GitHub Tutorial
- 1. Introduction to GitHub
- 2. Account Setup & SSH
- 3. Repository Management
- 4. Remotes & Syncing
- 5. Collaborating Via Branches
- 6. Forking & Pull Requests
- 7. Code Reviews & Branch Protection
- 8. Merge Strategies
- 9. Issues & Projects
- 10. Markdown & Project Wikis
- 11. Deploying to GitHub Pages
- 12. CI/CD with GitHub Actions
- 13. Packages & Releases
- 14. Gists & Discussions
- 15. Security & Dependabot
8. Merge Strategies
Once a Pull Request has been fully reviewed, all tests have passed, and approval has been granted, it is time to merge the changes into your main branch. GitHub offers **three different merge strategies** to help you maintain your project's commit history structure. In this chapter, we will study these strategies and when to use them.
The 3 Merge Options on GitHub
When you click the drop-down arrow on the green "Merge pull request" button on a PR page, you can choose from three options:
1. Create a Merge Commit (Default)
This performs a standard git merge. All commits from the feature branch are added to the target branch history, and a dedicated **Merge Commit** is created to join the branches.
- Pros: Preserves the full, unaltered history and chronological context of all developer commits.
- Cons: If your team works on many small features, your commit logs can quickly become cluttered and difficult to navigate.
2. Squash and Merge (Highly Recommended for Clean History)
This strategy takes **all commits** from the feature branch, combines them into **one single commit**, and applies it to the target branch.
- Pros: Keeps your main branch history clean, linear, and readable. Wipes out messy WIP commits (like "Fix typo", "Debugging", "Add missing bracket").
- Cons: Erases the individual granular commit history of the feature branch.
3. Rebase and Merge
This strategy takes each individual commit from the feature branch and applies them **individually** onto the target branch's latest commit, without creating a merge commit. It creates a perfectly straight, linear timeline.
- Pros: Retains granular commit details while avoiding muddying the logs with merge commits.
- Cons: Rewrites commit hashes. Requires careful handling if branches diverge.
Comparing the Strategies
| Merge Strategy | New Commit Created? | Granular History Kept? | Timeline Structure |
|---|---|---|---|
| Create a Merge Commit | Yes (1 merge commit) | Yes (all commits) | Divergent (branching history lines visible) |
| Squash and Merge | Yes (1 combined commit) | No (condensed) | Linear (straight line) |
| Rebase and Merge | No | Yes (all commits) | Linear (straight line) |
Automatic Branch Deletion
Once a pull request is merged, the feature branch is no longer needed. To keep your repository tidy, you can configure GitHub to automatically delete branches upon successful merges:
- Go to your repository and click Settings.
- On the **General** settings tab, scroll down to the "Pull Requests" section.
- Check the box for "Automatically delete head branches".
