with - gitlab update fork




Wie aktualisiere ich ein GitHub Forked Repository? (11)

Ab Mai 2014 ist es möglich, eine Fork direkt von GitHub aus zu aktualisieren. Dies funktioniert immer noch ab September 2017, ABER es wird zu einer schmutzigen Commit-Geschichte führen.

  1. Öffne deine Gabel auf GitHub.
  2. Klicken Sie auf Pull Requests .
  3. Klicken Sie auf New Pull Request . Standardmäßig vergleicht GitHub das Original mit Ihrer Gabel, und es sollte nichts Vergleichbares geben, wenn Sie keine Änderungen vorgenommen haben.
  4. Klicken Sie auf die Basis wechseln, wenn Sie diesen Link sehen. Andernfalls setzen Sie die Basisgabel von Hand auf die Gabel und die Kopfgabel nach oben. Jetzt vergleicht GitHub Ihre Gabel mit dem Original, und Sie sollten die neuesten Änderungen sehen.
  5. Erstellen Sie eine Pull-Anfrage, und weisen Sie Ihrer Pull-Anfrage einen vorhersagbaren Namen zu (z. B. Update from original ).
  6. Scrollen Sie nach unten zu Pull-Anfrage zusammenführen , klicken Sie jedoch noch nicht auf etwas.

Jetzt haben Sie drei Optionen, aber jede führt zu einem weniger als sauberen Commit-Verlauf.

  1. Bei der Standardeinstellung wird ein hässlicher Merge-Commit erstellt.
  2. Wenn Sie auf das Dropdown-Menü klicken und "Squash and merge" auswählen, werden alle dazwischenliegenden Commits zu einem Squash-Befehl zusammengefasst. Dies ist meistens etwas, was Sie nicht wollen.
  3. Wenn Sie auf " Zurücksetzen" und "Zusammenführen" klicken, werden alle Commits "mit" gemacht, die ursprünglichen PRs werden mit Ihrem PR verknüpft, und GitHub wird angezeigt. This branch is X commits ahead, Y commits behind <original fork> .

Ja, Sie können Ihr Repo mithilfe der GitHub-Web-Benutzeroberfläche auf dem neuesten Stand halten, dies wird jedoch Ihren Commit-Verlauf beeinträchtigen. Bleiben Sie stattdessen an der Befehlszeile - es ist einfach.

Ich habe kürzlich ein Projekt gegabelt und mehrere Korrekturen vorgenommen. Ich habe dann eine Pull-Anfrage erstellt, die dann akzeptiert wurde.

Ein paar Tage später wurde eine weitere Änderung von einem anderen Mitarbeiter vorgenommen. Also enthält meine Gabel diese Änderung nicht.

Wie kann ich diese Änderung in meine Gabel bekommen? Muss ich meinen Zweig löschen und neu erstellen, wenn ich weitere Änderungen habe, um einen Beitrag zu leisten? Oder gibt es eine Aktualisierungsschaltfläche?


Als Ergänzung zu dieser Antwort suchte ich nach einer Möglichkeit, alle abgelegenen Niederlassungen meines geklonten Repos ( Ursprung ) von den vorgelagerten Niederlassungen auf einmal zu aktualisieren. So habe ich es gemacht.

Dies setzt voraus, dass Sie bereits ein Upstream- Remote-Pointing auf das Quell-Repository konfiguriert haben (von dem der Ursprung abgezweigt wurde) und es mit git fetch upstream synchronisiert hat.

Dann renne:

for branch in $(git ls-remote --heads upstream|sed 's#^.*refs/heads/##'); do git push origin refs/remotes/upstream/$branch:refs/heads/$branch; done

Der erste Teil dieses Befehls listet alle Köpfe im Upstream- Remote-Repo auf und entfernt den SHA-1, gefolgt von dem Präfix refs/heads/ branch name.

Dann schiebt er für jeden dieser Zweige die lokale Kopie des Upstream- refs/remotes/upstream/<branch> ( refs/remotes/upstream/<branch> auf lokaler Seite) direkt an den entfernten Zweig am Ursprung ( refs/heads/<branch> auf entfernter Seite ).

Jeder dieser Verzweigungssynchronisierungsbefehle kann aus einem von zwei Gründen fehlschlagen: Entweder wurde der Upstream- Zweig neu geschrieben, oder Sie haben für diesen Zweig Commits an Ihre Verzweigung verschoben. Im ersten Fall, in dem Sie dem Zweig Ihrer Gabel noch nichts zugesagt haben, können Sie sicher forcieren (fügen Sie den Schalter -f hinzu ; dh git push -f im obigen Befehl). Im anderen Fall ist dies normal, da Ihr Fork-Zweig unterschiedlich ist und Sie nicht erwarten können, dass der Sync-Befehl funktioniert, bis Ihre Commits wieder mit dem Upstream zusammengeführt wurden .


Das hängt von der Größe Ihres Repositorys und davon ab, wie Sie es aufgespalten haben.

Wenn es sich um ein ziemlich großes Repository handelt, haben Sie es vielleicht auf eine spezielle Art und Weise verwalten wollen (z. B. Drop-History). Grundsätzlich können Sie Unterschiede zwischen der aktuellen und der vorgelagerten Version erhalten, sie festschreiben und dann wieder zum Master zurückkehren.

Lies das hier . Es beschreibt, wie mit großen Git-Repositorys umgegangen wird und wie sie mit den neuesten Änderungen aktualisiert werden.



Ich aktualisiere meine gegabelten Repos mit dieser einen Zeile:

git pull https://github.com/forkuser/forkedrepo.git branch

Verwenden Sie diese Option, wenn Sie Ihrem Projekt keinen weiteren Remote-Endpunkt hinzufügen möchten, da andere Lösungen hier veröffentlicht werden.


Seit November 2013 wurde eine inoffizielle Funktionsanforderung mit GitHub geöffnet, in der sie aufgefordert werden, eine sehr einfache und intuitive Methode hinzuzufügen, um eine lokale Verzweigung mit dem Upstream zu synchronisieren:

https://github.com/isaacs/github/issues/121

Hinweis: Da die Funktionsanforderung nicht inoffiziell ist, ist es auch ratsam, sich an [email protected] zu [email protected] , um Ihren Support für eine zu implementierende Funktion wie diese hinzuzufügen. Die obige inoffizielle Merkmalsanforderung könnte als Beleg für das Interesse an der Umsetzung verwendet werden.


Viele Antworten führen dazu, dass Sie Ihre Gabelung um ein Commit vor dem übergeordneten Repository verschieben. Diese Antwort fasst die here gefundenen Schritte zusammen, wodurch Ihre Verzweigung zu demselben Commit wie das übergeordnete Element verschoben wird.

  1. Wechseln Sie in Ihr lokales Repository.

    • Wechseln Sie zum Master-Zweig, wenn Sie nicht als git checkout master
  2. Fügen Sie das übergeordnete Element als Remote-Repository hinzu, git remote add upstream <repo-location>

  3. Ausgabe git fetch upstream
  4. Ausgabe git rebase upstream/master

    • An dieser Stelle prüfen Sie, ob das zusammengeführt wird, indem Sie git status eingeben
  5. git push origin master

Weitere Informationen zu diesen Befehlen finden Sie in here .


Wenn Sie GitHub für Windows verwenden, verfügen sie jetzt über eine Funktion zum Aktualisieren der Gabeln mit einem Klick:

  1. Wählen Sie das Repository in der Benutzeroberfläche aus.
  2. Klicken Sie oben auf "Update from user / branch".

Wenn Sie wie ich niemals etwas direkt an den Master übergeben , was Sie wirklich sollten, können Sie Folgendes tun.

Erstellen Sie aus dem lokalen Klon Ihrer Gabel Ihre Upstream-Fernbedienung. Sie müssen das nur einmal tun:

git remote add upstream https://github.com/whoever/whatever.git

Wann immer Sie sich mit dem Upstream-Repository-Hauptzweig treffen möchten, müssen Sie Folgendes tun:

git checkout master
git pull upstream master

Vorausgesetzt, Sie haben nie selbst etwas gegen Master begangen, sollten Sie bereits fertig sein. Jetzt können Sie Ihren lokalen Master zu Ihrer ursprünglichen Remote-GitHub-Gabel verschieben. Sie können Ihren Entwicklungszweig auch auf Ihrem aktuellen lokalen Master umbauen.

Nach dem ersten Upstream-Setup und dem Master-Checkout müssen Sie lediglich den folgenden Befehl ausführen, um Ihren Master mit dem Upstream zu synchronisieren: git Pull Upstream Master .



In Ihrem lokalen Klon Ihres verzweigten Repositorys können Sie das ursprüngliche GitHub-Repository als "Remote" hinzufügen. ("Remotes" sind wie Kurznamen für die URLs von Repositorys - origin ist zum Beispiel einer.) Dann können Sie alle Verzweigungen aus diesem Upstream-Repository abrufen und Ihre Arbeit neu stützen, um mit der Upstream-Version weiterzuarbeiten. In Bezug auf Befehle könnte das so aussehen:

# Add the remote, call it "upstream":

git remote add upstream https://github.com/whoever/whatever.git

# Fetch all the branches of that remote into remote-tracking branches,
# such as upstream/master:

git fetch upstream

# Make sure that you're on your master branch:

git checkout master

# Rewrite your master branch so that any commits of yours that
# aren't already in upstream/master are replayed on top of that
# other branch:

git rebase upstream/master

Wenn Sie die Historie Ihres Master-Zweigs nicht neu schreiben möchten (z. B. weil andere Personen es geklont haben könnten), sollten Sie den letzten Befehl durch git merge upstream/master ersetzen. Wenn Sie jedoch weitere Pull-Requests durchführen möchten, die so sauber wie möglich sind, ist es wahrscheinlich besser, sie erneut zu prüfen.

Wenn Sie Ihren Zweig auf upstream/master umgestaltet haben, müssen Sie möglicherweise den Push erzwingen, um ihn in Ihr eigenes verzweigtes Repository auf GitHub zu verschieben. Sie würden das mit machen:

git push -f origin master

Sie müssen die Option -f beim ersten Mal verwenden, nachdem Sie neu basierten.





github