One question that every team faces when moving to Git is what development workflow to use. Since every team is different and has different requirements, there is no one-workflow-fits-all approach. However, there is one rule all teams should follow when looking for a new workflow to adopt: Keep it simple. Doing so will reduce the number of mistakes people can make, and will help with adoption. On the Stash team, we’ve adopted one of the simplest Git workflows possible. And since so many of you have asked, we’ve decided to share our workflow in the hopes that it will help you and your team adopt Git. Story branching Every significant piece of work on the Stash team is associated with a JIRA issue. This makes it easy to track why a change was made, and when it was shipped. For every new task, we create a branch, named using the issue key and a short description. By using the new integrated development flow found in JIRA and Stash, a developer can just click the create branch link in the JIRA view issue page. Or, devs can create branches manually it by running the following in the console: 1$ git checkout -b STASH-22-my-task-name This shorthand automatically creates and switches to the new branch, so coding can start. Short-lived branches When thinking about branches, people generally imagine a fork of the code that lives for weeks or month, and is a nightmare to merge when ready. That’s not how you should think of branches when working with Git. Think of them as a tool for your daily workflow. Remember, they’re easy to create and easy to merge. Branches can be as short lived as a few minutes, but generally live for a few days until the work on the specific issue or feature has been completed. If work on a branch goes on for a longer period of time, the branch is frequently updated with changes from master to avoid a large number of conflicts once it’s is ready to be merged (Bamboo even has the option to do this for us automatically). Stay tuned for an upcoming article on the different schools of thought regarding how to keep your feature branches up to date, and whether to use merge or rebase when the development is complete. The branch holds all code changes related to that feature, and we work on it in isolation until we are satisfied with the work. Behind the scenes, Bamboo is building and testing our branches every time we push commits to the repo. Once we have something presentable, we create a pull request from our branch back into the main development branch, typically master. A pull request is like saying. “Hey, I’ve got some changes here that I would like to merge. Can someone take a look at it?”. Pull requests We pick at least two reviewers and ask them to take a look at the pull request. To ensure reviewers have all the information they need, the pull request description should be clear about what has changed. Stash generates a pull […]
Previous Topic
