[dev] Git branch naming

Vilius Šumskas vilius at lnk.lt
Mon Oct 29 23:18:46 UTC 2012


Michael M Slusarz <slusarz at horde.org> rašė:

> Instead of explaining why I think our old setup is bogus, I will  
> instead describe what I think we should be using instead:
>
>   + The release of Horde 5.0 should be immediately branched into HORDE_5.
>   + 'master' again becomes the HEAD branch.
>     - For now, 'master' should be thought of as what will eventually  
> become Horde 5.1
>     - *ALL* developers should be using 'master' going forward
>   + Bugs discovered on master need to be backported (i.e.  
> cherry-picked) into the HORDE_5 branch.
>     - We should *NEVER* be merging (i.e. 'git merge') to/from  
> branches for release versions.
>
> What does this setup give us?
>
>   + Proper browsing of the current code state
>     - Someone who goes to git.horde.org (or github) immediately sees  
> our most up-to-date code.
>     - This is consistent with other projects (browsing source code  
> always goes to the most up-to-date code).
>   + Enforces our release rules
>     - This setup makes it much easier to ensure that minor releases  
> (i.e. 5.0.x) are ONLY bug fixes or small features that are  
> easily/cleanly backported
>     - Since each individual commit it required to be back-ported, it  
> reduces the tendency to allow feature creep in maintenance releases  
> (I'll admit, I am one of the worst when it comes to this  
> distinction. Reorganizing the development tree in this matter  
> eliminates the incentive to do this).
>   + It prevents merge issues.
>     - Merging a large group of commits can be very confusing.
>     - Merging large commit groups may require someone to fix  
> conflicts who did not modify the original code.
>     - By cherry picking, instead of merging, it requires the person  
> to immediately resolve issues after they have just finished working  
> with the code, so it is more likely any merge resolutions will be  
> more accurate.

+1 on all of this. With the exception of branching of master during  
the release.

I would suggest branching during alpha/beta stages. This way long  
release polishing cycle won't block development work which should go  
into next "major" version, e.g. Horde 5.1.

-- 
   Vilius




More information about the dev mailing list