Ich habe den klassischen OSS-Maintainer / Contributor-Git-Workflow für ein Unternehmensprojekt auf Github implementiert, aber ein Edge-Case erzeugt einige seltsame Ergebnisse, von denen ich nicht sicher bin, wie ich sie umgehen soll.
Nehmen wir an, dass es ein typisches Projekt gibt, das ich gegabelt habe und Upstream Remote hinzugefügt habe, um es auf dem neuesten Stand zu halten.
%Vor%Für die Zwecke dieses Beispiels ist diese Verzweigung durch einige Commits zurück.
%Vor%Ich arbeite an dieser Verzweigung und schiebe einige Commits, bevor ich meine letzte Commit-Operation drücke und eine Pull-Anfrage erstelle. Ich aktualisiere den Clone meiner Verzweigung, um sicherzustellen, dass es keine Konflikte gibt.
%Vor%Wenn ich jetzt versuche, auf meine Gabel zu drücken, werde ich abgelehnt.
%Vor%Was soll ich als nächstes tun? Alles was ich will ist, dass die Pull-Anfrage foo und bar Commits enthält, aber ...
Wenn ich pull verwende, enthält die Pull-Anfrage doppelte Foo-Commits sowie eine Extra-Merge-Eins.
Eine github-Pull-Anfrage sieht so aus.
%Vor% Wenn ich git pull --rebase anstelle von pull verwende, werden im besten Fall die Commits anderer Personen in meine Pull-Anfrage einbezogen (die von reset), und schlimmstenfalls gibt es Konflikte bei der Zusammenführung.
Wenn ich git push --force ohne pull oder --rebase benutze funktioniert es perfekt, aber ich bin sehr unruhig zu sagen, dass jeder die Kraft nutzen oder es Teil des Standard-Workflow machen, wie ich mir vorstellen kann, ein paar Leute oder ein kleines Subteam kollaboriert auf einer Gabel und tritt mit gezwungenem Stoß auf die Zehen.
Irgendwelche Ideen? Was vermisse ich?
Wenn Sie
%Vor%Sie schreiben Ihre eigene Historie neu, da Sie Ihre Master-Verzweigung auf dem aktualisierten Upstream-Repository neubasieren. Wenn du dein rebasiertes Repo zu deiner Gabel schiebst, beklagt sich git. Sie müssen mit --force
drücken %Vor%