Is it wise to use branching with one-man git project?

Question

I have a small project on git, on which I am the sole developer. For now, I used only one main branch to actually get it working.

Now the project is somehow working and I would like to just implement some new features. The question is, should I create new branch for each new feature and merging it back afterwards?

The fact is, my workflow will be just improving the "feature branch" and merging it back into the unchanged "master branch" most of the time anyway, so does it make sense to make new branches at all?

Answer 1

Rule of thumb: if you break the product during development, branch. Just assume you find a bug in trunk, and want to fix it.

Answer 2

It makes sense as long as it helps you.
I use SVN for my personal projects and sometimes when I want to research a new feature or throw away a lot of code I like to branch off my main branch.

That way I can work on the new functionality for a long period of time (read: more than one commit) if I fail I can always go back to the main branch and if I succeed I can merge the whole branch or just the changes that make sense.

Answer 3

I'd say its probably personal preference, but on some of the solo project I work on, it is sometimes useful to at least create a branch for the new work, leaving the master branch available to bug fix. I find myself in the middle of working on something new, when someone comes along reporting a bug to the existing version. In that situation, i can easily shelve the new code and fix the bug on the master branch, then go back to the things i was working on. Then in the end merge them together.

I don't usually branch for each new feature though. I don't typically work on multiple features at the same time...only once in a while, in which case it depends on how much the two features overlap file-wise that would cause me to branch again.

Answer 4

I would say yes, for me every time I push code into the production environment I will create a version branch. So if something goes wrong I can simply go back to that branch and make the fix push the fix out and then merge my code change back into the trunk.

Answer 5

should I create new branch for each new feature and merging it back afterwards?

Yes, because halfway through implementing that feature, you'll find a show-stopping bug in your production code, and you will be thankful that you can git checkout master back to the code that is in production and fix it. My rule is to always have my master branch in a deployable state.

Answer 6

From the gitworkflows man page:

Any nontrivial feature will require several patches to implement, and may get extra bugfixes or improvements during its lifetime.

Committing everything directly on the integration branches leads to many problems: Bad commits cannot be undone, so they must be reverted one by one, which creates confusing histories and further error potential when you forget to revert part of a group of changes. Working in parallel mixes up the changes, creating further confusion.

Use of "topic branches" solves these problems.

You should use topic branches (aka feature branches) even if you are the sole developer.

In addition to the reasons cited above, I would add:

• If you have a feature that will take a long time to complete, working on a feature branch allows you to easily suspend work on that feature to work on something else.
• If there is a chance that you need to support multiple versions of your code (i.e. your current version is v2.0, but a customer/user is using v1.0 then using topic branches allows you to easily merge bug fixes into multiple versions.

Answer 7

I say yes to having feature branches, even during a trivial 1 person project with no customers.

The reason is workflow. If you use a single workflow that you can apply across all the projects you are involved in then there is less to get wrong each time and fewer decisions to think about. It also makes life easier if your 'trivial' project suddenly takes on a life of it's own :-).

(A single workflow is an ideal of course, but anything that helps...)

Answer 8

Adding to what others have said: branches are so easy to create & maintain in git, why not make a branch? Even if you never need to do a bugfix / update on the old branch, you'll still end up with some extra meta-data about your code-base via the branches that you'll be happy to have in a year.

I'm a big fan of making all kinds of feature branches, for two reasons: first, you can structure your workflow such that the master branch is always ready to ship (which is pretty cool) and second, once you have some history with a bunch of feature branches and such, looking at the tree in something like gitk or qgit gives you a really cool high-level feel for the history of the codebase that a single line wouldn't.