New Posts  All Forums:Forum Nav:

git branching model

post #1 of 11
Thread Starter 
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!
post #2 of 11
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.
post #3 of 11
Thread Starter 
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.
post #4 of 11
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.
Edited by randomizer - 8/16/13 at 5:29pm
    
CPUMotherboardGraphicsRAM
i7 920 D0 MSI X58 Pro-E GTX 560 Ti 448 3x2GB G.Skill DDR3-1333 9-9-9-24 
Hard DriveHard DriveOptical DriveOS
840 Pro Caviar Black LG BD-ROM Windows 8.1 Pro x64 
MonitorMonitorKeyboardPower
Dell U2713HM Dell U2311H Turbo-Trak (Google it :D) Corsair HX-520 
CaseMouseMouse PadAudio
CM690 Mionix Avior 7000 Everglide Titan AKG K 242 HD 
  hide details  
Reply
    
CPUMotherboardGraphicsRAM
i7 920 D0 MSI X58 Pro-E GTX 560 Ti 448 3x2GB G.Skill DDR3-1333 9-9-9-24 
Hard DriveHard DriveOptical DriveOS
840 Pro Caviar Black LG BD-ROM Windows 8.1 Pro x64 
MonitorMonitorKeyboardPower
Dell U2713HM Dell U2311H Turbo-Trak (Google it :D) Corsair HX-520 
CaseMouseMouse PadAudio
CM690 Mionix Avior 7000 Everglide Titan AKG K 242 HD 
  hide details  
Reply
post #5 of 11
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/
The Kandalf
(16 items)
 
  
CPUMotherboardGraphicsGraphics
I7 5820K MSI X99S Gaming 7 ASUS R9 280X TOP Crossfire X ASUS R9 280X TOP Crossfire X 
RAMHard DriveOptical DriveOS
Crucial DDR4 2133MHz 8GB (2x4GB) Samsung SpinPoint F1 1TB HP DVD630 Ubuntu 
MonitorKeyboardPowerCase
2x Philips Brilliance 220CW Microsoft Wireless Desktop Elite Keyboard Fractal Design Newton R3, 800W 80+ Platinum Corsair 900D 
MouseMouse PadAudioAudio
Mionix Naos 8200 Razer Pro Solutions Arcam rDAC B&W CM1 
  hide details  
Reply
The Kandalf
(16 items)
 
  
CPUMotherboardGraphicsGraphics
I7 5820K MSI X99S Gaming 7 ASUS R9 280X TOP Crossfire X ASUS R9 280X TOP Crossfire X 
RAMHard DriveOptical DriveOS
Crucial DDR4 2133MHz 8GB (2x4GB) Samsung SpinPoint F1 1TB HP DVD630 Ubuntu 
MonitorKeyboardPowerCase
2x Philips Brilliance 220CW Microsoft Wireless Desktop Elite Keyboard Fractal Design Newton R3, 800W 80+ Platinum Corsair 900D 
MouseMouse PadAudioAudio
Mionix Naos 8200 Razer Pro Solutions Arcam rDAC B&W CM1 
  hide details  
Reply
post #6 of 11
Thread Starter 
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.
post #7 of 11
Quote:
Originally Posted by boringboy View Post

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
post #8 of 11
Thread Starter 
Quote:
Originally Posted by Nixalot View Post

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!
post #9 of 11
Quote:
Originally Posted by boringboy View Post

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
post #10 of 11
Quote:
Originally Posted by boringboy View Post

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".
    
CPUMotherboardGraphicsRAM
i7 920 D0 MSI X58 Pro-E GTX 560 Ti 448 3x2GB G.Skill DDR3-1333 9-9-9-24 
Hard DriveHard DriveOptical DriveOS
840 Pro Caviar Black LG BD-ROM Windows 8.1 Pro x64 
MonitorMonitorKeyboardPower
Dell U2713HM Dell U2311H Turbo-Trak (Google it :D) Corsair HX-520 
CaseMouseMouse PadAudio
CM690 Mionix Avior 7000 Everglide Titan AKG K 242 HD 
  hide details  
Reply
    
CPUMotherboardGraphicsRAM
i7 920 D0 MSI X58 Pro-E GTX 560 Ti 448 3x2GB G.Skill DDR3-1333 9-9-9-24 
Hard DriveHard DriveOptical DriveOS
840 Pro Caviar Black LG BD-ROM Windows 8.1 Pro x64 
MonitorMonitorKeyboardPower
Dell U2713HM Dell U2311H Turbo-Trak (Google it :D) Corsair HX-520 
CaseMouseMouse PadAudio
CM690 Mionix Avior 7000 Everglide Titan AKG K 242 HD 
  hide details  
Reply
New Posts  All Forums:Forum Nav:
  Return Home
  Back to Forum: Coding and Programming