Version Control Work Flow

Question

I have been coding for over 10 years but I have never used any kind of version control. I am wanting to learn and start using GIT, I intend on reading the Apress ProGIT book soon.

This question isn't on how to use the GIT command but more on in which steps to invoke them.

I often read about people saying to checkout a project, then push it to the server.

I am usually working on many files at once so I am trying to figure out, everyime I make a change to a file and hit save` is that the time I should commit that file, or is it more like ok I worked on these 5 files today, at the end of the day I can commit all these 5 files?

I know a lot of people use command line for GIT so I can't imagine them going back and forth every time a fil is changed.

I realize this may sound basic and it is but remember I have never used any kind of version control so I am a bit lost, I mean all the articles and tutorials are about the correct syntax/commands and assume you have other version control knowledge (which most people do)

Answer 1

The thing with git, or any DVCS for that matter, is that committing and pushing your commits upstream are entirely separate notions. If with SVN, for example, committing meant everyone seeing your changeset, in git you have no such worries. Commit whenever you want, as much as you want. Push the changes upstream once you're confident enough with them.

This allows you to commit as often as you wish. Basically this boils down to your personal workflow preference and that of your team.

A good rule of thumb is to commit once you have a stable new version of your code, such that if anyone happens to check out that revision, stuff won't be broken. (This is also important later on if you plan on doing git bisect , which is an advanced debugging method, but ignore that for now.)

There are some really good resources that you can learn-by-example from:

• http://nvie.com/posts/a-successful-git-branching-model/
• http://gitready.com/

Answer 2

I am usually working on many files at once so I am trying to figure out, everyime I make a change to a file and hit save` is that the time I should commit that file, or is it more like ok I worked on these 5 files today, at the end of the day I can commit all these 5 files?

When working with VCS it's better to think about changes in terms of features (or fixes if you're working on an issue) and not just files. Even if you changed only one file, but introduced new feature that is complete and, in case you're working in a team, ready to be shared with someone else it's time to make a commit. On the other hand if you changed 20 files already, but you are still in the middle of implementing new feature, it's better to postpone commit until you finished.

Every methodology has exceptions, but it's a general rule I try to use in my work. The idea behind it is that after checking out your code at any commit you get something more or less completed and working. Creating new commit for every feature is useful as well when you need to remove/revert one of the features later. Though, often you are working on a big feature that can't go in a single commit. In that case I still try to break this feature into smaller pieces and make commit after completing everyone of them.

And the exception for me is usually the project that just have started and you don't care so much about future as it's only beginning and project doesn't have good structure yet and most likely lots of the stuff will change in the nearest future. In that case my commits sometimes become huge and not that well structured.

Answer 3

Check out this link: Git for beginners: The definitive practical guide

I found it very useful. It made me understand how it works.