1. Git Workflow
2. Overview
3. Branches
   • Trunk Branch
   • Feature Branches
   • Project Branches
   • Staging/Release Branches
   • Official 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

Branch Conventions

Trunk Branch

Trunk-based development (TBD) is a branching model for software development where developers merge every new feature, bug fix, or other code change to one central branch in the version control system. This branch is called “trunk”.

The mainline branch named "main", and it is the default branch that everyone interally does development, implementation, testing on.

Branch Example:

• main

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 trunk 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 from the trunk for each new feature or fix and then merged back into the trunk once the feature is completed and tested.

Branch Example:

• develop/CETC-75425-maximizedialog
• develop/CETC-99387-backup
• private/einal/excel-api-test

Project Branches

A longer-lived branch used for a project or specific teams branched out from trunk.
Workflow in these project branches is governed by the process of the project team, but usually team members work in feature branches that get merged into project branches.

Branch Example:

• project/CETC-83528-gfx-3
• project/CETC-78767-flooring

Staging/Release Branches

A Staging Branch is created for each future patch/release that are planned, and all BETA/RC/Official builds are based on this branch. Automated Builds from this branch.

It is created by branching off the trunk branch.
Only used by Configura's internal rapid response team.

Branch Example:

• release/13.5/major
• release/13.5/patch1
• release/13.5/minor
• release/13.5/patch2

Official Branches

Official branches house the actual release or beta our customers experience. These branches are merged in from staging branches during publication.

All production/3rd party should use this.

Branch Example:

• version/13.5/official
  This branch will contain the latest code released to our user base.
  
  
• version/13.5/beta
  • This branch holds the code for the next release major or minor once it's available in a publicly shared BETA box.
  • Shared with partners - this is what you should use for migration.

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