Q: In one paragraph: what does `git pull` actually do, and why do some teams prefer `git pull --rebase`?

git pull is two commands stitched together: git fetch (download new commits and tags from the remote into origin/) followed by git merge origin/ into your current branch. If your local branch has commits the remote doesn't, that merge produces a merge commit ("Merge branch 'main' of …"), which clutters history with bookkeeping commits that don't represent real work. git pull --rebase replaces the merge step with a rebase: your local commits are temporarily set aside, the new remote commits are applied first, and then your commits are replayed on top. Result: a clean linear history with no noise commits. Many teams set git config --global pull.rebase true so this becomes the default. The tradeoff is that rebase rewrites your *local* commit hashes — fine for unpushed work, but you should never rebase commits others have already pulled.