Wie kann ich den GitHub Forked Repo aktualisieren, wenn eine Pull-Anfrage abgelehnt wurde?

Question

Ich gab ein Repo auf GitHub und gab eine Pull-Anfrage ab. Die Betreuer des Projekts haben die Pull-Anfrage abgelehnt, aber wir haben in einem Forum eine bessere Lösung ausgearbeitet. Sie beauftragten mich, eine weitere Pull-Anfrage mit den alternativen Änderungen zu erstellen. Allerdings ist mein Fork des Repositories auf GitHub jetzt veraltet, da Updates seit meiner Abzweigung zum Hauptrepo übertragen wurden. Außerdem hat das Repository auf GitHub ein zusätzliches Commit (mein Pull-Request-Commit), das nicht dort sein sollte, weil es nicht als Teil des Projekts akzeptiert wurde.

fand ich diese Frage: How do I update a GitHub forked repository?

ich die Anweisungen befolgt, speziell, ich dies tat:

git remote add upstream git://github.com/fuel/core 
git fetch upstream 

, die in Folge:

remote: Counting objects: 93, done. 
remote: Compressing objects: 100% (47/47), done. 
remote: Total 69 (delta 49), reused 40 (delta 20) 
Unpacking objects: 100% (69/69), done. 
From git://github.com/fuel/core 
* [new branch]  1.0/master -> upstream/1.0/master 
* [new branch]  1.1/master -> upstream/1.1/master 
* [new branch]  1.2/develop -> upstream/1.2/develop 
* [new branch]  1.2/master -> upstream/1.2/master 
* [new branch]  1.3/develop -> upstream/1.3/develop 
* [new branch]  1.3/master -> upstream/1.3/master 
* [new branch]  1.4/develop -> upstream/1.4/develop 
* [new branch]  1.4/master -> upstream/1.4/master 
* [new branch]  1.5/develop -> upstream/1.5/develop 
* [new branch]  1.5/master -> upstream/1.5/master 
* [new branch]  1.6/develop -> upstream/1.6/develop 
* [new branch]  feature/better-hmvc -> upstream/feature/better-hmvc 

Okay, so dass alles in Ordnung scheint und gut. Ich stellte sicher, dass ich auf dem richtigen Zweig war:

git checkout 1.6/develop 
Already on '1.6/develop' 

Wort. Okay, jetzt für das:

git rebase upstream/1.6/develop 
First, rewinding head to replay your work on top of it... 
Applying: prevent invalid XML node names 

Warten ... was? Warum wird "ungültige XML-Knotennamen verhindern" angewendet? Das ist die Pull-Anforderung, die von den Projektbetreuern abgelehnt wurde. Ich vermisse das Boot offensichtlich in der wahren Bedeutung von "Rebase". Nun, wenn ich git status heißt es:

# On branch 1.6/develop 
nothing to commit (working directory clean) 

Als ich git log ich, dass die Hälfte meiner Problem behoben ist zu sehen. Die Änderungen, die seit meiner Abzweigung in das Projekt gezogen wurden, spiegeln sich jetzt in meiner git log wider. Das letzte Commit bleibt jedoch "ungültige XML-Knotennamen verhindern". Wie kann ich es auslöschen?

Ich habe versucht, die letzten am Projekt vorgenommen Auschecken commit:

git checkout 5f31a4df55e5b6ca1b2092534063a1fce4a32181 

jedoch

, das läßt mich in einem frei stehenden HEAD Zustand. Es sagt, ich kann mich umsehen, Änderungen vornehmen und sie begehen. Ich glaube nicht, dass ich das machen möchte. Ich denke, ich möchte, dass HEAD auf commit 5f31a4df55e5b6ca1b2092534063a1fce4a32181 zeigt. Was ist mein nächster Schritt?

Answer 1

git rebase wird Ihr Commit in Ihrer Branche halten. Da Ihre PR abgelehnt wurde, möchten Sie sie löschen und Ihren Zweig master genauso wie upstream/master verzweigen.

Als so wollen Sie reset!

git checkout master 
git reset --hard upstream/master 

Dann haben Sie genau den gleichen Master wie der Upstream. Erstellen Sie dann einen neuen Zweig für Ihre neue PR, damit Sie dieses Problem nicht erneut haben.

Answer 2

Da diese Frage eine bereits akzeptierte Antwort hat, werde ich Ihnen einen anderen Weg sagen, weil die angenommene Antwort in meinem Fall nicht gut gelaufen ist.

Executing

$git rebase  
There is no tracking information.... 

$git checkout 
Already on 'master' 

$git reset --hard upstream/master 
ambiguous argument upstream/master 

Wenn eine solche Situation entsteht dann durch diese Schritte gehen Sie bitte.

Lokal HEAD zurücksetzen.

$git reset HEAD 

die gleichen Änderungen am Server Repo vornehmen.

$git reset HEAD^ 

Dann wird die Nachricht über die Änderungen zeigen, dass Sie zu den ursprünglichen gegabelt Repo von Ihnen gemacht, alle Dateien auflistet. Unstagiert mit Dateinamen geändert.

nun rückgängig machen Sie die Änderungen mit:

$git stash 

Jetzt können Sie diese Änderungen zwingen, Push-to-Sever Ihre lokalen und Remote-Repo auf demselben Kopf zu zeigen.

$git push origin +HEAD 

Jetzt sind Sie in der gleichen Repo, wo Sie zur Zeit der Gabel waren. Jetzt können Sie für den neuesten Code aus dem ursprünglichen Repo erneut ziehen.