Git Workflow
1. GitHub Merge Strategies
| Feature | Merge Commit | Rebase | Squash Merge |
|---|---|---|---|
| History Style | Branched and verbose | Perfectly linear | Clean and linear |
| Commit Type | Keeps all commits, adds a new merge commit | Rewrites original commits, Moves commits to the tip of the base branch. | Condenses / folds all commits to one commit |
| Traceability | High (exact history) | Low (original context lost) | Low (individual steps lost) |
| Safety | High (non-destructive) | Do not use on public brach, its intended to be used on private branches only | Safe for final integration |
| Best For | Public/shared branches, Audit trails and complex feature integration where history matters. | Local/private cleanup, Maintaining a purely linear history without merge noise. | Finalising feature PR, Keeping the main branch clean and concise. |
What is the difference between merge commit and squash merge?
Summary of Differences
| Feature | Merge Commit | Squash Merge |
|---|---|---|
| History Style | Verbose and branched1 | Clean and linear5 |
| Commit Count | Keeps all original commits + 1 merge commit1 | Reduces all commits to exactly one4 |
| Traceability | High; sees every incremental change2 | Low; sees only the final result8 |
| Workflow | Standard non-destructive integration1 | Used for cleaning up “messy” histories |
2. Git Rebase Essentials
-
Definition: Re-applying commits on top of another base tip.
-
When to use: To keep your local feature branch up to date with
masterwithout adding unnecessary merge commits. -
When to avoid: Never rebase branches that others are working on. Rewriting history causes
git push --forcerequirements which can delete teammates’ work.
Git Rebase
Applies the commits of the current branch ahead of a specified branch to create a linear history?
The Golden Rule of Rebasing
You should **never use it on public branches
The most critical distinction is when to use each tool. The Golden Rule of Rebasing states that you should never use it on public branches.
- Why: Because rebasing creates new commits, if you rebase a shared branch like
main, your local history will diverge from everyone else’s. To fix this, teams must merge the diverged branches back together, leading to a confusing mess of duplicate commits. - Safe Usage: Rebasing is intended for private feature branches to clean up local history before a final merge. If a branch is public and being looked at by others, you must use
git mergeto incorporate changes.
Summary Comparison
| Feature | git merge | git rebase |
|---|---|---|
| History Style | Branched and verbose | Clean and linear |
| Commit Type | Creates a new merge commit | Rewrites original commits |
| Safety | High (non-destructive) | Risky if used on public branches |
| Traceability | High (exact history preserved) | Low (original context is lost) |
| Best For | Public/shared branches | Private/local branch cleanup |
| https://www.atlassian.com/git/tutorials/merging-vs-rebasing |