Wie cherry-pick eine Reihe von commits und merge in eine andere Abteilung?

Wann kommt es zu einer Reihe von commits, cherry-picking ist war nicht praktikabel.

Als die unten erwähnt werden von Keith Kim, Git 1.7.2+ die Möglichkeit eingeführt, cherry-pick, eine Reihe von commits (aber Sie noch brauchen, um bewusst sein, der Folge von cherry-picking für die Zukunft Zusammenführen)

git cherry-pick", gelernt, um eine Reihe von commits

(z.B. "cherry-pick A..B" und "cherry-pick --stdin"), so hat "git revert"; diese unterstützen nicht die schönere sequencing control "rebase [-i]" hat, obwohl.

damian Kommentare und warnt uns:

In der "cherry-pick A..B" form, A sollte älter sein als B.

, Wenn Sie die falsche Reihenfolge der Befehl wird im hintergrund fehl,.

Wenn Sie möchten, um die Bereich B durch D (inklusive) das wäre B^..D.

Siehe "Git-create-branch aus dem Bereich der früheren verpflichtet?" als eine illustration.

Als Jubobs erwähnt in den Kommentaren:

Dies setzt Voraus, dass B kein root-commit; Sie erhalten eine "unknown revision" Fehler sonst.

Hinweis: als Git-2.9.x/2.10 (Q3 2016), können Sie cherry-pick eine Reihe von commit direkt auf einem verwaisten Zweig (leerer Kopf): siehe "Zu machen, wie die bestehende Niederlassung als Waise in git".

Ursprüngliche Antwort (Januar 2010)

Einen rebase --onto wäre besser, wo Sie die Wiedergabe der bestimmten Reihe von commit auf Ihre integration Zweig, als Charles Bailey hier beschrieben.

(sehen Sie sich auch für "Hier ist, wie würden Sie-Transplantation-ein Thema-branch basierend auf einem Zweig zu einem anderen" in die git rebase Mann Seite, um zu sehen, ein Beispiel aus der Praxis git rebase --onto)

Wenn Ihr Aktueller Zweig integration:

# Checkout a new temporary branch at the current location
git checkout -b tmp

# Move the integration branch to the head of the new patchset
git branch -f integration last_SHA-1_of_working_branch_range

# Rebase the patchset onto tmp, the old location of integration
git rebase --onto tmp first_SHA-1_of_working_branch_range~1 integration

Wird replay alles, was zwischen:

• nachdem die Eltern von first_SHA-1_of_working_branch_range (daher der ~1): der erste commit, die Sie wiedergeben möchten
• bis zu "integration" (die Punkte der letzten übertragung, die Sie wiedergeben möchten, aus der working branch)

"tmp" (die Punkte, wo integration zeigte vor)

Wenn es einen Konflikt, wenn einer von denen verpflichtet wird wiedergegeben:

• entweder lösen Sie es und führen Sie "git rebase --continue".
• oder überspringen Sie diesen patch, und führen Sie stattdessen "git rebase --skip"
• oder Abbrechen, die ganze Sache mit einem "git rebase --abort" (und wieder die integration Filiale auf der tmp branch)

Danach rebase --onto, integration sich wieder auf das Letzte commit von der integration Zweig ("tmp"Branche + alle wiedergegeben verpflichtet)

Mit cherry-picking oder rebase --onto, vergessen Sie es nicht, hat das Auswirkungen auf die spätere Zusammenführungen, als hier beschrieben.

Einer reinen "cherry-pick" Lösung ist diskutiert hier, und würde so etwas wie:

Wenn Sie möchten, verwenden Sie ein patch-Ansatz dann "git format-patch|git am" und "git cherry" sind Ihre Optionen.

Derzeit git cherry-pick akzeptiert nur eine einzelne Begehen, aber wenn Sie wollen, um die Palette B durch D wäre B^..D im git lingo, so

git rev-list --reverse --topo-order B^..D | while read rev 
do 
  git cherry-pick $rev || break 
done 

Aber trotzdem, wenn Sie brauchen, um "replay" - eine Reihe von commits, das Wort "replay" zu drücken Sie die " rebase " - feature von Git.

InformationsquelleAutor VonC

Sind Sie sicher, dass Sie nicht wollen, um tatsächlich verschmelzen die äste? Wenn der Zweig hat einige der jüngsten verpflichtet Sie nicht möchten, können Sie einfach erstellen Sie einen neuen Zweig mit einem KOPF an der Stelle, die Sie wollen.

Nun, wenn Sie wirklich wollen, cherry-pick, eine Reihe von commits, die, aus welchem Grund auch immer, ein eleganter Weg, dies zu tun ist, ziehen Sie einfach ein patchset und anwenden, um Ihre neue integration Branche:

git format-patch A..B
git checkout integration
git am *.patch

Dies ist im wesentlichen, was git-rebase macht sowieso, aber ohne die Notwendigkeit, Spiele zu spielen. Sie können hinzufügen --3way zu git-am wenn Sie Zusammenführen müssen. Stellen Sie sicher, es gibt keine anderen *.patch-Dateien bereits in dem Verzeichnis, in dem Sie dies tun, wenn Sie Folgen Sie den Anweisungen wörtlich...

InformationsquelleAutor djs

Wickelte ich VonC code in einem kurzen bash-Skript, git-multi-cherry-pick für einfach läuft:

#!/bin/bash

if [ -z $1 ]; then
    echo "Equivalent to running git-cherry-pick on each of the commits in the range specified.";
    echo "";
    echo "Usage:  $0 start^..end";
    echo "";
    exit 1;
fi

git rev-list --reverse --topo-order $1 | while read rev 
do 
  git cherry-pick $rev || break 
done 

Ich bin derzeit mit, wie ich den Wiederaufbau der Geschichte des Projekts, hatte die beiden 3rd-party-code-Anpassungen und vermischt in der gleichen svn-trunk. Ich bin jetzt splitting auseinander core 3rd-party-code, 3rd-party-Module und Anpassungen auf Ihre eigenen git-Verzweigungen zum besseren Verständnis der Anpassungen für die Zukunft. git-cherry-pick ist hilfreich in dieser situation, da ich zwei Bäume in der gleichen Ablage, aber ohne einen gemeinsamen Vorfahren.

InformationsquelleAutor Adam Franco

Weitere option könnte sein, die merge mit Strategie, die uns zu dem verpflichten, bevor die Reihe und dann einen 'normalen' verschmelzen mit dem letzten commit des Bereichs (oder-Zweig, wenn es der Letzte ist). So nehme nur 2345 und 3456 commit des master zusammengeführt Zweig:

master: 
1234 
2345 
3456 
4567 

in der feature-branch:

git merge -s unsere 4567 
git-merge-2345 

InformationsquelleAutor Koos Vriezen