Mein typischer git-Workflow besteht darin, einen Feature-Zweig von unserem Master-Zweig abzuzweigen, kleine Commits zu machen und dabei periodisch vom Master zu verschmelzen, um Schritt zu halten.
Ich öffne dann eine Pull-Anfrage auf GitHub und wenn es akzeptiert wird, werde ich den Zweig löschen. Ich würde gerne interaktiv mehr Rebases machen, aber wenn ich das tue, werde ich Merge-Commits und Commits anderer Leute finden, die mit meinen eigenen verschachtelt sind. Ich bin mir nicht sicher, wie / wenn ich diese Commits zerquetschen oder meine Gruppe alleine zerquetschen kann?
Zum Beispiel könnte mein git-Protokoll für meinen Zweig so aussehen, wenn es Zeit für die erneute Erstellung ist:
%Vor%Ich habe Probleme mit dem, was möglich ist und was nicht, wenn ich eine interaktive Rebase mache und die Commits quittiere und neu ordne. Was würden Sie angesichts des obigen Arbeitsablaufs empfehlen?
Der Prozess, den wir in meinem Büro verwenden, besteht darin, auf den Zweig master (oder den Zweig, in den Sie voraussichtlich wechseln werden) umzulagern, bevor Sie Ihre Pull-Anforderung zusammenführen. Dies stellt sicher, dass Ihre Commits über alle anderen Commits in master angeordnet sind, was die Verschachtelung Ihrer Commits mit anderen verhindert:
Ich bin mir nicht sicher, wie / ob ich diese Commits zerquetschen oder meine Gruppe alleine gruppieren / quetschen kann?
Squash nur deine Commits nicht andere !!
Kürzlich hatte ich dasselbe Problem, ich hatte 41 Commits für meine Pull-Anfragen, mein Zweig hatte einen Merge-Konflikt und meine Pull-Anfrage war abgestanden. Ich musste mich mit einigen der Probleme auseinandersetzen, denen Sie jetzt gegenüberstehen. Ich werde nur etwas berühren, was ich implementiert habe.
%Vor%Ich empfehle Squash nur Ihre Commits (alle, wenn Sie wollen).
Wenn Sie zum Beispiel 3 Commits haben, können Sie sie zerquetschen und mit einer interaktiven Rebase zu einem Commit machen. Siehe folgenden Befehl:
%Vor%Sie möchten zum Beispiel 3 Commits quetschen:
%Vor%Jetzt sehen Sie eine interaktive Rebase-Schnittstelle, wo Sie reword / pick beim ersten Commit schreiben und auf den Rest von ihnen zugreifen können. Bitte lesen Sie dieses Video zum besseren Verständnis.
%Vor%Rebase zu anderen (jemand anderen) commits
Dies ist das allgemeine Problem, mit dem jeder bei der Verwendung von Git konfrontiert wird. Stellen Sie sich vor, Sie arbeiten an Ihrem lokalen Repo. Nachdem Sie einige Zeit gearbeitet haben, haben Sie einige Commits gemacht, jetzt möchten Sie sie zum ursprünglichen Remote-Repository verschieben. Cool, du hast das git push gemacht, was merge commit problem sagt.
Sie wissen, dass jemand anderes sich auch für dasselbe Remote Repo entschieden hat, das jetzt aktualisiert wird. Da Ihr lokaler Repo nicht auf den entfernten Repo aktualisiert wird, gibt es merge commit problem .
Was nun, wenn wir dieses Problem lösen? Können wir den Repo unseres lokalen Computers auf Ihren ursprünglichen Remote-Computer aktualisieren? Ist es möglich?
Ja, es ist möglich, Sie können es tun, indem Sie umlenken. Wie?
Wenn Sie das tun:
%Vor% Was passiert hier? Git wird alle lokalen Commits zurückspulen (rückgängig machen), die Remote-Commits herunterziehen und dann Ihre lokalen Commits über die neu gezogenen Remote-Commits wiederholen. Wenn Konflikte auftreten, die git nicht verarbeiten kann, haben Sie die Möglichkeit, die Commits manuell zusammenzuführen. Führen Sie dann einfach git rebase --continue aus, um die lokalen Commits weiter zu wiederholen.
Sehen Sie diesen Blogeintrag für mehr Details
Wenn Sie Ihren Zweig zum Master zusammenführen möchten?
Beste (und sicherste) Möglichkeit füge einen Git-Zweig in den Master ein