# Git Flow

By

KT-Anja

It describes a best practice branching model and follows essentially the GitHub Flow.

The main and develop branches are long-running branches with protection rules. The rules ensure that every change is code reviewed, along with ensuring passing tests in the CI environment before changes go in.

Represents the current state of production environment. It should always reflect the stable and deployable code.

This branch serves as integration branch for ongoing development work. It contains pre-production code with newly developed features and bugfixes.

When the next release date is approaching the develop branch forks a release branch. From this point on, no new features should be added to this branch, only bugfixes. When it is ready for delivery, the release branch is merged into the main branch tagged with a version number (rocket's semantic release management automates this). Additionally it should be merged back into the develop branch, which may have evolved since the release was initiated.

Are used for developing new features. Each new feature should be developed in a separate branch independent from other features. Several feature branches can be worked on simultaneously.

Bugfix branches are used to fix bugs in the code that are not urgent and critical. They are treated like feature branches but with another prefix.

Hotfix branches are used to fix critical bugs in production environment. Using these should be the exception. Merging such a branch triggers the creation of a new tag on the main branch.

• Use prefixes to categorize branch (see table below)

• Lowercase and Hyphen-separated: Stick to lowercase for branch names and use hyphens to separate words. For instance, feat/PROJECT-123-new-login or bugfix/PROJECT-123-header-styling.

• Use only alphanumeric characters (a-z, 0–9) and hyphens. Avoid punctuation, spaces, underscores, or any non-alphanumeric character.

• Do not use continuous hyphens. feat--new-login can be confusing and hard to read.

• The name should be descriptive and concise, ideally reflecting the work done on the branch.

When starting work on a new feature, branch off from the develop branch.

1. Make sure your develop branch is up-to-date

2. Create a feature branch based off of develop

$ git checkout develop
$ git checkout -b feat/PROJECT-123-new-feature
$ git push --set-upstream feat/PROJECT-123-new-feature

3. Develop the code for the new feature and commit. Push your changes often. This allows others to see your changes and suggest improvements/changes as well as provides a safety net should your hard drive crash.

4. Open a pull request with the following branch settings:

• Base: develop
• Compare: feat/PROJECT-123-new-feature

5. When the pull request was reviewed, merge and close it and delete the feat/PROJECT-123-new-feature branch.

Semantic-release will create a changelog file with every single commit message pushed to the branch. If you want to reduce the feature description to one line, use "squash and merge" option and provide a new commit message (following commit lint rules) before merging the pull request.

1. Make sure your local main branch is up to date.
2. Create a hotfix branch based off of main

$ git checkout main
$ git checkout -b hotfix/PROJECT-123-hotfix-issue
$ git push --set-upstream hotfix/PROJECT-123-hotfix-issue

3. Fix the critical bug code, commit and push. The commit message should be of type "fix".

$ git add --all
$ git commit -m 'fix(scope): [hotfix-issue]'
$ git push

4. Open two pull requests with the following branch settings:

• Base main - Compare: fix/PROJECT-123-hotfix-issue

• Base develop - Compare: fix/PROJECT-123-hotfix-issue (TODO: automate this one?)

5. When the pull requests was reviewed, merge and close it and delete the hotfix branch.