Embedded Software Git Workflow:2018

The following has been used successfully on several one and two person projects spanning 3 to
9 months.

Overview
Git allows many different workflows. We will use the following Feature Branch Workflow.

1. Use feature branches for all new features and bug fixes
2. Merge feature branches into the master branch once the work is done*
3. Keep a high quality, up-to-date master branch - always builds, passes tests, safe to
branch from
4. Use release branches for all releases

Which leads to:

1. Never commit work directly into master

2. Never merge work into master until the work is done*

*Done - defined per project but likely includes - passes all tests, code review complete.

Tip: Bitbucket Server can be configured per repo to prevent commits into master and restrict
merge to Pull Requests. This approach is not required.

Use feature branches to develop

Develop features and fix bugs in feature branches based off the master branch. This makes
reviewing history very simple:

Feature branches should be named <type>/<description> where:

● <type> can be feature, bugfix, hotfix
● Bugfix and hotfix should always use the jira issue as part of the description
● Examples: feature\mAoutput, bugfix\paomfw-43

Small Applications - feature/development

For a very small application (e.g. an internal tool) which will take one or two weeks to code, a
single feature branch is sufficient. This should be called feature/development.

Tips: Branches created within Bitbucket Server have the appropriate prefix.
Use release branches for all software releases
Create a release branch from the master branch when you believe you are ready to stabilise
code for release. Create branches to fix bugs from the release branch. and merge them back
into the release branch. When a release is complete, merge the release back into master. Any
hotfixes should be branched from the release branch.

Tip: Lock release branches when you're ready to stop supporting a particular release.

Tagging Releases
Tag commits which are release candidates and tag the actual releases.
E.g. on release branch release/20 which failed testing on rc1 but passed on rc2, the following
tags should be in place: v20-rc1, v20-rc2, v20 (v20 = v20-rc2)

Optional - Merge using Pull Requests

Bitbucket Server also supports Pull Requests before merging a branch into master. A Pull
Request is a discussion between developers about the branch prior to merging - effectively
acting as a lightweight code review.

Tip: A pull request can be raised many times in the development of a branch. It can act simply
as the basis of a discussion.

Diverging from this workflow

The above workflow should work for most of the development we do. However, there may be
situations where a different workflow would better suit a project. This is ok - but should be
documented in the project README.md file.
Further Reading
● Git simple guide including cheat sheet
● Microsoft Git branching strategy - similar to the above except cherry picking is used from
release branches back into master
● GitHub team use of Feature Branch Workflow - again, similar to the above
● Official documentation on branches
● Official documentation on tags