Nehmen wir an, wir haben die folgende Situation in Git:

1. Ein erstelltes Repository:

   mkdir GitTest2
   cd GitTest2
   git init
   

2. Einige Änderungen im Master finden statt und werden festgeschrieben:

   echo "On Master" > file
   git commit -a -m "Initial commit"
   

3. Feature1 hat vom Master abgezweigt und einige Arbeiten sind erledigt:

   git branch feature1
   git checkout feature1
   echo "Feature1" > featureFile
   git commit -a -m "Commit for feature1"
   

4. Währenddessen wird ein Fehler im Master-Code entdeckt und ein Hotfix-Zweig eingerichtet:

   git checkout master
   git branch hotfix1
   git checkout hotfix1
   

5. Der Fehler wurde im Hotfix-Zweig behoben und wieder mit dem Master zusammengeführt (möglicherweise nach einer Pull-Anfrage / Code-Überprüfung):

   echo "Bugfix" > bugfixFile
   git commit -a -m "Bugfix Commit"
   git checkout master
   git merge --no-ff hotfix1
   

6. Die Entwicklung von Feature1 wird fortgesetzt:

   git checkout feature1
   

Angenommen, ich benötige den Hotfix in meinem Feature-Zweig, möglicherweise weil der Fehler auch dort auftritt. Wie kann ich dies erreichen, ohne die Commits in meinem Feature-Zweig zu duplizieren?

Ich möchte verhindern, dass zwei neue Commits in meinem Feature-Zweig angezeigt werden, die keinen Bezug zur Feature-Implementierung haben. Dies scheint mir besonders wichtig zu sein, wenn ich Pull-Anfragen verwende: Alle diese Commits werden auch in die Pull-Anfrage aufgenommen und müssen überprüft werden, obwohl dies bereits geschehen ist (da sich der Hotfix bereits im Master befindet).

Ich kann kein git merge master --ff-only: "fatal: Nicht schnell vorspulen, abbrechen.", Aber ich bin mir nicht sicher, ob mir das geholfen hat.

Wie verschmelzen wir den Hauptzweig mit dem Feature-Zweig? Einfach:

git checkout feature1
git merge master

Es macht keinen Sinn, hier eine Schnellvorlaufzusammenführung zu erzwingen, da dies nicht möglich ist. Sie haben sowohl den Feature-Zweig als auch den Master-Zweig festgelegt. Ein schneller Vorlauf ist jetzt unmöglich.

Schauen Sie sich GitFlow an . Es ist ein Verzweigungsmodell für Git, dem man folgen kann, und das haben Sie unbewusst bereits getan. Es ist auch eine Erweiterung von Git, die einige Befehle für die neuen Workflow-Schritte hinzufügt, die Dinge automatisch ausführen, die Sie sonst manuell ausführen müssten.

Was haben Sie in Ihrem Workflow richtig gemacht? Sie müssen mit zwei Zweigen arbeiten. Ihr Feature1-Zweig ist im Grunde der "Entwicklungs" -Zweig im GitFlow-Modell.

Sie haben einen Hotfix-Zweig vom Master erstellt und wieder zusammengeführt. Und jetzt steckst du fest.

Das GitFlow-Modell fordert Sie auf, den Hotfix auch mit dem Entwicklungszweig zusammenzuführen, der in Ihrem Fall "feature1" ist.

Die wirkliche Antwort wäre also:

git checkout feature1
git merge --no-ff hotfix1

Dadurch werden alle Änderungen, die innerhalb des Hotfixes vorgenommen wurden, zum Feature-Zweig hinzugefügt, jedoch nur diese Änderungen. Sie können mit anderen Entwicklungsänderungen in der Verzweigung in Konflikt stehen, sie stehen jedoch nicht in Konflikt mit der Hauptverzweigung, wenn Sie die Feature-Verzweigung schließlich wieder mit der Hauptverzweigung zusammenführen.

Seien Sie beim Umbasieren sehr vorsichtig. Rebase nur, wenn die Änderungen, die Sie vorgenommen haben, lokal in Ihrem Repository geblieben sind, z. B. wenn Sie keine Zweige in ein anderes Repository verschoben haben. Rebasing ist ein großartiges Tool für Sie, um Ihre lokalen Commits in eine nützliche Reihenfolge zu bringen, bevor Sie sie in die Welt hinausschieben.

Sie sollten in der Lage sein, Ihren Zweig auf Master neu zu gründen:

git checkout feature1
git rebase master

Verwalten Sie alle auftretenden Konflikte. Wenn Sie zu den Commits mit den Bugfixes kommen (bereits im Master), wird Git sagen, dass es keine Änderungen gab und dass sie möglicherweise bereits angewendet wurden. Anschließend setzen Sie die Rebase fort (während Sie die bereits im Master enthaltenen Commits überspringen) mit

git rebase --skip

Wenn Sie einen git logFeature-Zweig ausführen , wird das Bugfix-Commit nur einmal und im Master-Bereich angezeigt.

Weitere Informationen finden Sie in der Git-Buchdokumentation unter git rebase( https://git-scm.com/docs/git-rebase ), die genau diesen Anwendungsfall abdeckt.

================ Für zusätzlichen Kontext bearbeiten ====================

Diese Antwort wurde speziell für die von @theomega gestellte Frage unter Berücksichtigung seiner besonderen Situation gegeben. Beachten Sie diesen Teil:

Ich möchte [...] Commits in meinem Feature-Zweig verhindern, die keinen Bezug zur Feature-Implementierung haben.

Die Wiederherstellung seiner privaten Niederlassung auf Master ist genau das, was zu diesem Ergebnis führen wird. Im Gegensatz dazu würde das Zusammenführen des Masters in seiner Zweigstelle genau das tun, was er speziell nicht möchte : Hinzufügen eines Commits, das nicht mit der Feature-Implementierung zusammenhängt, an der er über seine Zweigstelle arbeitet.

Um die Benutzer anzusprechen, die den Fragentitel gelesen haben, überspringen Sie den tatsächlichen Inhalt und Kontext der Frage und lesen Sie dann die oberste Antwort nur blind, vorausgesetzt, sie gilt immer für ihren (anderen) Anwendungsfall. Lassen Sie mich Folgendes erläutern:

• Nur private Zweige neu gründen (dh die nur in Ihrem lokalen Repository vorhanden sind und nicht für andere freigegeben wurden). Das Wiederherstellen gemeinsam genutzter Zweige würde die Kopien anderer Benutzer "beschädigen".
• Wenn Sie Änderungen von einem Zweig (egal ob es sich um einen Master oder einen anderen Zweig handelt) in einen öffentlichen Zweig integrieren möchten (z. B. Sie haben den Zweig zum Öffnen einer Pull-Anforderung verschoben, aber es gibt jetzt Konflikte mit dem Master, und Sie müssen ihn aktualisieren Um diese Konflikte zu lösen, müssen Sie sie zusammenführen (z. B. mit git merge masterwie in der Antwort von @ Sven).
• Sie können auch Filialen in Ihre lokalen privaten Filialen einbinden, wenn Sie dies bevorzugen. Beachten Sie jedoch, dass dies zu "ausländischen" Commits in Ihrer Filiale führt.

Wenn Sie mit der Tatsache unzufrieden sind, dass diese Antwort nicht zu Ihrer Situation passt, obwohl sie für @theomega war, ist das Hinzufügen eines Kommentars unten nicht besonders hilfreich: Ich kontrolliere nicht, welche Antwort ausgewählt wird. nur @theomega tut.

Basierend auf diesem Artikel sollten Sie:

• Erstellen Sie einen neuen Zweig, der auf der neuen Version des Masters basiert

  git branch -b newmaster

• Führen Sie Ihren alten Feature-Zweig in einen neuen zusammen

  git checkout newmaster

• Konflikt im Zweig für neue Funktionen lösen

Die ersten beiden Befehle können zu kombiniert werden git checkout -b newmaster.

Auf diese Weise bleibt Ihr Verlauf klar, da Sie keine Zusammenführungen benötigen. Und Sie müssen nicht so vorsichtig sein, da Sie keine Git-Rebase durchführen müssen.

git merge

Sie können die folgenden Schritte ausführen

1. origin/masterZweig zu featureZweig zusammenführen

# step1: change branch to master, and pull to update all commits
$ git checkout master
$ git pull

# step2: change branch to target, and pull to update commits
$ git checkout feature
$ git pull

# step3: merge master to feature(⚠️ current is feature branch)
$ git merge master

2. featureZweig zu origin/masterZweig zusammenführen

origin/masterist der entfernte Hauptzweig, während masterder lokale Hauptzweig ist

$ git checkout master
$ git pull origin/master

$ git merge feature
$ git push origin/master

Zimis Antwort beschreibt diesen Prozess allgemein. Hier sind die Besonderheiten:

1. Erstellen Sie einen neuen Zweig und wechseln Sie zu ihm. Stellen Sie sicher, dass der neue Zweig auf basiert, masterdamit er die neuesten Hotfixes enthält.

   git checkout master
   git branch feature1_new
   git checkout feature1_new
   
   # Or, combined into one command:
   git checkout -b feature1_new master
   

2. Führen Sie nach dem Wechsel zum neuen Zweig die Änderungen aus Ihrem vorhandenen Feature-Zweig zusammen. Dadurch werden Ihre Commits hinzugefügt, ohne dass die Hotfix-Commits dupliziert werden.

   git merge feature1
   

3. Lösen Sie in der neuen Verzweigung alle Konflikte zwischen Ihrer Funktion und der Hauptverzweigung.

Erledigt! Verwenden Sie nun den neuen Zweig, um Ihre Funktion weiterzuentwickeln.

Hier ist ein Skript, mit dem Sie Ihren Hauptzweig mit Ihrem aktuellen Zweig zusammenführen können.

Das Skript führt Folgendes aus:

• Wechselt zum Hauptzweig
• Zieht den Hauptzweig
• Wechselt zurück zu Ihrer aktuellen Filiale
• Fügt den Hauptzweig in Ihren aktuellen Zweig ein

Speichern Sie diesen Code als Batch-Datei (.bat) und platzieren Sie das Skript an einer beliebigen Stelle in Ihrem Repository. Klicken Sie dann darauf, um es auszuführen, und Sie sind fertig.

:: This batch file pulls current master and merges into current branch

@echo off

:: Option to use the batch file outside the repo and pass the repo path as an arg
set repoPath=%1
cd %repoPath%

FOR /F "tokens=*" %%g IN ('git rev-parse --abbrev-ref HEAD') do (SET currentBranch=%%g)

echo current branch is %currentBranch%
echo switching to master
git checkout master
echo.
echo pulling origin master
git pull origin master
echo.
echo switching back to %currentBranch%
git checkout %currentBranch%
echo.
echo attemting merge master into %currentBranch%
git merge master
echo.
echo script finished successfully
PAUSE

Möglicherweise können Sie einen "Cherry-Pick" ausführen, um die genauen Commits, die Sie benötigen, in Ihren Feature-Zweig zu ziehen.

git checkout hotfix1Führen Sie a aus , um in den Zweig hotfix1 zu gelangen. Führen Sie dann a aus git log, um den SHA-1-Hash (große Folge von zufälligen Buchstaben und Zahlen, die ein Commit eindeutig identifizieren) des betreffenden Commits zu erhalten. Kopieren Sie das (oder die ersten 10 oder so Zeichen).

Kehren Sie dann git checkout feature1zu Ihrem Feature-Zweig zurück.

Dann, git cherry-pick <the SHA-1 hash that you just copied>

Dadurch wird dieses Commit und nur dieses Commit in Ihren Feature-Zweig gezogen. Diese Änderung wird in der Branche vorgenommen - Sie haben sie nur "ausgewählt". Nehmen Sie dann die Arbeit wieder auf, bearbeiten Sie sie, legen Sie sie fest, drücken Sie sie usw. nach Herzenslust.

Wenn Sie schließlich eine weitere Zusammenführung von einem Zweig in Ihren Feature-Zweig durchführen (oder umgekehrt), erkennt Git, dass Sie diesen bestimmten Commit bereits zusammengeführt haben , und wissen, dass er nicht erneut erstellt werden muss "überspringen".

Ich bin in der Feature-Branche und habe Refactorings durchgeführt. Ich möchte die Masteränderungen jetzt in meinem Feature-Zweig zusammenführen. Ich bin weit zurück. Hinweis Ich möchte die Master-Änderungen nicht auf mein lokales Verzeichnis übertragen, da in meinem Feature-Zweig Module von einem Ort an einen anderen verschoben wurden. Ich fand, dass es nicht funktioniert, nur unten ohne Ziehen aufzutreten. es heißt "Schon auf dem neuesten Stand."

 //below does not get the latest from remote master to my local feature branch without git pull
    git checkout master 
    git fetch 
    git checkout my-feature-branch 
    git merge master

Dies funktioniert unten. Beachten Sie, dass git merge origin / master verwendet wird:

 git checkout master 
    git fetch 
    git checkout my-feature-branch 
    git merge origin/master