emjayess/git_branching_model_considered.md

## git_branching_model_considered.md

      
    Raw
  

              git_branching_model_considered.md
            
          
    Feature development - proposed branching model (graph)

Take a feature: like 'OBH'

__ master ______________________________________.___________________
  \                                            / (pull request ^)
   \__ develop ____________________________.__/_____________________
      \                                   / (pull request ^)
       \__ develop/obh/master _[._._._.]_/                          
          \  \  \  \  \         / / / / (pull requests...)
====================================================================
 !! branches above, NEVER rebase; branches below, rebase ANYTIME !! 
====================================================================
              \  \  \  \  \                    /   /   /   /   /
               \  \  \  \  \__ develop/obh/x _/   /   /   /   /
                \  \  \  \                       /   /   /   /
                 \  \  \  \__ develop/obh/db ___/   /   /   /
                  \  \  \                          /   /   /
                   \  \  \___ develop/obh/ui _____/   /   /
                    \  \                             /   /
                     \  \____ develop/obh/models ___/   /
                      \                                /
                       \_____ develop/obh/console ____/

Notes:


master and develop are long-lived or forever branches

never ever rebased
never ever destroyed


develop/topic/master is the feature integration branch;

to be considered shared/shareable, and never rebased
to be considered deployable to any environment for feature testing
destroyed after final acceptance into develop


develop/topic/NN-sub-topic are developer branches

where the work really happens
to be considred NOT shared

thus may get rebased at any point by the developer


destroyed once merged into develop/topic/master


Pull requests


A PR would remain open for develop to receive 'develop/topic/master`
A PR-per-sub-topic would be opened for develop/topic/master to receive each respective sub-topic

Pit falls

There are always potential pitfalls :)

sub-topics may require or depend on other sub-topics...