Ok so Git is such an instrumental tool in every day development. It gives us a safe environment to manage our codebase, it helps teams not step on each others toes when making changes, keeps a history of changes, and even lets us know who's responsible for what and when.
Using git isn't entirely straightforward though, and it helps to have a good well thought out strategy for your team from the get go. This article will describe the git-branch strategy we use for most of our projects here at Starleap, known as OneFlow. We have a single branch that lives forever as the
master branch. In addition to master, we have numerous support branches. The rest of this document describes in greater detail the branches, different scenarios, and gives CLI examples.
The Main Branch
This is our master branch that lives forever. All code that makes it to production is eventually on this branch.
This is where most day to day coding happens. This is used to develop new features and to fix bugs. Feature branches can be named as followed:
feat/<JIRA-ID>-<short title>— for branches that belong to a bigger epic, eg User Authentication, Bluetooth integration, In-App Chat etc
task/<JIRA-ID>-<short title>— for branches that take care of smaller changes that can be merged by PR into
masteror a feature branch eg Changing color of a particular text field from “Red” to “Blue"
bug/<JIRA-ID>-<short title>— for branches that fix bugs but don’t need to be released immediately eg a NPE on screen that is rarely viewed.
To create a feature branch from
mastergit checkout -b feature/SL-00-my-new-feature
When feature is ready to be merged into
master open a PR, click the merge button after approvals are gained, and delete the branch.
If using CLI:
git checkout master git merge --ff-only feat/SL-00-my-new-feature git push origin master git branch -d feat/SL-00-my-new-feature git push origin :feat/SL-00-my-new-feature
This branch is used before we release to the Playstore. We first make a branch off of
master to create a build to give to QA. As QA works with the build, any bugs that arises, we commit to the release branch so they can reevaluate. After QA approves the build, we tag the last commit on the release branch, make a production release build, merge into
master, and delete the branch.
git checkout -b release/1.0.0 (Fix issues as they arise and continue to supply QA with builds each time this branch gets a commit) (QA approves the build) git tag 1.0.0 (Release a build to PlayStore) git checkout master git merge release/1.0.0 git push —tags origin master git branch -d release/1.0.0 git branch push origin :release/1.0.0 (delete the branch remotely because it's been merged. Can use delete branch button on Github)
If we make a release that has an urgent bug that needs a production fix ASAP, eg application crash on launch, you are in need of a hotfix branch. To create a hotfix branch we grab the commit of our last release, branch off, make our fix, get approval, and release to store. Aside from creating a hotfix branch, there are no differences than a release branch.
git checkout -b hotfix/1.0.1 (Fix issues as they arise and continue to supply QA with builds each time this branch gets a commit) (QA approves the build) git tag 1.0.1 (Release a build to PlayStore) git checkout master git merge hotfix/1.0.1 git push —tags origin master git branch -d hotfix/1.0.1 git branch push origin :hotfix/1.0.1 (delete the branch remotely because it's been merged)
Git is awesome on it's own, but even better when everyone on the team is using it in consistency. Having a simple strategy and some good documentation to go back to (feel free to use this article) will help get the best out this vital tool.
The following are the main advantages of the OneFlow strategy.
- Maintaining a single long-lived branch simplifies the versioning scheme.
- Day-to-day operations that developers have to perform are also dramatically simplified.
- Cleaner and more readable project history.
We also believe that both "OneFlow" and "GitFlow" are both very well suited for most software development projects, although we should point out that there is no silver bullet, so feel free to tweak this slightly or look into alternatives to suit your needs.