Wie verschmelzen Sie Änderungen an Nicht-Master-Zweigen aus einem Github-Repository?

StackOverflow https://stackoverflow.com/questions/2014914

  •  19-09-2019
  •  | 
  •  

Frage

In beiden folgenden Fragen der folgenden Stackoverflow -Fragen beschreibt die akzeptierte Antwort, wie Änderungen aus einem Forked -Repository in der Situation zusammengefasst werden können, in der Sie ein Repo aufwenden, das ursprüngliche Repo modifiziert wird, und dann möchten Sie die Änderungen an den Master -Zweig zurückführen Ihr Forked Repo.

Es ist mir jedoch nicht klar, wie Sie in den Nicht-Master-Zweigen im ursprünglichen Repo auf dem Laufenden bleiben, das Sie gegabelt haben. Zum Beispiel, als ich ursprünglich gegabelt habe Bitprophet -Stoffrepository, Es enthielt die folgenden Zweige:

  • Meister
  • 0.9
  • 0,9 Doc-Wrewrite (existiert nicht mehr)
  • Pfad und#24 (existiert nicht mehr)

Die letzten beiden Zweige existieren nicht mehr, und jetzt gibt es einen neuen Zweig flexible-task-declarations. Ich habe meinen Master -Zweig abgerufen, zusammengeführt und gedrängt, damit Master, Herkunft/Master und stromaufwärts/Master den gleichen SHA1 -Hash haben und auf denselben Git -Schnappschuss verweisen. Ich bin mir jedoch nicht sicher, wie ich die Zweige entfernen soll, die nicht mehr existieren, und die neuen Zweige so aktualisieren, dass meine Gabel auf dem neuesten Stand ist. Muss ich jeden stromaufwärts gelegenen Zweig verfolgen und dann jeden Zweig einzeln abrufen, verschmelzen und schieben, oder gibt es einen besseren Weg?

War es hilfreich?

Lösung

Szenario 1: Löschen der Zweige, die nicht mehr existieren

Um die Zweige zu löschen, die nicht mehr existieren, folgte ich den Anweisungen in der Antwort auf Stackoverflow -Frage Wie lösche ich einen Git -Zweig sowohl lokal als auch in GitHub? Durch die Ausgabe der folgenden Befehle:

$ git push origin :0.9-doc-rewrite
$ git push origin :path-and-#24

Szenario 2: Verschmelzung von Änderungen in einem vorhandenen Nicht-Master-Zweig

Um den Upstream/0,9 -Zweig auf dem neuesten Stand zu bringen, habe ich Folgendes gemacht:

$ git checkout --track origin/0.9
$ git fetch upstream
$ git merge upstream/0.9
$ git push

Szenario 3: Verfolgung der neuen Nicht-Master-Zweige

Ich bin mir nicht sicher, dass dies der beste Weg ist, um damit umzugehen, aber hier ist, was ich getan habe:

$ git branch flexible-task-declarations upstream/flexible-task-declarations
Branch flexible-task-declarations set up to track remote branch flexible-task-declarations from upstream.
$ git checkout flexible-task-declarations
$ git push origin flexible-task-declarations

Um zu bestätigen, dass alle Zweige im gleichen Commit sind:

$ git branch -av

Dies zeigt alle Zweige - lokal und fern - und die neueste Commit -Botschaft und SHA1 Hash.

Webforschung, die möglicherweise eine bessere Methode für die Handhabung von Szenario 3 beleuchten kann

Ein wesentlicher Unterschied zwischen einer Git -Gabel im Vergleich zu einem einfachen Git -Klon oder einer SVN -Checkout besteht darin, dass Ihre Gabel sich mit dem Master -Repo niemals auf dem neuesten Stand halten wird, wenn Sie es nicht tun. Glücklicherweise gibt es ein einfaches Werkzeug, mit dem Sie dies tun können. Ihre Gabel ist getrennt und dem Master in Git -Begriffen entspricht. Wenn Sie Änderungen an dem Master verfolgen möchten, können Sie in Ihrem Gabel -Repo eine Tracking -Filiale erstellen und diese Änderungen in den Master -Zweig Ihrer Gabel zusammenführen, wenn Sie etwas begehen möchten. Ich empfehle das "Github" -Vor -Juwel, das ein Tool ist, das Sie installieren können, damit Sie Änderungen in jedem anderen Repository in Bezug auf Ihre problemlos verfolgen können. Weitere Informationen finden Sie im Readme -Text am Ende dieser Seite zur Installation und Verwendung: http://github.com/defunkt/github-ge/tree/master

Ignorieren Sie die Github Fork -Warteschlange Es ist böse! Die Fork -Warteschlange ist ein Werkzeug für Betreuer, die gerne einzelne Commits von Mitwirkenden auswählen, aber nicht in ihrer gesamten Zweigstelle zusammenarbeiten möchten. Wenn Sie mit der Fork -Warteschlange herumspielen, werden Sie Ihre Gabel beschädigen (sie kann jedoch behoben werden, lesen Sie etwas schiefgegangen). Viele Neulinge in Github haben das Gefühl, etwas mit der Fork-Warteschlange zu tun, weil es dort viele möglicherweise widersprüchliche Veränderungen gibt und sie nicht wissen, was die angebliche Art ist, die Gabel auf dem neuesten Stand zu halten. Lesen Sie Ihre Gabel auf dem neuesten Stand und finden Sie es heraus!

Djangos Github -Workflow

Das Django -Projekt enthält Anweisungen, wie es geht Arbeiten Sie mit Github zusammen Dies nutzt die Standardmethode, um die Gabelung und das Ziehen von vorgelagerten Änderungen zu bewältigen.

Verschiedene anfängliche Fork -Konfiguration

Long Nguyens Gastbeitrag mit dem Titel " Einrichten Ihrer Git -Repositories für Open -Source -Projekte bei GitHub Auf Michael Hartls Blog beschreibt eine interessante Methode, um ein GitHub -Repository einzurichten, das Sie aufgetaucht sind. Die Ziele dieser Methode nach dem Artikel sind:

  • Halten Sie die Repositorys synchron, damit jeder das vollständige "offizielle" Repository enthält
  • Erlauben Sie Entwicklern, offizielle Updates zu erhalten
  • Ermutigen Sie die Arbeit an anderen Zweigen als Master

Andere Tipps

Grundsätzlich haben Sie 3 Remote Git Repo ton in Betracht:

  • Lokal: Ihr aktuelles Git -Repo auf Ihrer Workstation.
  • Origin: Welches ist Ihre gabelhafte Version von Fabric: Cumulusware
  • stromaufwärts: Bitprophet / Stoff, der eine am Ursprung aller anderen Forked Repo

Sie könnten nach oben als Remote -Repo zu Ihrem Einheimischen hinzufügen.

 git remote add upstream http://github.com/bitprophet/fabric.git

Schauen Sie sich die entfernten Zweige an

 git branch -r

und drücken (löschen), die im Ursprung existieren, aber nicht mehr im stromaufwärts existieren 

 git push origin :anOldBranch

Dann 

 git remote prune origin

Um die Zweige in Ihrem örtlichen Repo zu räumen (die nicht mehr auf Herkunft existieren, da Sie sie gerade gelöscht haben)

Die Zweige, die sowohl in Herkunft als auch stromaufwärts existieren Lassen Sie sich schnell vorantreiben, um Ihre Arbeit aufzunehmen).

Ich weiß nicht, ob Sie einen einfacheren Prozess/Befehl/Skript haben könnten, um zwei entfernte Repositorys zu synchronisieren.

Ich bin auf diese Antwort gestoßen, während ich nach Szenario 3 in der akzeptierten Antwort sauber suchte. Nachdem Sie sich mit Git 1.8 umgegraben haben, können Sie Folgendes tun:

git fetch upstream                      ;make sure you have all the upstream changes
git checkout --no-track upstream/0.9    ;grab the new branch but don't track it
git branch --set-upstream-to=origin/0.9 ;set the upstream repository to your origin
git push                                ;push your new branch up to origin
Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top