GIT Branching Strategies

Trunk-Based Development Workflow
Trunk-based development (TBD) is a branching strategy in which all developers make changes directly on the main branch, commonly referred to as the trunk, which holds the project’s deployable code.
Developers are encouraged to commit frequently and use feature toggles* and other techniques to manage changes that are not yet ready for release.

If a coding task requires an extended duration, possibly spanning over several days, the developer may create a branch from the main codebase, implement the necessary changes, and then merge it back into the main codebase once development is complete. However, the goal of trunk-based development is to minimize the use of feature branches and encourage developers to work collaboratively on the main codebase as much as possible.

Can lead to conflicts and integration issues if not managed properly, May not be suitable for larger teams or complex projects.

Feature toggles, also known as feature flags, can be used in software development to manage features that are not yet ready for release or that need to be shown only to specific users or groups. They function like a switch that can be turned on or off to enable or disable a particular feature in the codebase.

Feature Branching
Feature Branching is a commonly used workflow that involves creating a new branch for a specific feature or change in the codebase. This allows developers to work on the feature independently without affecting the main branch. When the feature is complete, it can be merged back into the main branch through a pull request. The pull request allows other team members to review the changes and suggest modifications or improvements before merging the feature into the main branch.

Git Flow
Git Flow is a branching strategy that uses two main long-lived branches — main and develop — that remain in the project during its entire lifetime.

Additionally, it employs several short-lived branches — feature, release, and hotfix — that are created as needed to manage the development process and deleted once they have fulfilled their purpose.

The main branch is the stable production-ready code and the develop branch is where all development takes place. Feature branches are used to develop new features or changes, release branches are used to prepare for a new release, and hotfix branches are used to quickly address critical issues in the production code.

Forking Workflow
The Forking Workflow is most often seen in public open source projects.

The Forking Workflow begins with an official public repository stored on a server. But when a new developer wants to start working on the project, they do not directly clone the official repository.

Instead, they fork the official repository to create a copy of it on the server. This new copy serves as their personal public repository — no other developers are allowed to push to it, but they can pull changes from it.

After they have created their server-side copy, the developer performs a git clone to get a copy of it onto their local machine. This serves as their private development environment, just like in the other workflows.

When they’re ready to publish a local commit, they push the commit to their own public repository — not the official one. Then, they file a pull request with the main repository, which lets the project maintainer know that an update is ready to be integrated. The pull request also serves as a convenient discussion thread if there are issues with the contributed code.

GitHub flow
The GitHub flow branching strategy is a relatively simple workflow that allows smaller teams, or web applications/products that don’t require supporting multiple versions, to expedite their work.

The main branch contains your production-ready code.

The other branches, feature branches, should contain work on new features and bug fixes and will be merged back into the main branch when the work is finished and properly reviewed.

Any code in the main branch should be deployable.
Create new descriptively named branches off the main branch for new work.
Commit new work to your local branches and regularly push work to the remote.
To request feedback or help, or when you think your work is ready to merge into the main branch, open a pull request.
After your work or feature has been reviewed and approved, it can be merged into the main branch.
Once your work has been merged into the main branch, it should be deployed immediately.

GitLab flow
GitLab flow branching strategy is similar to the GitHub flow branch strategy, the main differentiator is the addition of environment branches — ie production and pre-production — or release branches, depending on the situation.

GitLab flow has a main branch that contains code that is ready to be deployed. However, this code is not the source of truth for releases.

In GitLab flow, the feature branch contains work for new features and bug fixes which will be merged back into the main branch when they’re finished, reviewed, and approved.