Git Deep Dive
Merge or rebase?
Both produce the same files. They differ in what history remembers, and that is the whole decision. Merge keeps the fork visible forever: you can always see that these five commits were developed in parallel and joined on a Tuesday. Rebase erases the fork and pretends the work happened in a straight line, which is easier to read but is a rewritten story.
merge
- History is truthful, including the mess
- Safe on branches other people pulled
- Extra merge commits clutter the log
- Default for main and release branches
rebase
- Linear, readable, easy to bisect
- Every replayed commit gets a new hash
- Forces a push with lease on shared branches
- Fine on your own unpushed branch
The workable team rule is short: rebase your own branch before review, merge it after. Everything else is preference.
The three resets
Reset always moves the branch pointer. The flag decides how far the damage travels.
| Flag | Branch pointer | Staging area | Your files |
|---|---|---|---|
| --soft | moves | kept, still staged | untouched |
| --mixed | moves | cleared | untouched |
| --hard | moves | cleared | overwritten — uncommitted work is gone |
Only the last row destroys anything, and only what was never committed. Commits themselves survive in the reflog for 90 days, which is why the recovery step in the lab works.
Reading conflict markers
A conflict block has three parts. Everything between <<<<<<< and ======= is the side you are merging INTO — your current branch, labelled HEAD. Everything from ======= to >>>>>>> is the incoming side.
<<<<<<< HEAD
burst: 40
window_seconds: 60
=======
bucket_capacity: 100
refill_per_second: 10
>>>>>>> feature/rate-limitYou are not restricted to picking a side. The correct resolution here keeps both settings. Once the file reads the way it should and the markers are gone, git add is what marks it resolved — there is no separate resolve command, which is exactly why marker text sometimes reaches production. A CI grep for <<<<<<< costs nothing and catches it.
Commands worth having in muscle memory
# What actually happened, in one line each
git log --oneline --graph --all --decorate
# Undo the last commit but keep the work staged
git reset --soft HEAD~1
# Undo a commit that is already pushed — safely, with a new commit
git revert <sha>
# Where was HEAD before I broke everything?
git reflog
# Push a rebased branch without clobbering someone else's push
git push --force-with-lease
# Which commit introduced the bug?
git bisect start && git bisect bad && git bisect good <sha>
