Integration Practices & History Hygiene

Merge vs. Rebase

merge creates a new merge commit preserving both parent lineages; rebase replays a branch's commits on top of the target, producing linear history but rewriting commit hashes. Never rebase commits that have already been pushed and might be based on by others — it rewrites their hashes, causing confusing divergence for anyone who already pulled them.

# Safe — rebasing a LOCAL, not-yet-shared feature branch onto latest main
git checkout feature/search
git fetch origin
git rebase origin/main       # replays your commits on top, resolves conflicts incrementally
git push --force-with-lease  # only safe because no one else has based work on this branch

# rerere — Git remembers how you resolved a conflict and reapplies it
# automatically if the identical conflict recurs on a later rebase
git config rerere.enabled true

Pull Requests & Branch Protection

A pull request proposes merging one branch into another, giving space for review, discussion, and CI checks before the merge lands — a platform feature, not a core Git concept. Branch protection rules enforce that main stays deployable: required passing checks, minimum approvals, no direct pushes.

# GitHub branch protection (Settings > Branches > main)
# - Require a pull request before merging
# - Require status checks to pass (CI) before merging
# - Require at least 1 approving review
# - Require branches to be up to date before merging
# - Do not allow force pushes to this branch

Merge Strategies & Commit Hygiene

Squash merging combines every commit from a feature branch into one commit on the target branch — a clean, linear history at the cost of losing intermediate commits. Rebase-merge keeps individual commits but rewrites them onto the target. A regular merge commit preserves full branch history but makes git log/git bisect harder to read across many merges.

# Conventional Commits — structured messages tooling can parse
feat: add search autocomplete
fix: correct off-by-one in pagination
chore: bump dependency versions
docs: update README setup steps

# Tools like semantic-release read these prefixes to auto-bump
# patch/minor/major versions and generate a changelog.

Tagging Releases

git tag -a v1.2.0 -m "Release 1.2.0"
git push origin v1.2.0

# Tags are meant to be immutable once published — moving a tag after the
# fact is bad practice since CI/CD and rollback tooling may already target it.