Merge vs. Rebase
Bothgit merge and git rebase integrate changes from one branch into another, but they produce different history shapes and require different precautions.
How They Differ
git merge creates a new merge commit that has two parents — the tip of your current branch and the tip of the branch you are merging. The branch history is preserved exactly as it happened. You can see when a feature branch diverged, what happened on main in the meantime, and exactly where the two lines of work came together.
git rebase takes the commits from your branch and replays them one by one on top of the target branch, as if you had started your work from the current tip of that branch. The result is a perfectly linear history — no merge commits, no fork-and-join shape — but the commit SHAs change because the commits are rewritten.
Interactive Rebase
Interactive rebase (-i) lets you rewrite commits on your branch before sharing them — squash trivial “fix typo” commits, reorder commits for logical clarity, or split a large commit into smaller ones.
Pros and Cons
When to Use Each
- Use merge for integrating
maininto a long-lived feature branch when you want an honest record of the merge point, or when merging pull requests on GitHub/GitLab (the PR merge creates a documented integration point). - Use rebase to update a local feature branch with the latest
mainbefore opening a PR, and to clean up messy commit history (squash fixups) before the PR is reviewed.
Common Workflow
The feature branch workflow is the standard for teams using pull requests:Commit Message Best Practices
Good commit messages makegit log useful for debugging and git bisect effective for tracking regressions. Follow the Conventional Commits format:
feat (new feature), fix (bug fix), refactor, test, docs, chore (build scripts, dependencies), perf.
Tags
Tags mark specific commits as significant — typically releases. Unlike branches, tags do not move as new commits are added.Creating Tags
Git supports two tag types: Lightweight tag — just a named pointer to a commit. No metadata.Semantic Versioning
Tag releases following Semantic Versioning:vMAJOR.MINOR.PATCH
- PATCH (
v1.0.1): Backwards-compatible bug fixes. - MINOR (
v1.1.0): New backwards-compatible features. - MAJOR (
v2.0.0): Breaking changes.
Tagging a Past Commit
Pushing and Managing Tags
git push does not push tags by default.
Working with Remote Repos
Cloning
Fetch vs. Pull
Dealing with Conflicts
Useful Commands
Cherry-Pick
Apply a specific commit from another branch onto the current branch without merging the entire branch.main immediately without waiting for the full PR.
Stash
Temporarily save uncommitted changes so you can switch branches without committing half-done work.Reset vs. Revert
Use
git revert when undoing commits that are already on a shared branch. Use git reset only on commits that are purely local. git reflog can recover commits deleted by --hard reset, but only for 30 days and only locally.