Warum füge ich "Remote-Tracking-Zweig" Ursprung / Entwicklung "in" Entwicklung "zusammen?

git pull erstellt wahrscheinlich das Commit. Wenn Sie ein lokales Commit durchführen und dann git pull ausführen, nachdem eine andere Person ein Commit in das Repository hochgeladen hat, lädt Git das Commit des anderen Entwicklers herunter und führt es dann in Ihrem lokalen Zweig zusammen.

Wie vermeide ich diese Merge Commits in Zukunft?

Sie könnten git pull --rebase verwenden, um zu verhindern, dass dies in Zukunft geschieht, aber das Neu-Basieren birgt seine Gefahren, und ich empfehle, pull insgesamt zu vermeiden .

Ich empfehle Ihnen stattdessen, diesem Verwendungsmuster zu folgen:

# download the latest commits
git remote update -p

# update the local branch
git merge --ff-only @{u}

# if the above fails with a complaint that the local branch has
# diverged:
git rebase -p @{u}

Erläuterung

• git remote update -p lädt alle Festschreibungen in den Remote-Repositorys herunter und aktualisiert die Remote-Verfolgungszweige (z. B. Origin/master). Es berührt NICHT Ihr Arbeitsverzeichnis, Ihren Index oder Ihre lokalen Zweige.

  Das Argument -p löscht vorgelagerte Zweige. Wenn also der Zweig foo im Repository Origin gelöscht wird, löscht git remote update -p automatisch Ihren Origin/foo ref.

• git merge --ff-only @{u} weist Git an, den Upstream-Zweig (das Argument @{u}) in Ihrem lokalen Zweig zusammenzuführen, aber nur, wenn Ihr lokaler Zweig zum Upstream-Zweig "schnell weitergeleitet" werden kann (mit anderen Worten, wenn er nicht auseinander gegangen ist).

• git rebase -p @{u} verschiebt effektiv die Commits, die Sie vorgenommen haben, aber noch nicht über den Upstream-Zweig verschoben haben. Dadurch müssen Sie keine albernen Merge-Commits mehr erstellen, die Sie vermeiden möchten. Dies verbessert die Linearität des Entwicklungsverlaufs und erleichtert die Überprüfung.

  Die Option -p weist Git an, Zusammenführungen beizubehalten. Dies verhindert, dass Git die neu basierenden Commits linearisiert. Dies ist wichtig, wenn Sie beispielsweise einen Feature-Zweig in master zusammengeführt haben. Ohne -p würde jedes Commit für den Feature-Zweig im Rahmen der von git rebase durchgeführten Linearisierung auf master dupliziert. Dies würde die Überprüfung der Entwicklungshistorie erschweren und nicht erleichtern.

  Vorsicht : git rebase kann möglicherweise nicht das tun, was Sie erwarten. Überprüfen Sie daher die Ergebnisse, bevor Sie auf "Push" klicken. Beispielsweise:

  git log --graph --oneline --decorate --date-order --color --boundary @{u}..
  

Ich bevorzuge diesen Ansatz aus folgenden Gründen git pull --rebase:

• Sie können siehe die eingehenden Upstream-Commits , bevor Sie Ihren Verlauf ändern, um sie einzubeziehen.
• Damit können Sie die Option -p (--preserve-merges) an git rebase übergeben, falls Sie eine beabsichtigte Zusammenführung erneut durchführen müssen (z. B. die Zusammenführung eines bereits gepushten Feature-Zweigs in master).

Kurzform: git up statt git pull

Um dies zu vereinfachen, empfehle ich, einen Alias ​​mit dem Namen up zu erstellen:

git config --global alias.up '!git remote update -p; git merge --ff-only @{u}'

Jetzt müssen Sie nur noch Folgendes tun, um Ihre Filiale auf den neuesten Stand zu bringen:

git up

anstelle von git pull. Wenn Sie eine Fehlermeldung erhalten, weil Ihre lokale Niederlassung von der vorgelagerten Niederlassung abweicht, ist dies Ihr Anhaltspunkt für einen Rebase.

Warum nicht git pull --rebase?

Das Ausführen von git pull --rebase entspricht dem Ausführen von git fetch gefolgt von git rebase. Dadurch wird versucht, einen schnellen Vorlauf auf die neuen Upstream-Commits durchzuführen. Wenn dies jedoch nicht möglich ist, werden die lokalen Commits auf die neuen Upstream-Commits zurückgesetzt. Dies ist normalerweise in Ordnung, aber seien Sie vorsichtig:

• Neustart ist ein fortgeschrittenes Thema, und Sie sollten die Auswirkungen verstehen, bevor Sie einen Neustart durchführen.
• git pull --rebase gibt Ihnen keine Möglichkeit, die Commits zu überprüfen, bevor Sie sie einbinden. Abhängig davon, was sich im Upstream geändert hat, kann es durchaus sein, dass Rebase die falsche Operation ist - ein rebase --onto, merge, reset oder Push -f ist geeigneter als ein einfaches rebase.
• Es ist (derzeit) nicht möglich, --preserve-merges an die Rebase-Operation zu übergeben. Daher wird jede beabsichtigte Zusammenführung eines Feature-Zweigs linearisiert, wodurch alle Commits des Feature-Zweigs wiedergegeben (und somit dupliziert) werden.

"Korrigieren" eines vorhandenen Zusammenführungs-Commits, das von git pull erstellt wurde

Wenn Sie noch kein von git pull erstelltes Zusammenführungs-Commit übermittelt haben, können Sie das Zusammenführungs-Commit erneut in die Basis setzen. Angenommen, Sie haben keine beabsichtigten Zusammenführungen vorgenommen (z. B. Zusammenführen eines bereits übertragenen Feature-Zweigs in Ihrem aktuellen Zweig), sollten Sie Folgendes tun:

git rebase @{u}

Der obige Befehl weist Git an, alle von HEAD (dem aktuellen Commit) erreichbaren Non-Merge-Commits auszuwählen, abzüglich aller von @{u} erreichbaren Commits (Abkürzung für "the upstream branch", dh Origin/master if HEAD ist master), spielen Sie sie über dem Upstream-Zweig ab (wählen Sie sie aus), und verschieben Sie dann den aktuellen Zweigverweis, um auf das Ergebnis der Wiederholung der Commits zu verweisen. Dadurch werden die nicht zusammengeführten Festschreibungen effektiv auf die letzte vorgelagerte Festschreibung verschoben, wodurch die von git pull erstellte Zusammenführung beseitigt wird.

Wenn Sie absichtlich ein Merge-Commit durchführen, möchten Sie git rebase @{u} nicht ausführen, da dadurch alles aus dem anderen Zweig wiedergegeben wird. Der Umgang mit diesem Fall ist wesentlich komplizierter, weshalb es gut ist, git up zu verwenden und git pull ganz zu vermeiden. Sie müssen wahrscheinlich reset verwenden, um die von pull erstellte Zusammenführung rückgängig zu machen, und dann git rebase -p @{u} ausführen. Das Argument -p für git rebase hat bei mir nicht zuverlässig funktioniert, sodass Sie möglicherweise reset verwenden müssen, um die beabsichtigte Zusammenführung rückgängig zu machen, Ihren lokalen Zweig auf @{u} zu aktualisieren und dann die beabsichtigte Zusammenführung erneut durchzuführen (dies ist ein Fehler) Schmerzen, wenn es viele haarige Zusammenführungskonflikte gibt).