Git Merge einfach vs Squash. Was ist der Zweck? Wie verfolge ich ein Commit pro Feature?

Question

Eine Sache, die ich nicht mit Git mag, ist die Menge an Commits. Versteh mich nicht falsch, es ist eine sehr bequeme Methode, deine Arbeit sicher zu speichern, aber auf lange Sicht gibt es zu viel Granularität, um darin zu suchen.

Lassen Sie mich das folgende Szenario während der Entwicklung mit Feature-Zweigen von Entwicklung entwickeln beschreiben.

• Feature1 aus verzweigten entwickeln und hat 5 begeht
• Feature2 von entwickeln verzweigt ist und 3 begeht
• Feature3 von Feature1 verzweigt ist und 5 +2 verpflichtet.

Der Grund, warum es drei Zweige gibt, liegt daran, dass ein Team am Repository arbeitet. Feature3 geht davon aus, dass die Feature1 getan wird, warten auf zusammengeführt werden in entwickeln. Es gibt andere Anwendungsfälle dafür, aber dies ist das einfachste Beispiel.

Mein Ziel ist es, drei Commits auf entwickeln zu haben, wenn alle Funktionen erledigt sind.

git merge/Pull

Das obige Szenario funktioniert gut. Weil im Wesentlichen beide Befehle Commits in den Entwicklungszweig verschieben. Wenn Feature1 zusammengeführt wird, entwickeln Referenzen es ist fünf commits. Wenn Feature3 wird zusammengeführt werden, werden nur die letzten beiden Commits in entwickeln zusammengeführt werden.

Der einzige negative Aspekt davon ist, dass entwickeln bekommt zu viele Commits. Das bedeutet, dass beim Zusammenführen in Master all das "Rauschen" sich bewegt. Deshalb wird mein Ziel nicht erreicht.

git mit Squash fusionieren

Wenn Feature1 verschmolzen wird, wird entwickeln eine neue begehen, welche die Aggregation aller Feature1. Das ist sehr nett, da das Feature jetzt mit nur einem Commit verfolgt wird. Wenn Feature1 entfernt wird, sind alle Zwischen-Commits nicht mehr sichtbar, wodurch das Tracking vereinfacht wird. Dies entspricht auch Konzepten wie einer Pull-Anfrage und einem GitHub-Problem.

Wenn Feature3 zusammengeführt wird, gibt es Konflikte und das Problem beginnt. Um dies zu beheben, müssen Sie die Entwicklung zurück zu feature3 zusammenführen. mit Konflikten. Dies führt zu einem neuen Commit, bei dem null Dateien geändert wurden.Und jetzt verbinden wir Squash Feature3 zu entwickeln.

Mein Ziel ist erreicht, aber mit viel Micro-Management Opfer.

Fragen/Bemerkungen

Soweit ich verstehe dies die git Realität ist. Ein Rat, den ich gelesen habe, besteht darin, einen Nebenzweig zu erstellen, der den zerdrückten Merge-Commit enthält. Verwenden Sie den Nebenzweig für die Pull-Anforderung, wodurch die Verwendung eines Commits pro Feature erzwungen wird. Dies löst nicht die Konflikte, die beim Zusammenführen der anderen Zweige, insbesondere derjenigen, die von anderen Feature-Zweigen erben, erzeugt werden.

• Kann ich einen internen Squash innerhalb desselben Zweigs machen? Ich denke nicht, aber tut nicht weh zu fragen.
• Ich vermisse ich etwas?
• Ist das der Kompromiss von Squash Merge? Lösen von Konflikten, die möglicherweise keine Codeänderungen haben?
• Lohnt es sich, nach dem "one commit per feature" Konzept zu gehen?
  • Wenn nicht, was ist der Zweck von Squash? Wer benutzt das?

Ich habe Alternative mit rebase lesen und Simulation des Squash mit Reset nach merge, aber soweit ich verstehe nichts löst das Kopf erwähnt Feature3 zu verschmelzen.

Answer 1

Ja, der Zweck von Git mit so vielen Commits ist es, alle Änderungen nachverfolgbar zu machen. Wenn einige Commits nicht signifikant sind oder es in Ordnung ist, alle Änderungen in einem Commit aufzuzeichnen, um den Verlauf zu überprüfen, können Sie diese Commits natürlich unterdrücken.

Für Ihre Fragen:

1.Ja, können Sie ein internes Squash tun.Angenommen, Ihre git Geschichte als die Grafik unten begehen:

   K---L---M  Feature2 
      /
A---B---…---C---…    develop 
    \   
     D---E---F---G---H   Feature1 
         \ 
          I---J Feature3 

Sie diese Schritte können jeden Zweig quetschen:

git checkout Feature1 
git rebase -i HEAD~5 

Eingang i

pick D 
squash E 
squash F 
squash G 
squash H 

drücken Esc-Taste und dann Eingabe :wq

git checkout Feature3 
git rebase -i HEAD~7 

pick D 
squash E 
squash F 
squash G 
squash H 
squash I 
squash J 

git rebase Feature1 
git checkout Feature2 
git rebase -i HEAD~3 

pick K 
squash L 
squash M 

2. Ihr Prozess in Ordnung ist.
3. Zum Zusammendrücken von Commits sollte die erste (älteste) Verwendung pick sein, und andere können Squash verwenden, so dass die Verzweigung nur mit einem Commit angezeigt wird. Wenn ein Konflikt vorliegt, können Sie die Konfliktdateien ändern und speichern und dann git add . und git rebase --continue verwenden.
4. Es ist nicht notwendig und es hängt von Ihrem Liebling ab. Der Hauptzweck von Squash ist es, die Geschichte sauberer und klarer erscheinen zu lassen.

Answer 2

Ich glaube wirklich, Rebasing ist Ihre Lösung hier.

Wenn ich verstehe, ist die folgende Ihre git Struktur:

develop \ A - B - C [feature1] \ D - E [feature3]

Ihr Problem ist, wenn Sie zerquetscht haben und fusionierte feature1 um entwickeln, die ersten drei Commits Feature3 Referenzen existieren nicht mehr. Sie sind im Wesentlichen links wie folgt, außer Feature1 existiert nicht wirklich.

develop — feature1Merge \ A - B - C [feature1] \ D - E [feature3]

So ist die feature1Merge begehen in entwickeln in Feature3 ‚s Geschichte zu denen unterschiedlich ist.

In diesem Fall, wenn Sie auf Feature3 zurück zu rebase versuchten entwickeln, verpflichtet AB und C mit ihm gehen würde, was in der Theorie nicht zu Problemen führen sollte, da die Änderungen bereits sind auf Entwickeln Sie so git sollte nur diese Commits vorspulen. Offensichtlich scheint dies jedoch nicht zu geschehen.

Was ich in dieser Situation vorschlagen würde, ist ein rebase onto.

Rebase Auf

Die --onto Option können Sie bestimmte Commits rebase, anstatt eine ganze Branche.

So git zu stoppen zu verwenden versucht, begeht AB und C wenn Rebasing wir --onto verwenden, die drei Argumente verwendet:

• Die neue Basis für die Branche

• Die aktuelle Basis von der Zweig

• Der Name des Zweigs zu Rebase

In Ihrem Fall wäre dies:

git rebase --onto develop C feature3

Dies würde entwickeln überprüfen und dann gelten alle auf Feature3 seit C verpflichtet:

develop — feature1Merge \ D - E [feature3]

Hoffentlich macht das alles Sinn und erreicht, was du willst mit so wenig ha wie möglich!