1

I am working on this project of mine where I am the only developer. I have chosen git for the version control for the project. Currently, I work from multiple systems and commit to the master branch of my central repository.

I wanted to know if this is a proper strategy or I am missing out of any helpful Git feature. Should I create branches for different systems or for different features of my project? Please advise what is a generally recommended strategy for my use case.

  • Is there any specific problem with your current approach? I often work on a single branch in my personal repositories, and it's fine for me. – scriptin Jun 11 '16 at 10:04
  • There's not really a problem, just wanted to know if there's a better approach that others are following. – jaibatrik Jun 11 '16 at 10:40
  • 3
    FWIW I branch even on solo projects. It adds some overhead, but makes me feel better about experimenting with things that might take a while. – RubberDuck Jun 11 '16 at 10:53
  • possible duplicate of To branch or not to branch? – gnat Jun 22 '16 at 8:17
6

First of all, your current approach seems perfectly valid.

Working from several systems (I understand here several PCs in different places, or eventually different OS compiling the same sources) doesn't change the fact that you still work on the same piece of software. So this should not not be the major influencer of your branching strategy.

However, it could be interesting to create branches for new major features, especially if significant refactoring is required. Branching could then allow you to still maintain the current version while working on the new one, and in case of serious troubles switch back to the working version.

If you work solo on a single system, you could avoid such branching by keeping the changes in the local repository before pushing them to your central repository. But branching would facilitate things especially if implementation of the new features take longer time.

But in your case, when working on several systems, you can't rely on the local repository. So the branching would definitively bring you the benefit to have "work in progress" shared between several systems.

Be careful however not to make your branching strategy too complex, especially if you're working solo on your project.

  • Agreed. Even if I'm only working on one branch, on one PC, I still use a feature branch, so that I can remember the cut point between the stable (master) and the breaking changes (feature branch). – jpaugh Jun 22 '16 at 21:14
4

Rule of thumb: Use as few branches as possible, and as many branches as necessary.

If a branch is necessary or not is something you mostly learn from experience, but when in doubt: don't branch. The reason for this is branching hell.

You need branches when you need to modify the same code at the same time in 2 different ways, for example when you release the software and want to support the release with bugfixes while also working on the next major version, or when you start writing a feature which you know you might not complete before the next release (or the next testing phase).

Temporary branches that live for minutes or days are a different animal, you can create as many of them as you want to, because you're closing them as quickly as you open them.

PS: That means your current setup is good.

  • I'd say: "When in doubt, branch". It's not hard to merge or delete a branch if you didn't need one. It can be annoying to roll back or even cherry pick commits though if you didn't branch and your awesome idea doesn't really work out. – user161778 Jun 11 '16 at 14:13
  • That answer you linked to was not specific to git, and is talking mostly about release strategy, i.e. long-running branches, not feature branches.Git makes branching and merging a lot easier than (say) SVN, and as long as you don't include the semantic overhead of a release with each (feature) branch, you're fine --- as long as those branches all get merged back into the master branch for the (same) release. Then, the feature branches can well be deleted and forgotten – jpaugh Jun 22 '16 at 21:18
  • @jpaugh Branching hell is the point when everyone loses track of which fix needs to go to which branches. This affects all version control systems equally, regardless of how easy branching or merging is. You are right that feature branches don't contribute to branching hell, at least until someone gets the bright idea to release from the feature branch. Reality is that there are lots of "if"s if you want to work with multiple branches, that's why the simple rule of thumb is to use few branches. Branching experts don't need the rule of thumb, because they know the many "if"s involved. – Peter Jun 22 '16 at 21:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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