Workflows

Gitflow

A successful Git branching modelnvie.com

More info on Gitflow

If you use the Extension git-flow, keep in mind that it will commit and push to main automatically through the scripts execution.

Thus you may not be able to create Pull Requests.

It is an alternative Git branching model that involves the use of feature branches and multiple primary branches.

It has numerous, longer-lived branches and larger commits.

Under this model, developers create a feature branch and delay merging it to the main trunk branch until the feature is complete.

This can lead to higher risk of deviating from the trunk branch and introduce conflicting updates.

Gitflow can be used for scheluded realese cycle projects and for DevOps best practices of CD.

Gitflow vs Feature Branch

It doesn't add new concepts or commands from what is required from Feature Branch, instead it assigns very specific roles to different branches and defines how and when they should interact.

In addition to feature branche, it uses individual branches for preparing, maintaining, and recording releases.

Develop and Main branches

We will have two branches to record the history of the project.

Other developers should now clone the central repository and create a tracking branch for develop.

main branch

Stores the official release history, but only an abridged version.

All commits here should be tagged with a version number.

develop branch

Serves as an integration branch for features, meaning done feature branches will ONLY be merged here. (Never to main)

Creating the develop branch

Manually:

git branch develop
git push -u origin develop

Using git-flow extension:

If using git-flow extension library, executing git flow init on an existing repo will create the develop branch.

$ git flow init

Initialized empty Git repository in ~/project/.git/
No branches exist yet. Base branches must be created now.
Branch name for production releases: [main]
Branch name for "next release" development: [develop]

How to name your supporting branch prefixes?
Feature branches? [feature/]
Release branches? [release/]
Hotfix branches? [hotfix/]
Support branches? [support/]
Version tag prefix? []

$ git branch
* develop
 main

Feature branches

Each new feature should reside in it's own branch, which can be pushed to the central repositoy for backup/collaboration.

feature branches will always branch off from develop, never from main.

When it is complete, it gets merged back to develop.

Note: feature branches combined with the develop branch is Feature branches workflow.

Feature steps (No PR)

1. Create a new local feature/<branch-name> from develop.

2. Work on feature...

3. Merge to develop.

4. Delete the feature/<branch-name>.

Feature steps (With PR and Rulesets)

Working with PR and Rulesets will not let you merge or push to main or develop from terminal.

1. Create a new local feature/<branch-name> from develop.

2. Work on feature...

3. When finished, go to GitHub and create a PR on feature/<branch-name>.

4. Finish the PR, merging to develop.

5. On your local repository delete the feature/<branch-name>.

Creating feature branches

Manually:

git checkout develop
git checkout -b feature/<branch-name>

With git-flow extension:

git flow feature start <branch-name>

Finishing a feature branch

Manually:

git checkout develop
git merge feature/<branch-name>
git branch -D feature/<branch-name>

With git-flow extension:

git flow feature finish <branch-name>

Release branches

Once develop has acquired enough features for a release (or a predetermined release date is approaching), you fork a release branch off of develop.

Creating this branch starts the next release cycle, so no new features can be added after this point, ONLY: Bug fixes, documentation generation, and other release-oriented tasks should go into release branch.

Once it is ready to ship, the release branch gets merged into (main and develop) and tagged with a version number.

You can follow SemVer versioning scheme of <major>.<minor>.<revision>.

release branches will always branch off from develop.

When it is complete, it gets merged into main and develop.

Release steps (No PR)

1. Create a new local release/<branch-name> from develop.

2. Add docs, bugfixes, hotfixes....

3. Merge to main and develop.

4. Delete the release/<branch-name>.

5. Tag the commit on main with an updated version number.

Release steps (With PR and Rulesets)

Working with PR and Rulesets will not let you merge or push to main or develop from terminal.

1. Create a new local release/<branch-name> from develop.

2. Add docs, bugfixes, hotfixes....

3. When finished, go to GitHub and create a PR on release/<branch-name>.

4. Finish the PR, merging to develop.

5. Manually merge squash release/<branch-name> into main.

6. Create a new Release on GitHub with an updated <major> or <minor> version number.

7. On your local repository delete the release/<branch-name>.

Creating release branches

Manually:

git checkout develop
git checkout -b release/0.1.0

With git-flow extension:

git flow release start 0.1.0

Finishing a release branch

Manually:

git checkout main
git merge release/0.1.0
git checkout develop
git merge release/0.1.0
git branch -D release/0.1.0

With git-flow extension:

git flow release finish '0.1.0'

Hotfix branches

Maintenance or hotfix branches are used to quicky patch production releases.

This is the only branch that should fork from main.

hotfix branches will always branch off from main.

When it is complete, it gets merged into main and (develop OR the current release branch).

You can follow SemVer versioning scheme of <major>.<minor>.<revision>.

Hotfix steps (No PR)

1. Create a new local hotfix/<branch-name> from main.

2. Work on the hotfix...

3. Merge to main and (develop or release).

4. Delete the hotfix/<branch-name>.

5. Tag the commit on main with an updated version number.

Hotfix steps (With PR and Rulesets)

Working with PR and Rulesets will not let you merge or push to main or develop from terminal.

1. Create a new local hotfix/<branch-name> from main.

2. Work on the hotfix...

3. When finished, go to GitHub and create a PR on hotfix/<branch-name>.

4. Finish PR, and merge on main.

5. Manually merge squash hotfix/<branch-name> into develop or release.

6. Create a new Release on GitHub with an updated <patch> version number.

7. On your local repository delete the hotfix/<branch-name>.

Creating hotfix branches

Manually:

git checkout main
git checkout -b hotfix/<branch-name>

With git-flow extension:

git flow hotfix start <branch-name>

Finishing a hotfix branch

Manually:

git checkout main
git merge hotfix/<branch-name>
git checkout develop
git merge hotfix/<branch-name>
git branch -D hotfix/<branch-name>

With git-flow extension:

git flow hotfix finish <branch-name>

Feature Branch

Forking