Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Related: Should every git commit leave the project in a working state?

Suppose I make the following commits locally:

  • Modify the database schema, breaking the application.

  • Update the application so it is compatible with the database schema again.

As long as I push both commits, master remains in a working state. However, a historical version is broken.

I'm aware that I can use git rebase -i to squash the commits together. However, the resulting commit will be large and less descriptive. If I need to search the commit history to find out why I changed something, I'd rather find the original commit showing what I did and why.

My questions are:

  • Has anyone encountered difficulties due to broken historical commits in master?

  • If so, is there a simple way to avoid such difficulties, without discarding individual commit messages and changes?

share|improve this question

3 Answers 3

Largely depends on your outfit's branching strategy, but I think that having broken commits on development branches makes a ton of sense in general -- the real big "win" in using source control is to be able to roll back small changes and sometimes you are making a bunch of them and you gotta break eggs to make omlets.

The simple way to keep the individual commits without polluting master is to use branches. You can put the breaking/experimental stuff in there so you can have a fine-grained history without polluting the master branch's history.

share|improve this answer
Yes, but when I merge a feature into master and it's a fast forward, master now has all of those commits. If it's a lot of commits, should I consider using the --no-ff option to git-merge to force it to make a merge commit? –  Joey Adams Dec 7 '11 at 23:52
I believe it is a sensible goal that every commit into the master branch creates a working software version. If rolling them into one big one does not make sense, the commit comments should clearly describe any dependencies with other commits. –  mattnz Dec 8 '11 at 0:19
My opinion is that those "broken commits" are good. If you have some bug that you didn't see in your implementation, these "broken commits" can give you a very specific memory refresher on what you changed. Sometimes, it's just the hint you need. –  hbdgaf Dec 8 '11 at 0:47

Broken commits are something that "just happens", shouldn't mean the end of the world. I do have a little nagging voice in the back of my head that tells me one shouldn't knowingly check in broken code, as a matter of principle and therefore including historical versions, however it's not something I'd go to war over.

Git's much praised branching model makes it feasible to keep broken commits off specific branches, e.g. if your team adopts gitflow or a simplified version thereof. Anything with a "clean master" policy. In this case, you could check in the final, working version as a merge commit, where the (broken) historical versions are available in the repository but off the main line.

If your team hasn't adopted such a branching model, then you have a valid excuse to just push the whole lot to master and be done with it.

share|improve this answer

I think as long as the commits are local and not pushed to others it's not only ok, it's actually a good way to work. Just don't push broken code to others.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.