Video narration
If both git merge and git rebase bring main's changes into your feature branch, why does Git care which one you choose? Imagine editing a shared document while someone else updates the master copy. Your branch is your version; main is the newer master. Both bring the newer work into your document, but they record the edit history differently. With git merge, Git joins your timeline to main's. Your separate edits stay visible, and a merge commit connects them-like marking where two document versions came together. With git rebase, Git takes your edits and replays them after the newest main. The document ends up together too, but the history reads as one straight sequence: a linear history, not two lines joining. The important difference is what happens to the commit history. So, a joining point means merge; one straight line means rebase. In the shared document, merge keeps both edit paths, while rebase places your edits after the latest master.