This question already has an answer here:

I would expect any build that I ever pulled from a repository to just compile, along with any dependencies that are required. Likewise, I would never commit anything that didn't at least compile. That is to say that there could still be known bugs or errors in the build, but at least it compiles. But this is how I do things now... I guess I sort of convinced myself for some unknown reason, that this is the way things ought to be done.

When I had less experience with version control I would just check-in/commit my builds every so often just to keep track of my "progress". Or in other words if I royally screwed something up I could just revert back to a previous commit (even though that commit doesn't compile). I still sort of work this way... but I at least make sure everything compiles before committing.

My question is, should the committed build at least compile? Or does it not matter?

marked as duplicate by gnat, Community May 4 '17 at 16:43

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • I think this would largely depend on whether you're working alone or with a team, and if the team agrees if this is an ok thing or not. It could also depend on whether you're committing to a master branch or a development branch. – neilsimp1 May 4 '17 at 15:37
  • We work on our own local branches and then eventually push everything to a remote repository. – Snoop May 4 '17 at 15:38
  • 1
    A build that does not compile?... You mean like a fire that does not burn? Or a party without people? Seriously, you probably want to rephrase your question. To "code that does not compile" instead of "builds that don't compile". It is not the build you put into your VCS, the build is your compiler's output or, if you wish, the process of compilation (as in "the build broke"). – Martin Maat May 4 '17 at 17:32

It does matter because once you're not the sole developer, you will have other people branching off the main branch. If it isn't in a working state, they'll have to fix it before starting their work, which is obviously something you don't want.

What's acceptable is committing whatever you want in your own personal, private branches. You can experiment as much as you want, then once you're done, you can rebase your branch before merging into master. You have the best of both worlds: a clean public history and the possibility to revert to an older commit as much as you want during development.

  • Darn, that sounds like what I should actually be doing. All this time I've just been pushing all of my commits... So on our remote, is essentially a collection of every single commit that's ever been made. I guess that's not such a good thing? – Snoop May 4 '17 at 15:42
  • 3
    Some people don't think it's worth it to take the time to rebase. From my experience, it makes it easier to find out why something changed when the commit message is clear. If it's cluttered in a sea of "WIP", "not compiling", "test", etc., it becomes hard to understand the reason of the change. It's ok if you commit a lot during development as checkpoints, but it's not interesting for the rest of your team that you had to commit three times to make your code compile. – Vincent Savard May 4 '17 at 15:47
  • No, that is not what branches are for, branches should build just like the trunk should build. Saving intermediate work to the VCS would be shelfing and if that is not available you should save your work locally. – Martin Maat May 4 '17 at 17:38
  • 1
    @MartinMaat "[...] you should save your work locally", which is exactly what I advocated for, by using private branches. It doesn't matter whether branches compile or not until they're made public. – Vincent Savard May 4 '17 at 18:06
  • 2
    @MartinMaat What does something being public or private have to do with if it's a branch or not? A branch is just a series of changes parallel to another series of changes, with which it has a common ancestor. Public and private just indicates if it's accessible to others or just you. It's trivial to create a branch on your local computer and keep track of its history of changes. You can even set up a remote branch, but keep it restricted so that only you can push to or pull from it. Distributed VCSs make this all easy, and I'd be rather surprised if centralized VCSs prevented this. – 8bittree May 5 '17 at 15:34

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