The Ultimate Guide to Git Branching and Merging Strategies#

1. Feature Branching#

This is a fundamental strategy where all development work on a specific feature, bugfix, or experiment takes place on a dedicated branch separate from the main branch.

• Workflow:
  1. Create a new branch from the main or develop branch for each new unit of work (feature, bugfix, etc.).
  2. Develop the code and make commits on the feature branch.
  3. Push the feature branch to the remote repository.
  4. Open a pull request to merge the feature branch back into the main branch (or develop).
  5. After review and approval, the feature branch is merged.
  6. The feature branch can then be deleted.
• Pros:
  • Isolation: Work on a feature does not disrupt the main codebase.
  • Collaboration: Multiple developers can work on different features simultaneously.
  • Code Review: Pull requests facilitate review before integration.
• Cons:
  • Integration frequency: If feature branches are long-lived, merging can become difficult.
  • Potential for merge conflicts if not kept up-to-date with the target branch.
• Suitability: Highly flexible, suitable for most teams and projects, especially when combined with pull requests.

2. Gitflow Workflow#

Introduced by Vincent Driessen, Gitflow is a more structured approach designed around project releases. It defines specific roles for different branches:

• main (or master): Stores the official release history. Commits on this branch are tagged with release numbers.
• develop: Serves as an integration branch for features. All feature branches are merged into develop.
• feature branches: Branch off from develop, contain work for a specific feature, and merge back into develop.
• release branches: Branch off from develop when preparing a new release. Only bug fixes and minor release-related tasks are done here. Merged into main and develop upon release completion.
• hotfix branches: Branch off directly from main to quickly address critical bugs in production. Merged into both main and develop.
• Workflow: Involves moving changes between these specific branches in a defined flow.
• Pros:
  • Well-defined structure: Clear roles for branches simplifies understanding the project state.
  • Manages parallel development, releases, and hotfixes effectively.
• Cons:
  • Complexity: More branches and rules can be challenging for smaller teams or simpler projects.
  • Can be cumbersome for continuous delivery models due to the focus on distinct releases.
• Suitability: Projects with cyclical release processes, versioned software, or those requiring strong separation between development lines.

3. GitHub Flow#

A simpler, lightweight alternative to Gitflow, popularized by GitHub. It is centered around the main (or master) branch and feature branches, heavily relying on pull requests.

• Workflow:
  1. A single main branch (main or master) which is always deployable.
  2. Create a new branch from main for any new work.
  3. Commit changes to the feature branch and push frequently.
  4. Open a pull request from the feature branch to main to propose changes.
  5. Discuss and review the code in the pull request.
  6. Once approved and CI tests pass, merge the pull request into main.
  7. Deploy main immediately or very frequently.
• Pros:
  • Simplicity: Fewer branches and rules than Gitflow.
  • Designed for continuous delivery: Focus on keeping the main branch deployable at all times.
  • Strong emphasis on pull requests for collaboration and quality.
• Cons:
  • Less structured for managing multiple versions or complex release cycles compared to Gitflow.
• Suitability: Web applications, projects with frequent deployments, teams practicing continuous integration and continuous delivery (CI/CD). Data suggests that organizations practicing CI/CD deploy code significantly more often and have lower change failure rates.

4. GitLab Flow#

Extending GitHub Flow, GitLab Flow adds environment branches (e.g., production, staging, pre-production) and leverages GitLab’s CI/CD features.

• Workflow (Simplified):
  • Feature branches are created from and merged back into the main branch (similar to GitHub Flow).
  • Changes are propagated from main to environment branches (main -> staging -> production) via merges, often triggered automatically by CI/CD pipelines upon successful tests.
  • Hotfixes can be applied directly to production and then merged back.
• Pros:
  • Simple feature workflow while managing different environments.
  • Integrates well with CI/CD pipelines for automated deployments.
  • Clearly defines the state of code in various environments.
• Cons:
  • Can become complex if many environments or different promotion rules are needed.
• Suitability: Projects with multiple deployment environments, teams using GitLab’s integrated CI/CD, and those needing a balance between simplicity and environmental structure.

5. Trunk-Based Development (TBD)#

An approach where developers merge small, frequent commits into a single shared branch (the “trunk,” often main or master). Feature branches are very short-lived, often existing for only a few hours or a day.

• Workflow:
  1. Developers work directly on the trunk or create extremely short-lived branches.
  2. Commits are small and frequent.
  3. Changes are merged back into the trunk multiple times a day.
  4. Feature flagging is often used to hide incomplete features within the trunk.
• Pros:
  • Minimizes merge conflicts due to small, frequent merges.
  • Enables rapid iteration and continuous integration.
  • Reduces complexity associated with long-lived branches.
• Cons:
  • Requires a high level of discipline, strong test coverage, and feature flagging.
  • Incomplete features can potentially break the build if not properly hidden or tested.
• Suitability: High-performing teams focused on rapid delivery, continuous integration, and continuous deployment. Studies consistently show that elite performing teams prioritize practices like TBD and CI/CD.

1. Merge Commit (Default)#

This is the standard way git merge <branch-name> works.

• Git finds the common ancestor of the two branches being merged.
• It creates a new commit (a merge commit) that combines the changes from the tip of both branches.
• The merge commit has two parent commits, representing the histories of the branches being merged.
• The history of both branches is preserved.

1
# Assuming currently on 'main' branch
2
git merge feature/my-feature

• Pros: Preserves the exact history of when and how branches were merged.
• Cons: Can create a cluttered commit history with many merge commits, especially in busy repositories.

2. Fast-Forward Merge#

If the target branch (e.g., main) has not diverged from the source branch (e.g., feature/my-feature) since the source branch was created (i.e., the target branch’s tip is an ancestor of the source branch’s tip), Git can perform a fast-forward merge.

• Instead of creating a merge commit, Git simply moves the target branch pointer forward to the tip of the source branch.
• This results in a linear history.

1
# Assuming currently on 'main' branch
2
# If 'main' hasn't received commits since 'feature/my-feature' was branched off
3
git merge feature/my-feature # This will perform a fast-forward merge by default

• Pros: Creates a clean, linear history.
• Cons: Loses the historical context that a feature was developed on a separate branch; it looks like all commits happened directly on the target branch. Can be prevented using --no-ff.

3. Squash Merge#

This technique combines all the commits from a feature branch into a single new commit on the target branch.

• Git takes all the changes from the source branch and presents them as a single change set.
• A single new commit is created on the target branch containing all these changes.
• The individual commit history of the source branch is not preserved on the target branch.

1
# Assuming currently on 'main' branch
2
git merge --squash feature/my-feature
3
# After this, you need to commit the changes presented by the squash merge
4
git commit -m "Feature: Implement user authentication"

• Pros: Keeps the target branch history clean and concise, summarizing a whole feature in one commit. Useful for merging feature branches where individual commits are messy.
• Cons: Loses the detailed commit history of the feature branch. Can make debugging difficult if needing to bisect individual changes within the squashed feature.

Rebasing (An Alternative to Merging)#

Rebasing is often confused with merging but serves a different purpose: rewriting commit history.

• git rebase <target-branch> takes commits from the current branch, copies them, and places them on top of the latest commit of the target branch.
• This creates a linear history, making it look like the work on the current branch started after the target branch’s latest commits.

1
# Assuming currently on 'feature/my-feature' branch
2
git rebase main
3
# This moves the commits from 'feature/my-feature' to be on top of the latest 'main' commit
4
# Then, when you merge feature/my-feature into main, it will be a fast-forward merge

• Pros: Creates a clean, linear history, avoiding merge commits. Can make history easier to read.
• Cons: Rewrites history. This is problematic if the branch being rebased has already been pushed to a shared remote repository, as it can cause conflicts for other collaborators. Rule of thumb: Do not rebase branches that others are working on.
• Suitability: Cleaning up commits on a local, private branch before merging. Integrating changes from the target branch into a feature branch before creating a pull request.