die Meisten code-Integrationen geschehen mit einer Zusammenführen, aber gelegentlich kann ein Entwickler will sich Ihr lokaler code holte mit dem master-branch durch ein rebase statt. In diesem Beispiel wird gezeigt, wie ein Zweig auf Master git rebase wird, anstatt den Merge-Befehl zu verwenden, und gleichzeitig auf die Auswirkungen einer git rebase auf Master-Operation hingewiesen.
Was bedeutet Git rebase auf master zu bedeuten?,
In diesem Tutorial nehmen wir den Zweig mit dem Namen develop und setzen ihn auf die Spitze des Masters.
Der Entwicklungszweig brach bei Commit C vom Master ab, sodass beide Zweige die Dateien gemeinsam nutzen a.html, b.html und c.html. Siehe das Bild unten, um dies zu visualisieren.
Seit der Verzweigung hat Master Commits D und E. Dies bedeutet, dass Master zwei Dateien hat, die develop nicht hat, nämlich d.html und e.html.,
So sieht das Git Repository vor einer git Rebase zum Master aus.
Außerdem gab es seit der Aufteilung zwei neue Commits im Entwicklungszweig, die die Dateien hinzufügten f.html und g.html. Dies sind Dateien, die der Entwicklungszweig hat, die der Masterzweig nicht hat.
So sieht das GitLab-Repository nach der Git-Rebase für den Master aus.,
Auswirkungen der Git-Rebase
Nach einem erfolgreichen Entwicklungszweig zur Master-Rebase:
- Die Dateien im Masterzweig ändern sich nicht
- Der Entwicklungszweig erfasst zusätzlich alle neuen Dateien des Masterzweigs
- Der Verzweigungspunkt des Entwicklungsstroms ändert sich.
- Es wird so angezeigt, als ob sich der Entwicklungszweig nach Commit E auf dem Masterzweig aufteilt.
- Vor der Rebase teilte sich der Entwicklungszweig bei Commit C vom Master.,
Git rebase auf master-Befehl, syntax
Der Vorgang, um eine Git rebase master ist geradlinig. Hängen Sie einfach den Namen des Quellzweigs und dann den Namen des Zweigs an das Ende des Befehls an rebase. Um rebase zu entwickeln, um den Befehl zu meistern, lautet der Befehl wie folgt:
git rebase master develop
Warnung: Es gibt einen Git-Rebase-Switch, von dem Entwickler manchmal fälschlicherweise glauben, dass sie ihn in den Befehl rebase aufnehmen müssen. Dadurch werden Commits verworfen und Dateien gehen verloren., Machen Sie nicht den Fehler, eine Git-Rebase-On-Operation durchzuführen.
Vor der Rebase hatte der Entwicklungszweig nur fünf Dateien.
Jeder Zweig besitzt fünf Dateien vor dem git rebase auf master-Betrieb.
Nach der Git-Rebase zum Master hat der Entwicklungszweig sieben Dateien. Es hat alle seine ursprünglichen Dateien beibehalten und zwei neue Dateien von der Spitze des Master-Zweigs erworben., Die Anzahl der Dateien im Masterzweig bleibt jedoch unverändert.
Nach der Git-Rebase von develop to master erfasst der Entwicklungszweig alle Master-Dateien.
Die Tatsache, dass der Master-Zweig keine Dateien aus dem Entwicklungszweig erworben hat, wirft häufig neue Git-Benutzer aus, aber dies ist das erwartete Verhalten. Eine Git-Rebase wird nicht zwischen Zweigen synchronisiert. Es fängt einfach einen Zweig mit den neuesten Änderungen von einem anderen auf.,
Die Anzahl der Dateien in entwickeln, erhöhen Sie nach dem git rebase master.
Fahren Sie mit Vorsicht fort
Wenn eine Git-Rebase auftritt, wird der Commit-Verlauf des Repositorys irreparabel geändert. Nach der Rebase in unserem Beispiel werden Commits F und G brandneue Commit-IDs zugewiesen und die alten Commit-IDs verworfen. Aus diesem Grund werden Rebased Commits häufig als F‘ und G ‚ markiert, um die Tatsache hervorzuheben, dass neue Commit-IDs zugewiesen wurden.,
Wenn Sie einen Zweig, der für einen anderen Entwickler freigegeben ist, neu erstellen und Ihre Änderungen an GitHub oder GitLab zurückschieben, wird ein anderer Entwickler auf eine Vielzahl oder Probleme stoßen, wenn er versucht, das Rebased Repository in seine lokale Entwicklungsumgebung zu ziehen. Commits, die sie lokal haben, sind auf der Fernbedienung verschwunden, und der entfernte Zweig hat einen inkompatiblen Verzweigungsverlauf. Wie Sie sich vorstellen können, kann das Rebasing eines gemeinsam genutzten Zweigs oder das Quetschen von Git-Commits Chaos anrichten.,
Rebase auf GitHub oder GitLab
Wenn Sie tatsächlich eine Rebase durchführen und versuchen, auf GitLab oder GitHub zu pushen, lässt der Server die Ausführung der Operation nicht zu. Um eine Neubasierung auf GitHub oder GitLab durchzuführen, muss ein Entwickler den Schalter –force zum Befehl git push hinzufügen, um die Annahme der Änderungen zu erzwingen.
git push origin --force
Ein GitLab oder GitHub rebase-push wird widersprochen, es sei denn gezwungen.,
Die akzeptierte Logik besteht darin, nur git rebase zu verwenden, um Zweige lokal in Ihrem persönlichen Arbeitsbereich zu mastern. Auf diese Weise wirken sich Ihre Git Clean Up-Befehle nicht auf andere aus. Führen Sie keine Git-Rebase zum Master für Zweige durch, die mit anderen Entwicklern gemeinsam genutzt werden. Ein Rebase auf Master ist in Ordnung, nur nicht umgekehrt. Andernfalls werden Sie wahrscheinlich die Build-und Push-oder Pull-Vorgänge unterbrechen, die bereitstehen, die weitere Entwicklung vereiteln und Sie zu einer Persona non grata mit dem Rest des Entwickler-und DevOps-Teams machen.