Skip to content
No description, website, or topics provided.
Branch: release/2.0.0
Clone or download
Kevin Sheedy
Kevin Sheedy Simplify
Latest commit a457c18 Sep 9, 2015
Type Name Latest commit message Commit time
Failed to load latest commit information.
images Branching Diagrams Aug 20, 2015
.gitignore Branching diagrams Aug 20, 2015 Simplify Sep 9, 2015
branching-diagram.odg Branching diagrams Aug 20, 2015 Image with multiple release branches May 20, 2015 Branching diagrams Aug 20, 2015

A Lean Git branching model

Lean Git Flow is a lightweight branching strategy desinged for teams doing releases approximately monthly to quarterly rather than continuously. It is designed to be "As simple as possible but no simpler" and tries to avoid some of the unnecessary complexities of other branching strategies. To customise the workflow for your own team, feel free to Fork It.

alt text

Release 1.0.0 Branch

We start by creating a release branch. For now, this is also the mainline branch where day to day development is done. Release branches are named using Semantic Versioning i.e. MAJOR.MINOR.PATCH

git checkout -b release/1.0.0

alt text

Release 2.0.0 Branch

As soon as we need to commit some code that will not be part of release/1.0.0, we create a release/2.0.0 branch. The release/2.0.0 branch now becomes the mainline branch while release/1.0.0 is for last minute bug fixes and release preparation.

git branch release/2.0.0

alt text

Merge 1.0.0 into 2.0.0

Once release/1.0.0 has shipped, we merge it forward into release/2.0.0 ensuring that any bugfixes are not lost. Development now continues on the release/2.0.0 branch.

git checkout release/2.0.0
git merge release/1.0.0

alt text

Release 3.0.0 Branch

Again, once we need to commit code that will not be part of release/2.0.0, we create a release/3.0.0 branch. The release/3.0.0 branch is now the mainline while release/2.0.0 is for last minute bugfixes and release preparation.

git branch release/3.0.0

alt text

Continue Indefinitely

This process of creating one release branch per release and merging it forward can continue indefinitely.

alt text

Delete the master branch

The term master can have different meanings depending on the context. With LeanGitFlow, we delete the master branch.

git branch -d master

To delete the remote master branch use:

git push origin --delete master

Remember, git branches are just pointers. By deleting master, we don't lose any code or commits, as long as we have already created a release branch.

Feature Branch

A feature branch provides an isolated sandbox to do some work. That work could be a bugfix, a new feature or just an experiment. If you commit your work to a feature branch, it stays completely isolated from all other branches. This is very useful if you need to save your work and switch to working on a different task before the feature is complete.

git checkout -b feature/login-screen

Commit to your Feature Branch

git commit -m "This is my new feature"

Push your Feature Branch (or not)

If you want to share your feature branch with the team, push it to the central repo. This is often done so a code review can take place.

git push origin feature/login-screen

Alternatively, you may decide to keep your feature branch locally and to skip this step.

Merge to the release branch

Once you decide your feature is ready to target a particular release, merge it. You can do the merge locally or on the server using a Pull Request. A Pull Request allows for a code review to take place. To do it locally use:

git checkout release/1.0.0

git merge feature/login-screen --no-ff

The --no-ff flag forces git to create a merge commit. This preserves the history that the feature branch existed.

Tag Every Build

Every build is tagged by your CI Server using the Semantic Versioning convention: MAJOR.MINOR.PATCH+BUILD

git tag 1.0.0+25

Commit directly to the release branch

When appropriate, you may choose to commit directly to the release branch. You and your team decide if this is allowed. Use your best judgement when to use a feature branch and when to commit directly to the release branch. This is useful when you need to make a very small change like a spelling correction.

Tag Production Ready Code

When your code is deemed production ready, tag it. LeanGitFlow advocates Semantic Versioning. Any commit with a tag in the form 1.0.0 is deemed a released version. Once the code is tagged/released, there should be no more commits on that release branch.

git tag 1.0.0 release/1.0.0

If the code gets tagged in error, git allows you to delete the tag and to re-tag it. However, this should only be done if a tag was genuinely created in error.

Branch from a tag

Release branches can be branched off other release branches or from a tag. This is useful for patch releases:

git checkout -b release/1.0.1 <tagname>

Default Branch

Many Git Servers (GitHub, GitLab, GitStash) allow you to specify a default branch. This branch gets displayed when you browse to the repo via the web interface and gets checked out when you clone the repo. By default, it's usually master. With LeanGitFlow, it's up to you to set the default branch to whatever release branch you see fit.

Not sure what to name your branch?

If you're not certain what version your next release will be, that's not a problem. Give it a provisional version number and you can change it later. For example, if your last release was 2.2.1 then you could provisionally create a release/2.3.0 branch. Later, you may decide that the next release will actually be 3.0.0. In that case, simply create a release/3.0.0 branch and delete release/2.3.0.

Other Workflows

Check out these other git workflows and pick the one that suits you:

You can’t perform that action at this time.