Our recent webinar featuring product rock stars Jens Schumacher and Ken Olofsen gave a great overview of git workflows. Branching workflows go from bare and simple, to complex, robust, and defensive. What is the level of complexity and safeguard needed by your organization? This post covers the compromise between nimbleness and robustness, with some guidelines to choose your own git adventure and lessons learned inside Atlassian. The aim of this article is to give you the insight and tools you can use to decide how to choose the most effective branching model for your team. Guiding thoughts Trust the merge Stay away from branching model extremes. Simplify and flatten branch hierarchies when possible Consider how your development process and your tooling impact the branching model decisions Trust the merge The first step in choosing the optimal branching model is to trust the merge. I mention this for teams that have only recently adopted git; If you’ve passed this step and have embraced the merge, skip this paragraph. While in older systems you could be brought to extreme measures – like avoiding merges at all costs or hire a special team to take care of the merge hell – turns out merges are a non-event in git. This is due to several key things: Because branches are very cheap and fast, git encourages short-lived branches and fast integration. Merges are local in git, hence the result of a merge is often immediate. git knows the ancestry of your branches and only merges the commits that are relevant instead than the entire work-tree flat. This generally results in less conflicts. You have a plethora of merge strategies at your disposal. Because of this you will love to merge and by converse you will also love branching. Branching and merging become so easy that some teams end up with the opposite problem, they go overboard with them. So as with all in life, maintain a balance and don’t overdo it. Stay away from branching extremes If you look at branching models at large – pre- and post-git advent – you see they sit on a spectrum that goes from simple to layered. Extremes can be problematic. Let me show you a few stops on the branching continuum and why you might want them or not. Single branch extreme Memory of subversion past: one branch to rule them all. For years software teams (myself included) worked with just one branch, the trunk, in good or bad weather, with finished on unfinished features, with working or broken builds. This process used to work and it works still today. But it’s not the most efficient anymore. The one branch world we loved to hate and we grew up with and some of us still use, looks like this: Teams fresh on git adoption or teams that want to retain their workflow might try to reproduce the same feel. Even though the trunk in git-speak is now called master you can work with a single branch in git, it looks like this: Everyone works on master, nobody works on branches and every single developer uses rebase to keep up-to-date with the latest changes. This is very close to an old style trunk-only subversion branching model. It’s not uncommon for me to hear modern teams that – yes – […]
Previous Topic
