6

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?

3
  • 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
    Commented May 4, 2017 at 15:37
  • We work on our own local branches and then eventually push everything to a remote repository.
    – Snoop
    Commented May 4, 2017 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
    Commented May 4, 2017 at 17:32

1 Answer 1

Reset to default
12

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.

7
  • 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
    Commented May 4, 2017 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
    Commented May 4, 2017 at 15:47
  • 2
    @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
    Commented May 4, 2017 at 18:06
  • 3
    @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
    Commented May 5, 2017 at 15:34
  • 1
    The term 'private branch' might not make as much sense if you're using a centralised VCS like SVN, in which case shelving might be more what you want, but this post has the 'git' tag and since Git is distributed it is trivial to make local branches that are never committed to the central repository.
    – Sean Burton
    Commented Oct 16, 2017 at 16:03

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