Git Internals and Workflows: Branching, Merging, and Rebasing

Common Mistakes Worth Remembering

• Rebasing a branch other people are already working from, forcing a confusing history reconciliation on everyone downstream.
• git push --force onto a shared branch instead of --force-with-lease, silently discarding someone else's pushed commits.
• Committing generated files or secrets because .gitignore wasn't set up before the first commit — once committed, they're in history until deliberately purged, not just deleted in a later commit.
• Confusing git fetch (downloads new data, doesn't touch your working files) with git pull (fetch + merge/rebase into your current branch immediately).
• Using git checkout for both "switch branches" and "discard file changes" and getting the two confused — git switch and git restore exist specifically to split these into two unambiguous commands.
• Assuming a reset --hard or a bad rebase permanently destroyed work, without checking git reflog first.
• Squashing or rewording commits with interactive rebase after they've already been pushed and pulled by someone else.
• Resolving a merge conflict by keeping one side wholesale without actually reading what changed on the other side — conflict markers exist because two people had good reasons for two different changes; the resolution should usually reflect both intents, not just pick a winner.

This site's own history is a real, if small, example of a lot of this in practice — see it at github.com/HMankad8/screening-platform. Practice the underlying data model — joins, transactions, and the queries these workflows ultimately protect — in SQL Fundamentals: Joins, NULL, Aggregate Functions, and Subqueries, or write and run real code in the code lab.