Wann rebasest du und wann mergest du?

Rebase deinen eigenen Feature Branch auf den Main Branch, um die History linear zu halten und Konflikte in kleinen Dosen vor dem Review zu lösen. Merge, wenn du diesen Branch in einen geteilten Branch integrierst, und rebase nie einen Branch, den andere schon gepullt haben, denn geteilte History umzuschreiben zwingt alle in eine Wiederherstellung. Kurz: Rebase private Arbeit, merge öffentliche Arbeit, und squashe, wenn die Commit-History künftigen Lesern nichts bringt.

Meine Regel ist: private History rebasen, geteilte History mergen. Solange ein Feature Branch meiner ist, rebase ich ihn regelmäßig auf main, weil das den Diff ehrlich hält und ich Konflikte lieber in drei kleinen Dosen habe als einmal riesig am Ende. Wenn er nach main geht, merge ich, meistens gesquasht, weil niemand, der in sechs Monaten das Log liest, meine fix typo Commits sehen will. Was ich nicht mache, ist einen Branch zu rebasen, den jemand anderes gepullt hat, denn Rebase verschiebt keine Commits, es erzeugt neue mit neuen Hashes, und die Kopien der Originale bei allen anderen sind damit verwaist. Das bedeutet einen Force Push und dass jemand Arbeit verliert. Ich musste einen Kollegen schon einmal durch das Reflog führen, um genau daraus zu retten. Über die Regel hinaus mache ich, was das Team ohnehin macht, denn eine konsistente History, die alle verstehen, schlägt meine persönliche Vorliebe, und das ist kein Hügel, auf dem man im Code Review sterben sollte.