Getting solid at Git rebase vs. merge -- Medium

Getting solid at Git rebase vs. merge — Medium

A git merge should only be used for incorporating the entire feature set of branch into another one, in order to preserve a useful, semantically correct history graph. Such a clean graph has significant added value.

All other use cases are better off using rebase in its various incarnations: classical, three-point, interactive or cherry-picking.

Medium is an awesome platform, but it lacks a few tweaks for proper code-/tech-related content just now, chief of which is inline monospace formatting with no typographical replacements in them (syntax-highlighted code blocks would be nice too, but I didn’t need these here). So I resorted to italics for commands, branch names, etc. This seems to remain legible, at any rate, this was the best I could do!

A clean, usable history that makes sense

One of the most important skills of a Git user lies in their ability to maintain a clean, semantic public history of commits. In order to achieve this, they rely on four main tools:

• git commit --amend
• git merge, with or without --no-ff
• git rebase, especially git rebase -i and git rebase -p
• git cherry-pick (which is functionally inseparable from rebase)

I often see people put merge and rebase in the same basket, under the fallacy that both result in “getting commits from the branch across in our own branch” (which is, by the way, incorrect).

These two commands actually have hardly anything in common. They have entirely separate purposes and, indeed, are not supposed to be used for the same reasons at all.

I shall try to not only highlight their respective roles, but also equip you with a few reflexes and best practices so you can always produce a public history that is both expressive (concise yet clear) and semantic (viewing the history graph reflects the team’s goals in an obvious way). A top-notch history adds significant value to the whole team’s work, be it contributors coming in for the first time or getting back after a while away, project leads, code reviewers, etc.

Read full article from Getting solid at Git rebase vs. merge — Medium