Ablauf Rebase featureA auf master:

Nur machen, wenn niemand anders auf demselben Feature-Branch FeatureA arbeitet!

git checkout master
git pull
git checkout featureA
git  pull
git rebase master
git push --force-with-lease

git push ohne –force würde verweigert, weil, nach dem lokalen Rebase, der Commit-Ast unter dem lokalen Branch-Pointer „featureA“ nicht „fast forward“ auf den Zweig unter remote/FeatureA abbildbar ist.

Rebasing ins Remote-Repo zieht allen anderen, die auf demselben Branch arbeiten denselbigen unter den Füssen weg! Wenn diese Kollegen dann pushen wollen, findet der push einen Remote-Branch vor, der nur elend weit zurück liegend einen gemeinsamen Vorgänger mit der lokalen Version des Branches hat. Eine gewaltige Merge-Übung ist notwendig!

Man stelle sich folgendes Schreckens-Szenario vor:

1. Ausgangslage Commit-History:

M1 -- M2 -- M3(master)
\-- F1 -- F2 -- F3(featureA)

2. Entwickler A macht Rebase mit Force push:
Situation Remote-Repo:
M1 -- M2 -- M3(master) -- F1c -- F2c -- F3c(featureA)

3. Entwickler B hat weitere Änderungen an featureA gemacht:
M1 -- M2 -- M3(master)
\-- F1 -- F2 -- F3 -- F4(featureA)
Möchte er diese nun pushen, dann müsste er zuerst F1 bis F3 mit F1c bis F3c mergen. Denn: Der gemeinsame Vorfahre von remote/featureA und local/featureA ist M1. Alles, was von M1 aus geht muss gemerged werden.

Schlimmer allerdings wäre es, wenn Entwickler B seine Änderung (F4) schon eingecheckt hätte, und B hätte (ohne vorherigen pull) sein featureA mit –force remote rebased. F4 ginge verloren, da kein Branch mehr darauf zeigen würde (–> Garbage Collection)!
Diesbezüglich ist –force-with-lease vorzuziehen, da dann beim Push geprüft wird, ob inzwischen remote nicht weitere Commits auf dem Branch angelegt worden sind.