it-swarm.com.de

push kann nicht zum Zurücksetzen nach dem Ablegen

Wir verwenden Git und haben eine Hauptniederlassung und Entwicklerzweige. Ich muss eine neue Funktion hinzufügen und dann die Commits zum Master rebase und dann den Master zum CI-Server pushen.

Das Problem ist, dass ich, wenn ich Konflikte während der Rebase habe, nach dem Abschluss der Rebase nicht zu meinem Remote-Entwickler-Zweig (auf Github) pushen kann, bis ich meinen Remote-Zweig abziehe. Dies führt zu doppelten Commits. Wenn es keine Konflikte gibt, funktioniert es wie erwartet.

frage: Wie synchronisiere ich nach der Neubewertung und Konfliktlösung meine lokalen und Remote-Entwicklerzweige, ohne doppelte Commits zu erstellen?

Konfiguration:

// master branch is the main branch
git checkout master
git checkout -b myNewFeature

// I will work on this at work and at home
git Push Origin myNewFeature

// work work work on myNewFeature
// master branch has been updated and will conflict with myNewFeature
git pull --rebase Origin master

// we have conflicts
// solve conflict
git rebase --continue

//repeat until rebase is complete
git Push Origin myNewFeature

//ERROR
error: failed to Push some refs to '[email protected]:ariklevy/dropLocker.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Merge the remote changes (e.g. 'git pull')
hint: before pushing again.
hint: See the 'Note about fast-forwards' in 'git Push --help' for details.

// do what git says and pull
git pull Origin myNewFeature

git Push Origin myNewFeature

// Now I have duplicate commits on the remote branch myNewFeature

BEARBEITEN

Es klingt also so, dass der Workflow unterbrochen wird:

developer1 arbeitet an myNewFeature developer2 arbeitet an hisNewFeature Beide verwenden master als Hauptzweig

developer2 führt myNewFeature in hisNewFeature ein

developer1 rebasiert, löst Konflikte auf und erzwingt Push-Vorgänge zum Remote-Zweig für myNewFeature

ein paar Tage später führt der Entwickler2 erneut myNewFeature in seinNewFeature ein

Wird dies dazu führen, dass die anderen Entwickler developer1 hassen?

98
Matt

Zunächst müssen Sie und die Personen, mit denen Sie arbeiten, zustimmen, ob ein Zweig oder ein Entwicklungszweig für die gemeinsame Entwicklung vorgesehen ist oder nur für Ihren eigenen. Andere Entwickler wissen, dass sie sich in meinen Entwicklungszweigen nicht verschmelzen sollten, da sie jederzeit umbasiert werden. Normalerweise sieht der Workflow folgendermaßen aus:

o-----o-----o-----o-----o-----o       master
 \
   o-----o-----o                      devel0
                \
                  o-----o-----o       devel1

Um mit Remote auf dem neuesten Stand zu bleiben, mache ich Folgendes:

 git fetch Origin
 git checkout master
 git merge --ff Origin/master

Ich mache das aus zwei Gründen. Erstens, weil ich so sehen kann, ob es Remote-Änderungen gibt, ohne von meinem Entwicklungszweig wechseln zu müssen. Zweitens handelt es sich um einen Sicherheitsmechanismus, um sicherzustellen, dass ich keine unverfallenen/festgeschriebenen Änderungen überschreibe. Wenn ich die Zusammenführung mit dem Master-Zweig nicht vorspulen kann, bedeutet dies, dass entweder jemand den Remote-Master neu aufgebaut hat (dafür muss er stark ausgepeitscht werden) oder ich habe aus Versehen den Master-Master festgelegt und muss mein Ende bereinigen.

Wenn sich dann die Fernbedienung geändert hat, habe ich mich schnell auf den neuesten Stand gebracht.

git checkout devel0
git rebase master
git Push -f Origin devel0

Andere Entwickler wissen dann, dass sie ihre Entwicklungszweige von meinem neuesten Stand entfernen müssen:

git fetch <remote>
git checkout devel1
git rebase <remote>/devel0

Welches führt zu einer viel saubereren Geschichte:

o-----o                                 master
       \
         o-----o-----o                  devel0
                      \
                        o-----o-----o   devel1

Nicht Zusammenführen von Commits nach Lust und Laune. Es erstellt nicht nur doppelte Commits und macht es unmöglich, die Historie zu verfolgen, sondern es wird fast unmöglich, Regressionen einer bestimmten Änderung zu finden (weshalb Sie in erster Linie die Versionskontrolle verwenden, oder?). Das Problem, das Sie haben, ist das Ergebnis davon.

Es klingt auch so, als ob andere Entwickler sich zu Ihren Entwicklungszweigen verpflichten könnten. Kannst du das bestätigen?

Die einzige Zeit zum Zusammenführen ist, wenn Ihr Zweigzweig in master aufgenommen werden kann.

Als Randnotiz. Wenn sich mehrere Entwickler für dasselbe Repository engagieren, sollten Sie alle in Betracht ziehen, benannte Zweige zu verwenden, um zwischen Entwicklungsentwicklungen von Entwicklern zu unterscheiden. Zum Beispiel:

git branch 'my-name/devel-branch'

Alle Zweigzweige der Entwickler befinden sich also in ihrem eigenen verschachtelten Satz.

77
Trevor Norris

Sie müssen den Push erzwingen, wenn Sie die Commits weiter entlang der Zeile verschieben. Git erwartet, dass Sie der Spitze des Zweigs Commits hinzufügen. git Push -f Origin myNewFeature wird Ihr Problem beheben.

Tipp: Oben ist eine legitime Anwendung von Gewaltanwendung. Schreiben Sie niemals die Historie auf ein öffentlich zugängliches Repository oder viele Leute werden Sie hassen. 

39
Learath2

Die Hauptsache, die hier im Hinterkopf behalten wird, ist, was Pull und Re-Base hinter den Kulissen tun.

Beim Ziehen werden im Wesentlichen zwei Dinge ausgeführt: Abrufen und Zusammenführen. Wenn Sie --rebase einbeziehen, wird anstelle der Zusammenführung eine neue Basis durchgeführt.

Eine Rebase ist fast so, als würden Sie alle Ihre lokalen Änderungen seit Ihrer Verzweigung verwahren, Ihren Zweig schnell zum letzten Commit des Ziels weiterleiten und Ihre Änderungen in der Reihenfolge oben aufheben.

(Dies erklärt, warum Sie möglicherweise mehrere Aufforderungen zur Konfliktlösung erhalten, wenn Sie eine Rebase gegen die eine Konfliktlösung ausführen, die Sie möglicherweise bei einer Zusammenführung erhalten.) Sie haben die Möglichkeit, einen Konflikt bei jeder Verpflichtung zu lösen, der neu angesiedelt wird, um Ihre Commits andernfalls beizubehalten. )

Sie möchten niemals Änderungen an abgelegenen Verzweigungen vornehmen, da dies die Historie neu schreibt. Natürlich ist es nie ein bisschen stark, da es fast immer Ausnahmen gibt. Der Fall, dass Sie eine Remote-Version Ihres lokalen Repositorys verwalten müssen, um beispielsweise in einer bestimmten Umgebung zu arbeiten.

Dies erfordert, dass Sie die basierten Änderungen zu bestimmten Zeitpunkten entweder mit Hilfe von Force verschieben:

git Push -f Origin newfeature

In einigen Fällen hat Ihr Administrator möglicherweise die Möglichkeit zum Erzwingen von Ermittlungen aufgehoben, sodass Sie ihn löschen und neu erstellen müssen:

git Push Origin :newfeature
git Push Origin newfeature

In beiden Fällen müssen Sie absolut sicher sein, dass Sie wissen, was Sie tun, wenn eine andere Person in Ihrem Remote-Zweig mit Ihnen zusammenarbeitet. Dies kann bedeuten, dass Sie zunächst mit Merges zusammenarbeiten und diese vor dem Mastering und Entfernen Ihres Arbeitszweigs in ein überschaubareres Commit-Format umwandeln.

Denken Sie daran, dass Sie fast immer auf gits GC zurückgreifen können, indem Sie Folgendes nutzen:

git reflog

Dies ist ein RIESIGER Lebensretter, da Sie sich auf einen stabileren Zustand zurücksetzen können, wenn Sie sich bei Ihrem gesamten Konfliktmanagement/Konfliktmanagement verlieren.

27
Matthew Sanders

Sie müssen einen erzwungenen Push ausführen, d. H. git Push -f Origin myNewFeature

Oh, und Sie sollten verdammt sicher sein, dass die Leute nichts auf Ihrem Entwicklungszweig aufbauen. Normalerweise sollten Sie keine Zweigstellen veröffentlichen, in denen Sie die Historie neu schreiben (oder die Historie nach der Veröffentlichung nicht neu schreiben). Eine Möglichkeit wäre, einen Verzweigungsnamen wie wip/myNewFeature zu verwenden und dann zu erwähnen, dass wip-Verzweigungen von Zeit zu Zeit für das Mastering neu basiert werden.

2
ThiefMaster

Die allgemeine Antwort, die bereits gegeben wurde - die Verwendung von git Push -f Origin myNewFeature, wenn Änderungen erneut vorgenommen werden - ist ein guter Ausgangspunkt. Ich schreibe diese Antwort, um die Bearbeitung zu bearbeiten, ob Ihr Workflow dadurch beeinträchtigt wird.

Wenn wir davon ausgehen, dass Sie git pull --rebase ... (oder eine Variation davon) verwenden, gefolgt von einem Force-Push auf den entfernten Zweig, dann führt der Entwickler, der den Workflow in Ihrem Beispiel unterbricht, myNewFeature in hisNewFeature ein. Es ist sinnvoll, in der Lage zu sein, Ihren eigenen Feature-Zweig neu aufzubauen, solange niemand anderes an diesem Zweig arbeitet. Sie benötigen also Regeln, um das Zweiggebiet abzugrenzen.

Sie können dies umgehen, indem Sie a) eine Regel festlegen, die Sie nur aus master zusammenführen, oder b) einen kollektiven develop-Zweig erstellen, auf dem Sie Ihren eigenen myNewFeature-Zweig aufbauen, und eine Regel festlegen, die Sie nur aus develop zusammenführen. master ist dann nur für Meilensteine ​​oder Releases reserviert (oder wie auch immer Sie dies einrichten möchten), und develop ist der Ort, an dem Sie jedes Feature per Push übertragen, wenn es für die Integration in andere Funktionszweige bereit ist.

Ich glaube, dass dies als vereinfachte Version des Gitflow-Workflows betrachtet werden kann.

1
cosmicFluke

Ich stimme zu MrCholo und vielleicht Trevor Norris könnte erwägen, seine gute Antwort zu aktualisieren zu ersetzen 

git Push -f Origin devel0

mit

git Push --force-with-lease Origin devel0
0
Sylvain Lesage