1. Git Workflow
2. Overview
3. Branches
   • Release branch – versionX.Y
   • Beta branch(es) - versionX.Ybeta(Z)
   • Develop branch – versionX.Ydevelop
   • Feature Branches
   • Hotfix Branches
4. Recommended Practices

Git Workflow

This is a brief description of the workflow in Git. A basic understanding of Git is necessary to comprehend this information. For reference, see https://git-scm.com/docs/gittutorial.

Overview

Branches

Release branch – versionX.Y

The release branch contains the state matching the current release. Code should never be merged to the release branch before it has been released to users. The name of the release branch should be versionX.Y where X.Y is the current CET major version number, e.g. 9.5.

Beta branch(es) - versionX.Ybeta(Z)

Beta branches contain the commits slated to be included in an upcoming build. There are three options when updating the beta branch with new code:

• Merge in the develop branch
• Cherry pick a single commit from the develop branch
• Commit straight into the beta branch.

The preferred method is a merge from the develop branch (option 1); this will pull in all commits from the develop branch into the beta branch. If there is a need to extract code from the develop branch without merging the complete history of the develop branch (i.e merge it) a cherry-pick can be used. Committing straight into the beta branch (option 3) should be reserved for simple fixes. Should work occur on the beta branch, it will need to be merged into the develop branch as well.

Once the beta branch is in a state considered fit, a beta release is built on the beta branch. Once the code is officially released, the beta branch is then merged into the release. In some cases, multiple beta branches might be needed. Multiple beta branches allow developers to work on multiple betas in parallel. However, we recommend starting with just one.

The beta branch should be named versionX.Ybeta. In the case of multiple branches, a numerical postfix is recommended: versionX.Ybeta1, versionX.Ybeta2, etc.

Develop branch – versionX.Ydevelop

The develop branch spans across all beta branches. Each feature branch will be branched out from the develop branch.

Feature Branches

A big strength of Git is the ability to use and easily create and merge feature branches. Feature branches are short-lived branches whose purpose is to contain changes necessary for a single feature. Their lifespan usually ends once the feature branch is merged back into the develop branch. Several feature branches can exist in parallel and we strongly recommend the usage of feature branches. Ideally the name of a feature branch should describe what is being changed. Feature branches should be branched out for each new feature or fix and then merged back once the feature is completed and tested.

Hotfix Branches

If a hotfix needs to be released, a hotfix branch should be branched out from the release branch. The fix is then pushed to the hotfix branch where the build is made. Once released, the hotfix branch is merged to both the release and the patch branch. The naming of a hotfix branch should be of similar character to a feature branch.

Recommended Practices

Do:

• Delete feature branches after they are merged

Do NOT:

• Perform rebases, use merges
• Perform fast-forwarding Git merges
• Squash commits
• Perform force pushes
• Do not merge unreleased code to versionX.Y
• Perform active development in both Perforce and Git in parallel
• Use cherry-picks as part of the normal workflow

As many of the discouraged actions are typically aimed at getting a cleaner commit history we would explicitly like to mention first parent traversal. If first parent traversal is requested, the displayed history should map well against a “common sense” understanding of the commit history.

This option is called Merges within CET Operator. On the command line, many commands can take the –first-parent option, for example: git log --first-parent