This post originated from an RSS feed registered with Java Buzz
by Mathias Bogaert.
Original Post: The essence of branch based workflows
Feed Title: Scuttlebutt
Feed URL: http://feeds.feedburner.com/AtlassianDeveloperBlog
Feed Description: tech gossip by mathias
Two weeks ago I had the pleasure of speaking at the Jazoon conference in Switzerland about Git workflows. One particular piece that seemed to resonate well with the audience was the idea of looking at the underlying rules when it comes to branch based workflows. Workflows A workflow defines steps that represent how your team agrees to get code into production. The workflow being used needs to support a number of different use cases. How do I fix a bug in an old release, how can I make a hotfix of the code that is running in production, how do I do feature development, is the feature done, is the code compiling, are the tests running against the correct changes and so on? Those are questions involving a number of different concerns but the way developers interact with their version control system is an important piece of that puzzle. Therefore when we talk about workflows here we focus only on the source code management. And specifically how to use branches to help your team deliver software. There are a number of different branch based workflows out there. There is the well-known Gitflow workflow or feature branch based workflows similar to the way we in the Stash team use branches. Those workflows usually provide a number of useful advantages: Rules for branch creation (where do I branch off from) and merging branches (where, when and how do I merge changes back) A naming convention for the branches that conveys the purpose of the different branches and gives your team a common vocabulary (“never merge master into the release branch”) A shared understanding of what the various branches represent and what their expected life time is (long lived production branch vs. short lived feature branch) While this is very useful, looking at the underlying rules will help with understanding and more importantly enabling you to create a workflow from scratch or more likely adapt an existing workflow to fit your needs. Significant branches Before we try to understand the rules around working with branches in Git it is important to acknowledge that there are different types of branches. Significant branches map to a concept in the outside world. It may be a past release, a particular environment (staging, production) or a role (integrator). Those branches are long-running and stable whereas feature or more generally development branches are short lived and volatile. Short lived branches can be deleted after they have been merged as they are usually not important for the overall history of the project (and the merge commit will point to the tip of the merged branch anyway). The merge protocol The most important contribution the various workflow models have made, is a clear understanding of the merging rules that apply. But underlying all those different workflows is a set of very general rules that govern how branches should be merged. Those merge rules require an understanding of how one branch relates to another branch. Here we are specifically looking at how […]
Previous Topic
