[boringboy]

Hello,

I do a lot of programming for my work and I use Git for version control and I love it.

However, I always work alone and put my work on github. What I would like to learn about is a useful Git branching model. I try to keep separate release, develop and feature branches. I'd like to hear from people who have experience working in teams. What branching model do you use?

Thank you for your input!

 

[Nixalot]

At my work we keep all of our monitoring scripts inside a git repo. There's a small team of people that make updates and there's one lead (me). We do releases every month.The branches and workflow are setup as follows:

master -> this is everything as it currently exists in the production environment
monthly -> everything that is going to be in the next monthly release ends up here

The rules are as follows:

1. Nothing gets merged into master EXCEPT by the lead, and ONLY after the completion of a monthly release
2. monthly MUST always be in a releasable (meaning stable and tested) state. This is imperative in the event we have to do an emergency release to fix a critical bug
3. As a result of number 2, all development is done in a branch (our method makes no distinction between feature branches and fix branches)
4. After whatever is being worked on is ready to be merged into monthly, a pull request is sent to the lead, who reviews the changes and either accepts or rejects them. If accepted, the changes get merged into monthly and will be included in the next release
5. I dislike merge commits, so before merging into monthly I always rebase off monthly then merge so it's a fast-forward. This also lets me deal with conflicts in a branch that isn't one of the two critical ones which is ideal

Before settling on the above model, I reviewed a number of git branching models including git-flow and Scott Chacon's description of how things are done at github. I decided though that neither of those models really worked very well for how we do things at my place of employment. Incidentally, if you haven't read the posts describing git-flow and Scott Chacon's post about github you should, they're very informative. You can find the post describing git-flow here and Scott Chacon's post here.

In the end the method used by my team is closer to how they do it at github, though we don't do the immediate deployment that they do, and there's only one person who reviews the changes instead of a group of people.

 

[boringboy]

Thanks for your reply Nixalot.

That's pretty much how I try to keep my branches - though I often make mistakes in the naming convention for the branches resulting in some inconsistency.

But even if I work alone, I do something similar to what you do - I push the unmerged tested and stable branches to the github repo and it is my online account that sends pull requests and verifies and before merging the branches. We'll see how it works if I have anyone collaborating with me. At the moment it's just me working alone.

 

[randomizer]

I used to be a rebase fanatic too, but then I realised that it's much easier to see when and where new code came from when you have merge commits. I usually now do a combination of the two. I rebase any work that I did in master directly on the remote's master branch (which usually just means a fast forward since I avoid doing all but the most trivial of changes in master), and then I merge in my branch with a meaningful message. I never merge into master before making sure that I have the latest changes from the remote. Plenty of people in my team don't do this, and then they blindly pull from the remote, creating lots of "merged branch 'master' into 'remote/master'" messages and a really messy history (just view the graph!). I think later git versions have made it harder to merge with meaningless messages but you still have the extra unnecessary commits.

There are pros and cons to any workflow.

 

[i_ame_killer_2]

I do not have much to add but this might be a short but good read: http://nvie.com/posts/a-successful-git-branching-model/

 

[boringboy]

Thanks all for your inputs.

I looked at the article A successful Git branching model and I find that finally it is quite similar to what I am using. I do have one question. On this page, in the section Incorporating a finished feature on develop, I find that they delete the feature branch once it has been merged. I understand that the resulting graph looks much cleaner and there really is not much utility in keeping an old branch that has been merged into its parent. Apart from these reasons, are there any others as to why one should (or should not) delete the branch? I usually don't delete merged branches, but maybe I should start doing it.

 

[Nixalot]

Quote:

Originally Posted by boringboy

Thanks all for your inputs.

I looked at the article A successful Git branching model and I find that finally it is quite similar to what I am using. I do have one question. On this page, in the section Incorporating a finished feature on develop, I find that they delete the feature branch once it has been merged. I understand that the resulting graph looks much cleaner and there really is not much utility in keeping an old branch that has been merged into its parent. Apart from these reasons, are there any others as to why one should (or should not) delete the branch? I usually don't delete merged branches, but maybe I should start doing it.

I personally delete merged branches just to keep the repository cleaner. The only time I've ever kept branches around after a merge is if for some reason I have more work to do in the branch after the merge

 

[boringboy]

Quote:

Originally Posted by Nixalot

I personally delete merged branches just to keep the repository cleaner. The only time I've ever kept branches around after a merge is if for some reason I have more work to do in the branch after the merge

I have started deleting merged branches too. The Git repository keeps all the changes anyway, but just not as different branches, so nothing it really lost, and we get a cleaner repository. Thanks!

 

[Nixalot]

Quote:

Originally Posted by boringboy

I have started deleting merged branches too. The Git repository keeps all the changes anyway, but just not as different branches, so nothing it really lost, and we get a cleaner repository. Thanks!

Yeah that's true. Plus you can always recreate the branch from one of the commits anyway

 

[randomizer]

Quote:

Originally Posted by boringboy

I understand that the resulting graph looks much cleaner and there really is not much utility in keeping an old branch that has been merged into its parent.

Deleting the branch won't change the graph at all. The merge commit hasn't been deleted, only a pointer to it. Since HEAD on your master branch (assuming you merged into master) already points to the same commit there is no point keeping the other branch around. All it does is clog up your screen when you run "git branch".

 

[boringboy]

Quote:

Originally Posted by randomizer

Deleting the branch won't change the graph at all. The merge commit hasn't been deleted, only a pointer to it. Since HEAD on your master branch (assuming you merged into master) already points to the same commit there is no point keeping the other branch around. All it does is clog up your screen when you run "git branch".

Right. I phrased it incorrectly. It's the output of `git branch` that is cleaner. As Nixalot said, one can easily create a branch out of a previous commit so nothing is really lost. It just minimizes the possibility of someone pulling inadvertently from a branch that was not ready.