When and how to commit?

Question

I'm getting used in working with git at the moment. And I'm touching an issue that is unclear to me.

I feel compelled, if I think of commiting after a change and making a documenting description. I don't know exactly when I should commit, because that's very relative and there's always something under construction.

I tend to commit, when I fear to hose something. But then the summaries look like "Backup before trying this and that" or just "Backup".

What do you do? Is there a better way, or is my practise common?

Tim Abell · Accepted Answer · 2012-05-13T22:05:42.943

7

You can do whatever is socially acceptable with your fellow programmers on the project you are working on. There are no rules really.

Personally I commit very often to keep change-sets really small and make sure they only do one thing, and then may or may not rearrange / squash those before publishing to the team.

When you realize you have git rebase -i to hand, it becomes less important how often you commit initially.

In terms of comments, I think it can be important that your commits are well described so that you can manage the changes you are working on.

edited May 13 '12 at 22:05

answered May 12 '12 at 15:21

Tim Abell

205
1
7

2

+1 for rebase. It makes commits "your own business" and you can present them however you want when pushing to the main repo. – Tamás Szelei May 13 '12 at 10:57

score 3 · Answer 2 · answered May 12 '12 at 15:28

Source control is a bit of a personal thing. Typically if you work with a group they will have their own procedures regarding when to commit and what your commit messages should look like. Typically you commit AFTER you complete some task, not before. Remember, you want to be able to access the most up-to-date code possible in case you lose your data.

Here are a few rules of thumb:

You should always, to the best of your ability, leave the commited code in a runnable state. Do not submit anything unless you tested it.
The commited code should be as up-to-date as possible without violating rule 1.
You should try to keep commits as small as possible. If you fix three bugs, it's best to have three separate commits (one for each bug). That way you can rollback one small change at a time. It also makes it easier to find where you introduced mistakes
Commit messages should be meaningful. Always write like someone else will read them (because you won't remember what you did a week after your commit)

Obviously, sometimes (esspecially when you're beginning a project) it's hard to follow these rules. Either the code isn't complete enough to be run or your changes overlap and it's too difficult to separate them. Use your own judgement.

Thanks, you mentioned some good points. Some things are just hard for me to compy with at the moment, because I have too less routine in this mental tasks and I find it hard to getting started with it. — , May 12 '12 at 15:52

score 2 · Answer 3 · answered May 12 '12 at 15:17

2

Git is wonderful and scary because of it's flexibility. While there is a lot of advice that will probably be given on this thread, I think the best advice that I can give is to keep two branches of your code:

1) master

2) stable

I commit like crazy on my master branch. There is no guarantee of any functionality on it. There is also a desire to have a version of your code that is stable... that's where the stable branch comes in. Every time that you have a stable version of your code, you can merge your changes back in to the stable branch.

Depending on how big the project is, I might have several branches from the master. I'll have one for each bit of functionality that I'm working on and I can merge the changes back in when they're stable.

So long story short. In git you don't have to choose between committing often and having stable commits. You can do both! I like to use gitk or git-extensions to view my branches. It helps me remember where I am and what I'm working on for each project.

answered May 12 '12 at 15:17

qwerty9967

121
2

That's a great approach! +++ Why do say _merge_ to the stable branch and not _commit_? I thought the version you have got, when you debugged much, is a stable one which can directly be commited to the stable branch. +++ What I read according to descriptions from your answer is: Just don't get confused by different natures of descriptions. – May 12 '12 at 15:36
Branches in source control, just like in a tree, are separate. Your stable branch isn't actually like a flag you put up at a certian point in time were you say "This is the stable version!". It's a completely separate copy. That means when you want to update your stable branch you need to MERGE the changes from the master branch over, just like you'd need to merge your code changes with the code changes of your teammates (several copies merging into one). – May 12 '12 at 15:39
So the master branch is a construction area where you test *sections* of functionality? – May 12 '12 at 15:56
Would you agree to this, acattle? (If so, I'd say, you should carry over the code from stable to master from time to time.) – rynd May 14 '12 at 15:19
The idea that you should only commit when things are stable comes from a centralized versioning system like svn. In svn, when you commit you are forcing your code on everyone else. In git, this is the "push" command. Likewise, in git you should only push stable code. – qwerty9967 May 15 '12 at 12:55
The statement that "branches are a separate copy" is not really true. You can think of branches that way, but you can also use them like a flag as I have described. The wonderful and scary thing about git is that you can use it in a lot of ways. I suggest playing with git and then looking at the tree in git-extensions or gitk. That's what really helped me to better understand what is going on – qwerty9967 May 15 '12 at 13:05

score 2 · Answer 4 · answered May 12 '12 at 15:27

Commit when you've completed a cohesive "unit of work". That could be fixing a typo in a comment, adding a new module to a project, adding some logging statements, writing a new unit test and the code to make it pass, or anything else that's easily understandable as a discrete change to a project. The key is "easily". Commits should be narrowly focused and able to be fully described in the commit message. The commit message is sentences or paragraphs, not books. In general, I'd say if you go more than an hour of solid coding without committing, you're doing something wrong.

"fixing a typo in a comment" - So like in Wikipedia, somehow. :-) +++ I think I should train me to have the courage to revert. — , May 12 '12 at 16:12

score 1 · Answer 5 · answered May 12 '12 at 15:15

Whenever I start a project, I make a bullet point list of the different components that need doing, and often that includes subcomponents. It doesn't have to be on paper, it can be in your mind (even if paper is easier to share than thoughts). I always commit when I complete a component that took "some effort" and is something worthy of showing someone, even if that is a fellow developer and not a client.

score 1 · Answer 6 · answered May 13 '12 at 09:21

First off, like others I'm assuming you're working on a local branch and that you have a master somewhere else.

I think a DVCS gives you a huge amount of freedom. I try to commit each time I make a semantic step forward and the code compiles. If I rename a variable, I commit. If I improve a comment, I commit. The advantage of a very fine-grained commit structure is that when you push to master there is a bundle of descriptive commits.

I tend to commit, when I fear to hose something. But then the summaries look like "Backup before trying this and that" or just "Backup".

Again, a DVCS gives you freedom. I wouldn't say "backup before trying flux capacitor", I'd say "written flux capacitor". If it turns out that this doesn't work, I'd back that particular change set out. You have the freedom to do this because you only have to worry that your changes break other people when they either pull from you or you push to the master branch.

score 1 · Answer 7 · answered May 13 '12 at 11:27

You can take practical advice from big long-running open-source projects, like Chromium, there you send code for review first, so you can discuss your changes early and other engineers can point out your mistakes. When everyone agrees code is 'good enough', you can commit it.

This solves the backup problem (you have a separate branch on your machine, and code review server typically allows to download patch), and leads to better code in general.

score 1 · Answer 8 · answered May 14 '12 at 14:04

The wonderful thing about git is that for the most part it's like having a paper notebook, the notes in it aren't shared and for the most part are useful(ish) to you alone.

That means you're free to commit over anything, I'll commit things like "tweaked x by 3px", totally useless to the overall goals of a project but then I'll rebase it in so the commits are clear and in a nice block. Plus with how easy git makes local branching and merging it encourages you to commit often and just manage the change set you want to apply, versus for example SVN where a commit has to be thought about as generally it's going out to every other developer straight away.

When and how to commit?

8 Answers8