search

githubteacher / github-for-developers-sept-2015

practice repo for the Sept 29-30 GitHub for Developers class
12 stars 36 forks source link

git pull --rebase vs git merge #677

Closed metherton closed 9 years ago

saranicole commented 9 years ago

:+1:

PinoEire commented 9 years ago

In short, merge is non-destructive while rebase rewrites the very history, resulting in a cleaner and more linear project. Using rebase in conjunction with pull behaves like moving any local change on the current master HEAD.

cbrownrt commented 9 years ago

:+1:

saranicole commented 9 years ago

How does the history get rewritten? Does it erase the record of a particular commit?

sbrinkmeyer commented 9 years ago

:+1:

PinoEire commented 9 years ago

@saranicole Not quick to explain, better look at http://git-scm.com/docs/git-rebase :smile:

saranicole commented 9 years ago

@PinoEire cool, thank you

jaw6 commented 9 years ago

How does the history get rewritten? Does it erase the record of a particular commit?

This is a deep topic, but I'll try to explain here (in case we don't have time to cover it in depth during class). Git commits contain a pointer to the commit's parent (or, in the case of merge commits, parents). A branch is a pointer to the latest commit in a chain of commits pointing backwards in "time". rebase (and other commands that alter history, like reset) change history by altering the parent-commit pointer(s) and updating the branch pointer to point to the new parent-pointing commits.

There's a good explanation of this here and a visual in our (old) slide deck.