Major difference between git rebase & git merge -

after lot of search on internet, know have been discussed in length. , think now. want confirm, if major difference in using git-rebase vs git-merge linear/clean history git-rebase against tractability of git-merge? or there else team miss out, if use git-merge?

there recommendation, if team not aware of intricacies of rebase, go merge

there many items consider. i'm not sure complete list ("complete" hard).

1. merge conceptually simple, yet full of tricky corner cases. understand well, must understand how git's commit graph works.

   there several parts each merge:

   • identifying 2 specific commits, branch tips l ("left" or "local" or --ours) , r ("right" or "remote" or "other" or --theirs). these commits contain complete snapshots of source, git commits do.
   • identifying merge base commit of these 2 commits. uses commit graph, , scary-sounding graph theory find so-called lowest common ancestor or lca. if sit down , draw graphs (or stand @ whiteboard , draw them), it's matter of coloring in lines. colors first meet up, that's merge base.
   • computing 2 diffs: 1 base l, , second base r. turns each of 2 commits "change-sets": has changed in l, compared base? has changed in r, compared base?

   • combining these 2 changesets. base-to-l change affects file f, if base-to-r not affect f @ all, we're fine. if base-to-r affect f, changes f in different areas of f, or in same location? if in same location, same change? if so, take 1 copy of change. if they're in different locations, combine both changes.

     in other words, if 1 of l or r affects f, take l or r version wholesale. otherwise, combine changes. if of these changes conflict, declare merge conflict. repeat files in 2 change-sets, , keep totally-unmodified files same in base.

     the result combined set of changes, , long there no conflicts, git can make new commit. new commit can merge commit, i.e., record both parents l , r, commit graph records act of merging. normal case normal (real) merge.

   
   besides above, git has calls fast-forward merges (which not merges @ all), , squash merges (which merge work of combining changes, make ordinary, non-merge commit). means aside merge being conceptually simple (but above corner case issues), need recognize git has both merge-as-a-verb, change-set-combining thing, , merge-as-a-noun, "a merge" means "a merge commit": commit records 2 parents.

2. before can understand rebase, need understand cherry-picking. requires understanding how git's commit graph works. each cherry-pick copies commit, computing change-set commit's snapshot. change-set diff of parent of commit, vs commit ("what changed in commit?"). git applies change-set other commit, using same merge process—merge verb—as git merge. merge base of cherry-pick little bit confusing, in practice works.

3. rebase consists of automated cherry-picking of set of commits copy, followed branch-label movement, abandon original (pre-copy) commits in favor of new (copied) commits.

   thus, understand rebase, need understand cherry-pick, means need understand merge. need know how git's branch labels work, need know understand git reset , git branch -f, , means force-push. understand how git chooses set of commits copy, need understand git's commit graphs—but need understand how git merge finds merge base, although might seem difficult and/or scary, it's know point.

in end, it's not difficult: there several large graph-theory-related hurdles have clear simultaneously. is, however, undeniably true git rebase more complex git merge, if because git rebase uses of git merge via git cherry-pick.

because rebase copies commits (and abandons originals in favor of new copies), it's best avoid doing anywhere people might care hash ids of original commits. (commits uniquely identified hash ids.) short-cut, can use simple concept: if commit unpublished, know hash id, therefore no 1 else can possibly care hash id.

in typical setup, means if have not used git push publish commits, safe use git rebase on them; if have used git push, it's not safe: else has them (because pushed them) has know how handle copy-and-abandon thing.