Git – Wie wendet man selektiv Änderungen von einem Zweig auf einen anderen an?

Ist es möglich, mit Git selektiv Änderungen von einem Branch auf einen anderen anzuwenden?

Genauer gesagt verwende ich ein öffentliches dev Branch für GitHub und eine private master Zweig für die Bereitstellung. Wenn Änderungen an einem Zweig vorgenommen werden, müssen sie auf den anderen angewendet werden, aber einige Codezeilen müssen unterschiedlich bleiben. In meinem Fall sind es ein paar CSS-Klassen und ein Feed.

Ich bin neu bei Git, aber ich habe meine Nachforschungen angestellt:

• git merge --no-commit --no-ff kann verwendet werden, gefolgt von a git mergetool zu wählen, was ich im Falle eines Konflikts will. Das Problem ist, dass es nur für Konflikte funktioniert, die Git nicht automatisch zusammenführen kann. Was ich also anders halten möchte, wird ersetzt, bevor ich die Möglichkeit bekomme, mein Mergetool zu verwenden.

• git difftool --cached ist nützlich, da ich die Unterschiede sehen kann, aber ich muss kopieren, was ich von dort behalten möchte, und es manuell durch einen Texteditor ersetzen, da ich nicht einfach auswählen und speichern kann, wie ich es mit Mergetool kann.

• git cherry-pick scheint ein bestimmtes Commit auf ein anderes anzuwenden, aber was ich anders halten möchte, kann auf verschiedene Commits verstreut sein, und diese Commits können nicht nur das enthalten, was ich anders halten möchte. Ich kann mir nicht vorstellen, dass das funktioniert, es sei denn, ich mache Millionen von Commits, die mich verrückt machen würden.

Auch um klar zu sein, Ich möchte nicht, dass ein Zweig zu einem anderen wirdwas bei einer Verschmelzung der Fall zu sein scheint. Ich möchte zwei separate Zweige mit ihren jeweiligen Unterschieden und Änderungen von einem zum anderen anwenden.

Gibt es einen besseren Workflow, der es mir ermöglichen würde, eine Entwicklungs- und eine Bereitstellungsversion beizubehalten, indem ich ihre Änderungen übernehme und einige Unterschiede beibehalte? Es macht mir nichts aus, separate Repositorys oder verschiedene Tools zu verwenden, wenn dies zu einer Lösung führt.

Ich habe auch etwas über das Patchen herausgefunden:

So erstellen Sie den Patch: git diff dev > master.patch

Um es anzuwenden: patch < master.patch

Profitieren Sie von der Tatsache, dass das Erstellen von Git-Branches kostengünstig ist und keine Auswirkungen auf den tatsächlichen Inhalt des Arbeitsverzeichnisses haben muss.

1. Überprüfen Sie Ihren Quellzweig dev.

2. Erstellen Sie einen temporären Zweig. Es wird auf das gleiche Commit verweisen dev tut: checkout -b for_master

   Vermutlich wissen Sie (oder können leicht herausfinden), welche Commit vor dem dev Filiale ist die letzte Vor die Änderungen, die Sie (teilweise) wünschen. Nehmen wir in diesem Beispiel an, dass dieser Commit den Hash hat 1457B4 (‘zuletzt vor’, verstanden?).

3. Setze Dein __ zurück for_master zu diesem Commit verzweigen: git reset 1457B4. (Tun nicht benutze die --hard Schalter!)

   Jetzt haben Sie ein Arbeitsverzeichnis, das alle darin enthaltenen Änderungen enthält devaber aus dem POV der for_master -Zweig sind diese Änderungen nicht bereitgestellt und nicht festgeschrieben (während die dev branch zeigt immer noch auf Commits, die alle Änderungen aufzeichnen, sodass die Arbeit immer noch sicher ist).

4. Interaktives Staging verwenden (git add -p und/oder git add -e), erstellen Sie einen Commit (oder mehr als einen, wenn Sie möchten), der alle enthält, und nurdie Änderungen, die Sie auf Ihre anwenden möchten master Zweig.

   Notieren Sie sich den Hash des letzten Commits (oder geben Sie ihm ein Tag). In diesem Beispiel sage ich, dass sein Hash ist C0DA.

5. Kasse master.

6. Wählen Sie die Commit(s), die Sie gerade gemacht haben, aus: git cherry-pick 1457B4..C0DA.

   (Beachten Sie, dass das Rosinenpicken eines Bereichs erst nach Git-Version 1.7.2 verfügbar ist. Andernfalls müssen Sie alle Commits, die Sie in Schritt 4 vorgenommen haben, einzeln aussuchen.)

   (Ebenfalls Beachten Sie, dass bei der Rosinenauswahl eines Bereichs der Beginn des Bereichs der Commit ist Vor der erste, der tatsächlich gepflückt wird.)

Dieser Prozess ist eine Art Umkehrung der Verwendung git checkout -p wie in der ausgewählten Antwort erwähnt. Es könnte für die Erstellung nützlich sein cherry-pick-fähige Commits zwischen zwei Zweigen, die einen Teil des Codes teilen, aber auch viele Unterschiede aufweisen (z. B. zwischen zwei Hauptversionen eines Projekts), und Sie möchten nicht viel Zeit damit verbringen müssen, irrelevante Dateien in einem Aufruf zu ignorieren git checkout -p.

Persönlich fand ich es praktisch, zwei verschiedene Worktree-Verzeichnisse für dasselbe Repository zu verwenden (eines für den Quellzweig und eines für das Ziel) und zwischen zwei Befehlsshells zu wechseln, von denen eine das Quellzweigverzeichnis (Worktree) und die andere verwendet Ziel. Aber wenn Sie sich nicht wohl fühlen git worktree Funktion, die möglicherweise nichts für Sie ist.

Ich glaube nicht, dass es eine Möglichkeit gibt, Teile eines Commit aus derselben Datei auszuwählen. Ich würde sagen, Sie müssen Ihren Code einfach umgestalten, um solche Teile in andere Dateien zu verschieben.

Übrigens, wenn Sie einige Dateien aus einem Commit nehmen möchten, können Sie Cherry-Pick mit einer Kombination anderer Befehle verwenden, wie hier erklärt.