Gitlab-Anfrage zum Zusammenführen von Branch-A in Develop (3 Commits im Rückstand), sollte ich mir Sorgen machen?

Beim Erstellen einer Zusammenführungsanforderung in Gitlab erhalte ich häufig die Meldung: Request to merge branch-A into Develop ([x] Commits dahinter) Was will mir Gitlab sagen? Muss ich mir Sorgen machen oder muss ich etwas reparieren (was)?

Nach einiger Zeit a Zusammenführungsanfrage in einem Projekt geöffnet ist, ist es normal, dass die Version des Zweigs, in den Sie zusammenführen möchten, veraltet ist, weil andere Personen ihre eigenen Änderungen daran zusammenführen.

Gitlab hilft Ihnen, indem es anzeigt, wie weit die Version des Zweigs, den Sie aktualisiert haben, hinter dem Remote-Zweig liegt.

Ein Rückstand stellt kein Hindernis für den Zusammenschluss dar, ist aber eine gängige Praxis rebase Ihre Commits zusätzlich zu dem Zweig, in den Sie verschmelzen. Dadurch wird Ihre Zusammenführungsanforderung aktualisiert, indem Ihre Commits chronologisch nach denen platziert werden, die sich bereits in diesem Zweig befinden. Dieser Ansatz erleichtert die Arbeit der für die Zusammenführung verantwortlichen Person, da der Committer selbst eventuell aufgetretene Konflikte bereits gelöst hat.

Um ein rebase Das von Ihnen vorgeschlagene Szenario würde wie folgt aussehen:

# Add a remote named `upstream` pointing to the original repository
git remote add upstream https://gitlab.example.com/example/your_project.git

# Fetch the latest commmits from `upstream`
git fetch upstream

# Checkout our branch-A
git checkout branch-A

# Rebase our branch on top of the `upstream/develop` branch
git rebase upstream/develop

# If needed fix any conflicts that may have appeared and then `git rebase --continue`  

# Push the changes to the branch of your merge request
git push --force origin branch-A

Notiz: Der --force Flag ist beim Pushen erforderlich, da Sie den Commit-Verlauf von Ursprung/Zweig-A neu schreiben. Aus Gits Dokument:

[–force] kann dazu führen, dass das Remote-Repository Commits verliert; verwenden Sie es mit Vorsicht.

Wenn Sie die Meldung „Behind by

Wenn Sie sich die Unterschiede in Gitlab ansehen, können sie verwirrend wirken und möglicherweise darauf hindeuten, dass Sie dabei sind, Änderungen rückgängig zu machen, die in späteren Commits im Zielzweig implementiert werden.

Wenn Sie sicher sein möchten, dass Sie genau die Änderungen sehen, die durch die Zusammenführung vorgenommen werden, ist es am sichersten, den Zweig, den Sie zusammenführen möchten, zu aktualisieren, indem Sie ihn zuerst im Zielzweig zusammenführen …

# fetch the latest code on all branches
git fetch

# checkout your working branch (if you're not already on it)
git checkout branch-A

# merge in the target branch
git merge origin/develop

Beheben Sie eventuell auftretende Konflikte und begehen Sie sie dann:

# stage changes & commit
git add .
git commit

# push changes to origin
git push

Wenn Sie jetzt die Zusammenführungsanforderungsseite auf Gitlab aktualisieren, verschwindet die Meldung „behind“ und die Unterschiede spiegeln nur die von Ihnen vorgenommenen Änderungen wider.

Dies ist viel sicherer als eine Neubasierung Ihres Zweigs, da hierfür keine erforderlich ist --force drücken. Dies bedeutet auch, dass die Chronologie der Git-Zeitleiste mit dem übereinstimmt, was tatsächlich passiert ist. Wenn Sie also versuchen, ein Problem in der Zukunft aufzuspüren, werden Sie nicht durch eine Neuschreibung der Geschichte in die Irre geführt.

Der Nachteil ist, dass der Commit-Verlauf etwas unübersichtlicher aussehen kann.

Zusätzlich zur Antwort von @alejdg, um dies zu verhindern

[–force] kann dazu führen, dass das Remote-Repository Commits verliert; verwenden Sie es mit Vorsicht.

Sie könnten auch verwenden --force-with-lease was sicherer ist als --forcewenn andere Commits zwischen Ihren eingefügt werden rebase und dein push --force Mehr Informationen

Zusätzlich zu den obigen Antworten mache ich normalerweise die folgenden Schritte, um meinen lokalen Zweig neu zu starten und zu pushen. Normalerweise werde ich Remote Origin zum lokalen Git-Repo hinzufügen, wenn ich ein Mitwirkender bin.

git pull
git checkout <your-branch>
git rebase origin/<remote-branch>
git push --force origin <your-branch>

Dies ist das Verständnis eines Anfängers dafür, was vor sich geht. Sie finden Antworten auf Git mit einem höheren Grad an „Git-Wortlautung“. Aber so habe ich meinen Weg durch den Git-Dschungel gefunden. 😉 Ich hoffe, es hilft einigen anderen Anfängern.

Beginnen Sie mit der Überprüfung Ihres Hauptzweigs (hier entwickeln):

git checkout develop
git pull --all

Wechseln Sie dann zu Ihrem neuen Zweig A (an dem parallel zu anderen Commits gearbeitet wurde, die bereits in „develop“ zusammengeführt sind).

Sie können entweder jedes Commit einzeln auswählen, um vorsichtiger zu sein (empfohlen), oder ein Rebase direkt auf allen vorherigen Commits des letzten MR durchführen.

Schauen Sie im Allgemeinen auch nach oben stash Und stash applydann brauchen Sie keine Commits, es ist viel einfacher.

git checkout branch-A
git stash #(if you do not use commit, stash is recommended)
git rebase -i develop

-i bedeutet interaktiv, was bedeutet, dass Sie in einem auftauchenden Editor Änderungen vornehmen müssen.

(Wenn Sie es nicht verwenden -iSie erhalten den Editor nicht, was seitdem auch in Ordnung sein sollte, die gleichen Einstellungen werden automatisch verwendet, aber das ist nur in diesem Fall der Fall, in anderen Fällen könnte es sein, dass Sie ihn wirklich brauchen, daher scheint es gut zu sein, sich daran zu gewöhnen dieser Herausgeber).

Dieser „todo-editor“ wird mit den Commits geöffnet, die zum letzten MR für „develop“ geführt haben (was in Ihrem Fall dem Haupteditor entspricht).

Lassen Sie die pick vor allen Commits in diesem „Todo-Editor“, dies ist ohnehin die Standardeinstellung, und ändern Sie nur das letzte in edit anstatt pick da Ihr neuer Commit von allen Commits bearbeitet wird, die Sie im Folgenden durchführen, nicht von den anderen Commits. Ihr neuer Commit muss über dem MR des Zweigs „develop“ liegen, und alle anderen ausgewählten Commits sollten diejenigen vor dem letzten MR mit „develop“ sein.

Es sieht aus wie:

Schließen Sie dann diesen Editor und Sie werden nun alle Konflikte der ersten „Auswahl“ sehen, wenn Sie nachschlagen

git diff

Oder besser: Sie gehen in codium/vscode und akzeptieren bei jedem Konflikt nur den aktuellen oder den eingehenden Code (Dateien und Ordner mit Konflikten sind rot markiert, und in der Datei verwenden Sie den Pfeil nach oben/unten, um die Konflikte zu finden).

Dann:

git rebase --abort

Unterlassen Sie git commit oder git push während rebasestattdessen verwenden --abort und rebase erneut starten oder verwenden git rebase --continue wenn Sie sicher sind, was Sie tun, und die Zwischenergebnisse nicht überprüfen müssen. push kann Ihrem Commit-Baum schaden, commit --amend wird die früheren Commits ändern, und commit wird aus den alten neue Commits erstellen.

Rebase ist nicht dafür. Wenn Sie verwenden rebaseSie möchten am Ende und erst am Ende zum Ausgangspunkt zurückkehren Dann du kannst git commit --amend Und git push -f wenn benötigt.

Ohnehin. Weiter geht es mit der Arbeit:

Wiederholen Sie die obigen Schritte für jeden Commit, der nächste wäre der zweite Pick. Der dritte Commit ist bereits der „Edit“-Commit. Wenn Sie das erreichen, wiederholen Sie die oben genannten Schritte noch einmal, und wenn keine Konflikte mehr bestehen:

git add .
git stash apply #(or if you use commit: git commit --amend)
git push -f

Und Sie haben Ihren neuen Zweig auf die Arbeit gesetzt, die Sie in Ihrem letzten „Entwicklungs-MR“ geleistet haben.

*In meinem Fall führte mich die Rebase auf „develop“ auch zum MR-Commit des vorherigen „develop“ MR selbst. Am Ende habe ich einen duplizierten Commit dieses MR hinzugefügt, was falsch war. Dies geschieht, wenn Sie – fälschlicherweise – commit --amend auf einem vorhandenen MR-Commit, das bereits zusammengeführt ist. Somit hatte ich vor meinem letzten Commit einen Commit mehr, sodass ich zwei Commits statt einem zusätzlich zum „Develop“ hatte.

Verwenden Sie daher besser kein Commit, sondern stash / stash apply bei jedem ausgewählten Commit.*