What does git pull --rebase do, and why do many teams prefer it?
It fetches remote changes and replays your local commits on top of them instead of creating a merge commit. The result is a linear history without noisy 'Merge branch main' commits.
Explain it simply
You and a teammate both committed to the same branch. A normal git pull joins the two lines with a merge commit, and after a few days the log is full of 'Merge branch main of github.com...' entries that carry no meaning.
git pull --rebase fetches first, then lifts your unpushed commits and sets them on top of the new remote ones. History reads as one straight line. Conflicts, if any, are fixed per commit as in any rebase. Make it the default with git config --global pull.rebase true. Risk is small because you only rewrite your own unpushed commits.
Example
git pull --rebase origin main
# same as: git fetch && git rebase origin/main
git config --global pull.rebase trueWhat to say in the interview
"git pull --rebase fetches and then rebases my local commits onto the updated remote branch, avoiding extra merge commits and keeping history linear. It only rewrites my own unpushed commits, so it is safe, and I set pull.rebase to true globally."