• We use an adapted Git Flow branching model
• Every team has their own develop/* branch to accumulate latest (none released) fixes or features
• For releasing we use an automated process (Create Release Branch). This requires commit messages to be as informative as possible:
  • MAJOR-changes should contain BREAKING_CHANGE
  • e.g. feat(icm): ... will get a MINOR-change (feat: or feat(...):)
  • and the rest will be PATCH
• Versions are bumped either automatically or manually via bump-my-version (except the iom-helm-chart)
• To keep the develop branches in sync with main we either:
  • use the automated release process where a sync pull requests are created for main -> develop/*
  • use history rewriting based on git rebase and git push --force-with-lease (see Rebasing)
• Conventional commit messages are desired

In our helm-chart repo we have to have more than one develop branch. This is due to the fact that more than one team is working on new pre-production grade code. A decision what to release when can only be made within a team context. As well as cross feature testing, documentation and version bump planing (e.g. major, minor or patch increment). If every team would be merging new features into one develop branch, that (team) decision would not be possible. Simply because the order of commits is then erratic.

We use the same meaning of feature branch as Git Flow has established it except for the merge strategy. When some feature branch is ready to be merged, the author creates a pull request with develop/<your-team> as selected target branch.

1. Create a new pull request from the list of branches
2. Select your target branch. If you're working on a forked repo, make sure to select the correct target repo.
3. Please choose a title accoding to conventional commit messages.
4. Fill out the Pull Request template.
5. Please select a person to review changes introduced by your PR
6. Before merging make sure that the base of your branch is still an existing commit in your designated target branch. Have a look in chapter "Rebasing" for details on how to execute that.
7. Once the reviewer approved the changes you're free to merge into the designated develop/<your-team> branch. Select Rebase and merge or Squash and merge depending on your flavor to retain your feature branch commits or to squash them into one commit. ATTENTION!: Each commit shall follow the rules of our defined contribution guideline.

The main (or master) branch contains production ready code. It receives that code from the team specific develop/<team> branches or from any other hotfix branch. We have protected the 'main' branch and only allow pull requests to introduce changes. The steps to create a PR, review and prepare the merge are explained in chapter "Feature Branch". There is one tiny difference. Since main contains production ready code, that code must be released in order to be consumed. Helm Charts contain their version number as part of Chart.yaml. Consequently some automatic version bumping mechanism can exists when merging a PR into main. That mechanism needs the input of the PR's author as to decide which part of the semantic version number must be incremented. So please, before merging the PR into main it has to be labeled with 2 labels. One reflecting the chart that has been changed (automatically detected) and another label for the version bump.

** Version Bump Label: **

• major
• minor
• patch

** Chart Label: **

• icm
• pwa
• iom

The chart label is automatically detected when creating the pull request based on the changed paths. Please refer to labeler.yml to find the current configured mapping.

The history of the main branch shall be readable and consistent. Therefore PRs could only be merged via "Rebase and merge"-method. Features, Bug- and Hotfixes shall be always squashed into one explanatory commit before bringing them into the main/develop branch.

The process of rebasing branches in git moves the foundation (base) of a branch to another commit within the same repository. Because that changes the chain of commits introduced in a branch (remember that a commit object always has a reference to its predecessor) a simple git push to the upstream repo doesn't work. You need to force push. Replacing the upstream state of the branch with your local (rebased) version of that branch. A fair amount of communication within the team is required to avoid loosing commits of others.

To rebase a Feature Branch with team specific Develop you have to:

git checkout develop/<your-team>
git fetch origin
git rebase
git checkout <your-feature-branch>
git rebase develop/<your-team>
<Resolve possible conflicts>
git push --force-with-lease

To rebase a team specific Develop with Main Branch you have to:

git checkout main
git fetch origin
git rebase
git checkout develop/<your-team>
git rebase main
<Resolve possible conflicts>
git push --force-with-lease