Branches Overview

Branch	Protected ?	Base Branch	Description
Master	YES	N/A	What is live in production (stable)
Acceptance	YES	Master	The latest state of development (unstable)
Release/vX.Y.Z	NO	Acceptance	A temporary release branch that follows the semver versioning. This is what is sent to UAT.
FeatureName/StoryName	NO	Acceptance	Cutting-edge features /acceptance(unstable)
Bugfix	NO	Acceptance	Any fixes against master branch should be considered in a bug-fix branch. The bug-fix branch should be merged into the master branch and also into Acceptance.
Hotfix-*	NO	Master	These are bug fixes against production. This is used because develop might have moved on from the last published state. Remember to merge this back into develop and any release branches.

The central repository holds two main branches with an infinite lifetime:

• master
• develop (acceptance in our case)

Develop a new Feature/Story

1. Navigate to the project of bitbucket and create a feature branch based off of Acceptance
2. Develop the code for the new feature and commit as you go
3. Navigate to the project on bitbucket and open a pull request from feature/superlovelyfeature to Acceptance
4. When the pull request has been reviewed merge and delete the feature/superlovelyfeature branch
5. If you get a green build on the Acceptance then you are done, otherwise you need to fix the Acceptance branch.

Creating a feature branch using Git

$ git checkout -b myfeature acceptance Switched to a new branch "myfeature"

Incorporating a finished feature on acceptance using Git

$ git checkout acceptance Switched to branch acceptance $ git merge --no-ff myfeature (Summary of changes) $ git branch -d myfeature Deleted branch myfeature (was 05e9557). $ git push origin acceptance

Develop multiple features in parallel

There is nothing special about that. Each developer follows the above Develop a new feature or story workflow. During development, make sure to update from Acceptance often so that when you get ready to complete your feature you don't have to deal with large code conflicts.

Bug fixing

1. Navigate to the project of bitbucket and create a bugfix branch based off of Acceptance
2. Develop the code for the selected bugs to fix and commit as you go using one bug per commit
3. Navigate to the project on bitbucket and open a pull request from bugfix/maintenancename to Acceptance
4. When the pull request has been reviewed merge and delete the bugfix/maintenancename branch
5. if you get a green build on the develop then you are done, otherwise you need to fix the Acceptance branch.

Creating a bugfix branch using Git

$ git checkout –b bugname acceptance Switched to a new branch "bugname"

Incorporating a finished feature on acceptance using Git

$ git checkout acceptance Switched to branch acceptance $ git merge --no-ff bugname (Summary of changes) $ git branch -d bugname Deleted branch bugname (was 05e9557). $ git push origin acceptance

Production hot fix

In rare situations, you may need to get a fix into production fast! Use this workflow to push a hotfix to production when you cannot spare the time to follow the standard Develop a feature workflow.

1. Navigate to the project of bitbucket and create a hotfix/hotnamehere branch based off of master
2. Add a test case to validate the identified bug once fixed.
3. Develop the code for the hotfix and commit as you go
4. Navigate to the project on bitbucket and open a pull request from hotfix/hotnamehere to master
5. When the pull request has been reviewed merge and delete the hotfix/hotnamehere branch
6. If you get a green build on the master then you are done, otherwise you need to fix the master branch using again the hotfix workflow.

Creating a hotfix branch using Git

$ git checkout -b hotfix-1.2.1 master Switched to a new branch "hotfix-1.2.1" $ git commit -a -m "Bumped version number to 1.2.1" [hotfix-1.2.1 41e61bb] Bumped version number to 1.2.1 1 files changed, 1 insertions(+), 1 deletions(-)

Don’t forget to increment the version number after branching off! Then, fix the bug and commit the fix in one or more separate commits.

$ git commit -m "Fixed severe production problem" [hotfix-1.2.1 abbe5d6] Fixed severe production problem 5 files changed, 32 insertions(+), 17 deletions(-)

Incorporating a finished feature on acceptance using Git

When finished, the bugfix needs to be merged back into master, but also needs to be merged back into acceptance, in order to safeguard that the bugfix is included in the next release as well. This is completely similar to how release branches are finished.

First, update master and tag the release.

$ git checkout master Switched to branch 'master' $ git merge --no-ff hotfix-1.2.1 Merge made by recursive. (Summary of changes) $ git tag -a 1.2.1

Next, include the bugfix in acceptance, too:

$ git checkout acceptance Switched to branch acceptance $ git merge --no-ff hotfix-1.2.1 Merge made by recursive. (Summary of changes)

Finally, remove the temporary branch:

$ git branch -d hotfix-1.2.1 Deleted branch hotfix-1.2.1 (was abbe5d6).

Publish a new Release

The following steps should be respected:

1. Create release branch
2. Update pom.xml
3. Merge with master with tag
4. Delete release branch
5. Sync master branch with acceptance branch

Creating a hotfix branch using Git

$ git checkout -b release-1.2 acceptance Switched to a new branch "release-1.2" $ git commit -a -m "Bumped version number to 1.2" [release-1.2 74d9424] Bumped version number to 1.2 1 files changed, 1 insertions(+), 1 deletions(-)

Incorporating a finished feature on acceptance using Git

$ git checkout master
Switched to branch 'master'
$ git merge --no-ff release-1.2
Merge made by recursive.
(Summary of changes)
$ git tag -a 1.2
The release is now done, and tagged for future reference.
To keep the changes made in the release branch, we need to merge those back into acceptance, though. In Git:
$ git checkout acceptance
Switched to branch acceptance
$ git merge --no-ff release-1.2
Merge made by recursive.
(Summary of changes)
Now we are really done and the release branch may be removed, since we don’t need it anymore:
$ git branch -d release-1.2
Deleted branch release-1.2 (was ff452fe).