This is a presentation I wanted to give at work but never found the time (nor did it seem there would be any interest, the git branching model there has been chosen and is firmly in place).
The presentation shows there are multiple branching models and that each one is good for different situations. The Github model is the one I most agree with; have a master branch and make sure it’s always deployable.
I think I agree with it mainly because it adheres to Agile software development principles.
I was hoping to use the presentation to change the minds of the other developers to adopt a more flexible model of branching where we would branch for features and bugs almost always, in order to reduce the amount of time that the master branch is in a half-finished state. I didn’t like how we had a shared branch for all developers where half-broken stuff was committed which corresponded to multiple issues/tickets; I feel like this is close to SVN/Subversion where merging of branches is hard so you hardly use branches. Having things in a separate branch also gives you a nice space to do code reviews and to make code reviews a part of the process. When you’re allowed to dump code into the master branch whenever you want, there’s little guarantee that the code has been reviewed and when it has, a few commits later the review could be rendered moot. Using branches and pull requests (or patch submissions) you can review a more finalized feature or bug fix instead of each step that led to the solution.