- Git Workflow
- Recommended Practices
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.
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.
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.
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.
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.
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.
This branch will contain the latest code released to our user base.
- 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.
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.
- Delete feature branches after they are merged
- 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
Please sign in to leave a comment.