Warum macht Squash Git Commits für Pull Requests?

200

Warum möchte jeder ernsthafte Github-Repo, für den ich Anfragen ziehe, dass ich meine Commits in einem einzigen Commit zusammenführe?

Ich dachte, das GIT-Protokoll wäre da, damit Sie Ihre gesamte Historie einsehen und genau sehen können, was sich an welcher Stelle geändert hat, aber wenn Sie es zerquetschen, wird es aus der Historie entfernt und alles wird zu einem Commit zusammengefasst. Was ist der Sinn?

Dies scheint auch gegen das Mantra "Frühzeitig und häufig festlegen" zu verstoßen.

hamstar
quelle
1
Für ein großes Repo spart es viel Zeit und Platz, wenn die Leute etwas mit dem Repo anfangen wollen.
Raptortech97
8
" Dies scheint auch gegen das Mantra" Frühes Festschreiben und häufiges Festschreiben "zu verstoßen. - Nein, Sie legen früh / häufig fest, aber Sie möchten nicht unbedingt jede kleine Änderung PR. Und der Rezensent möchte sie nicht durchsehen, das ist sicher.
JensG
7
Die Frage muss nicht bearbeitet werden, um die wahrgenommene Antwort zusammenzufassen. Das ist der Ort akzeptierter Antworten und Gegenstimmen. Menschen können ihre eigenen Schlussfolgerungen aus dem Lesen der Antworten ziehen.
5
Ich verstehe immer noch nicht, warum es einen Wunsch gibt, Verpflichtungen zu quetschen. Ich denke, es gibt viel zu viele Nachteile, um mit fast keinem Pro zu kämpfen. Es ist ein Präsentationsproblem, das sich als Datenproblem tarnt.
Mkobit
3
Nützliche Analysen im Protokoll gehen durch Kürbisse verloren. Es scheint also, als hätte ein Entwickler ein Feature mit einem einzigen Commit erstellt. Es ist auch schwer zu verstehen, warum ein seltsames Stück Code existiert. Der Verlauf eines Features kann wichtig sein und einen langen Weg weisen, um zu erklären, warum Code so ist, wie er ist. Die übersichtliche Darstellung des Protokolls ist hilfreich, kann jedoch nicht auf andere Weise erreicht werden?
Tjaart

Antworten:

158

Damit Sie eine klare und prägnante Git-Historie haben, die die vorgenommenen Änderungen und die Gründe dafür klar und einfach dokumentiert.

Zum Beispiel könnte ein typisches 'unsquashed' Git-Log für mich so aussehen:

7hgf8978g9... Added new slideshow feature, JIRA # 848394839
85493g2458... Fixed slideshow display issue in ie
gh354354gh... wip, done for the week
789fdfffdf... minor alignment issue
787g8fgf78... hotfix for #5849564648
9080gf6567... implemented feature # 65896859
gh34839843... minor fix (typo) for 3rd test

Was für ein Chaos!

Während ein sorgfältig verwaltetes und zusammengeführtes Git-Protokoll mit einem kleinen zusätzlichen Fokus auf die Nachrichten dafür wie folgt aussehen könnte:

7hgf8978g9... 8483948393 Added new slideshow feature
787g8fgf78... 5849564648 Hotfix for android display issue
9080gf6567... 6589685988 Implemented pop-up to select language

Ich denke, Sie können den Punkt des Quetschens von Commits im Allgemeinen erkennen und dasselbe Prinzip gilt für Pull-Anfragen - Lesbarkeit der Historie. Sie können auch ein Commit-Protokoll hinzufügen, das bereits Hunderte oder sogar Tausende von Commits enthält. Auf diese Weise können Sie den wachsenden Verlauf kurz und präzise halten.

Sie möchten sich früh und häufig festlegen. Es ist aus vielen Gründen eine bewährte Methode. Ich stelle fest, dass ich häufig Commits habe, die "wip" (in Bearbeitung) oder "part A done" oder "typo, minor fix" sind, bei denen ich git verwende, um zu arbeiten und mir Arbeitspunkte zu geben Ich kann zurückgehen, wenn der folgende Code nicht funktioniert, während ich Fortschritte mache, um die Dinge zum Laufen zu bringen. Ich brauche oder möchte diese Historie jedoch nicht als Teil der finalen Git-Historie, damit ich meine Commits quetschen kann. Beachten Sie jedoch die nachstehenden Hinweise dazu, was dies für einen Entwicklungszweig im Vergleich zu einem Master bedeutet.

Wenn es wichtige Meilensteine ​​gibt, die unterschiedliche Arbeitsphasen darstellen, ist es immer noch in Ordnung, mehr als ein Commit pro Feature / Task / Fehler zu haben. Dies kann jedoch häufig die Tatsache hervorheben, dass das Ticket in der Entwicklung "zu groß" ist und in kleinere Teile zerlegt werden muss, die eigenständig sein können, zum Beispiel:

8754390gf87... Implement feature switches

scheint wie "1 Stück Arbeit". Entweder existieren sie oder nicht! Es scheint keinen Sinn zu machen, es herauszubrechen. Die Erfahrung hat jedoch gezeigt, dass (abhängig von der Größe und Komplexität der Organisation) ein differenzierterer Pfad sein kann:

fgfd7897899... Add field to database, add indexes and a trigger for the dw group
9458947548g... Add 'backend' code in controller for when id is passed in url.
6256ac24426... Add 'backend' code to make field available for views.
402c476edf6... Add feature to UI

Kleine Teile bedeuten einfachere Codeüberprüfungen, einfachere Komponententests, bessere Qa-Möglichkeiten, bessere Ausrichtung auf das Prinzip der Einzelverantwortung usw.

Für die praktische Durchführung solcher Kürbisse gibt es grundsätzlich zwei verschiedene Phasen, die ihren eigenen Arbeitsablauf haben

  • Ihre Entwicklung, zB Pull-Anfragen
  • Ihre Arbeit wurde dem Hauptzweig hinzugefügt, z. B. master

Während Ihrer Entwicklung legen Sie "früh und häufig" und mit schnellen "Wegwerf" -Botschaften fest. Möglicherweise möchten Sie hier gelegentlich einen Squash ausführen, z. B. Wip-Squashing und Nachrichten-Commits ausführen. Innerhalb des Zweigs ist es in Ordnung, mehrere Festschreibungen zu speichern, die unterschiedliche Schritte darstellen, die Sie in der Entwicklung durchgeführt haben. Die meisten Kürbisse, die Sie auswählen, sollten sich in diesen Feature-Zweigen befinden, während sie entwickelt werden und bevor sie zum Master zusammengeführt werden.
Beim Hinzufügen zum Hauptleitungszweig möchten Sie, dass die Festschreibungen präzise sind und entsprechend der vorhandenen Hauptleitungshistorie korrekt formatiert werden. Dies kann die Ticket Tracker-System-ID enthalten, z. B. JIRA, wie in den Beispielen gezeigt. Squashing wird hier nicht wirklich angewendet, es sei denn, Sie möchten mehrere verschiedene Commits auf dem Master "zusammenfassen". Normalerweise nicht.

Unter Verwendung --no-ffbeim Zusammenführen zu meistern wird ein für die merge commit verwenden und auch Geschichte zu erhalten (im Zweig). Einige Organisationen halten dies für eine bewährte Methode. Weitere Informationen finden Sie unter https://stackoverflow.com/q/9069061/631619. Sie sehen auch den praktischen Effekt, in git logdem ein --no-ffCommit das letzte Commit oben im HEAD ist (wenn es gerade ausgeführt wurde), während --no-ffdies möglicherweise nicht der Fall ist weiter unten in der Geschichte, abhängig von Daten und anderen Verpflichtungen.

Michael Durrant
quelle
30
Ich stimme dieser Philosophie überhaupt nicht zu. Kleine regelmäßige Festschreibungen unterteilen eine Aufgabe in kleinere Aufgaben und geben häufig nützliche Informationen darüber, woran gerade gearbeitet wurde, als eine Zeile geändert wurde. Wenn Sie kleine "WIP" -Commits haben, sollten Sie eine interaktive Rebase verwenden, um diese zu bereinigen, bevor Sie sie verschieben. Squashing PRs scheinen den Punkt der regulären Small Commits meiner Meinung nach völlig zu besiegen. Es ist fast respektlos für den Autor, der sich die Mühe gemacht hat, Protokollnachrichten mit spezifischen Commit-Informationen zu geben, und Sie werfen alles einfach weg.
Jez
6
Interessant. Am Ende des Tages stütze ich meine "Philosophie" auf das, was ich gesehen habe. Klar zu sein - die Arbeit in kleine Teile zu zerlegen und sich alle zu engagieren, ist großartig, wenn man an der Veränderung arbeitet. Ich habe die Erfahrung gemacht, dass nach dem Zusammenführen dieser Arbeit zum Master die Hauptsache ist, die untersucht wird: "Was, in seiner Gesamtheit, ist dieses Zusammenführungs-Commit, das (normalerweise) Probleme verursacht hat?"
Michael Durrant
6
Ich bin auch Anti-Squash. Sie sollten in erster Linie keine dummen Commit-Nachrichten schreiben. Und im Beispiel (85493g2458 ... Problem mit der Diashow-Anzeige in IE behoben). Das wäre viel hilfreicher, wenn ich den dazugehörigen Code debuggen würde.
Thomas Davis
5
Es ist bedauerlich, dass in der SCM-Praxis ein solches unvorsichtiges und verlegtes Dogma aufgetaucht ist. Filterwerkzeuge sollten verwendet werden, um die Lesbarkeit des Verlaufs zu verwalten, ohne das Verhalten zu bestätigen.
Ctpenrose
4
beunruhigende Tendenzen und Dogmen. ja. Ich würde ein sachbezogeneres Argument bevorzugen, das auf angenehmere Weise präsentiert wird. Sie können gerne eine andere Meinung abgeben / abstimmen. Das ist der Punkt, an dem die Community abstimmt
Michael Durrant,
26

Weil sich die Person, die eine PR zieht, oft um den Nettoeffekt des Commits "Added Feature X" kümmert, nicht um die "Base Templates", Bugfix-Funktion X, Add-Funktion Y, feste Tippfehler in Kommentaren, angepasste Daten-Skalierungsparameter, Hashmap-Leistung besser als list "... Detaillierungsgrad

Wenn Sie der Meinung sind, dass Ihre 16 Commits am besten durch 2 Commits und nicht durch 1 "Feature X hinzugefügt, Z neu faktorisiert, um X zu verwenden" dargestellt werden, ist dies wahrscheinlich in Ordnung, um einen PR mit 2 Commits vorzuschlagen, aber dann ist es möglicherweise am besten, dies vorzuschlagen In diesem Fall 2 separate Prs (wenn der Repo immer noch auf einzelnen Commit-Prs besteht)

Dies steht nicht im Widerspruch zum Mantra "Frühes und häufiges Festschreiben", wie in Ihrem Repo, während Sie sich weiterentwickeln, haben Sie immer noch die detaillierten Details, sodass Sie nur eine minimale Chance haben, Arbeit zu verlieren, und andere Personen können prüfen / ziehen / vorschlagen PR ist gegen deine Arbeit, während der neue PR entwickelt wird.

Andrew Hill
quelle
4
Aber wenn Sie Squash-Commits machen, verlieren Sie diese Geschichte auch in Ihrer Gabel, oder? Warum würdest du diese Geschichte wegwerfen wollen?
Hamstar
4
a) Wenn Sie die Historie in Ihrem Zweig beibehalten möchten, ist es einfach genug, einen Zweig "zum Zusammenführen" und einen Zweig "Entwickler" zu haben (was möglicherweise sowieso erforderlich ist, da Sie Ihrem Hauptentwickler neue Commits hinzufügen könnten Verzweigen Sie, nachdem Sie die PR vorgeschlagen haben.) b) Sie behalten immer noch die Nettowirkung dieser Commits bei. Nur in den Fällen, in denen Sie eine Unterkomponente der PR rückgängig machen oder eine Cherry-Auswahl treffen möchten, wären die einzelnen Commits erforderlich . In diesem Fall erledigen Sie wahrscheinlich mehrere Aufgaben (z. B. Bugfix X, Feature Y hinzufügen) in einer einzelnen PR, und es können erneut mehrere PRs erforderlich sein.
Andrew Hill
@ AndrewHill was für ein tolles Konzept! Ich möchte diesen Workflow meinem Team vorstellen. Wie hat er für Sie funktioniert? Ich habe einen Blog-Beitrag darüber geschrieben und bin bei der Recherche auf diesen Kommentar gestoßen.
Droogans
19

Der Hauptgrund für das, was ich sehen kann, ist folgender:

  • In der GitHub-Benutzeroberfläche zum Zusammenführen von Pull-Anforderungen (Okt. 2015) können Sie die erste Zeile der Festschreibungsnachricht nicht bearbeiten und müssen sie daher zwingen Merge pull request #123 from joebloggs/fix-snafoo
  • Die GitHub-Benutzeroberfläche zum Durchsuchen des Festschreibungsverlaufs ermöglicht es Ihnen derzeit nicht, den Verlauf des Zweigs aus der --first-parentSicht anzuzeigen
  • Die GitHub-Benutzeroberfläche zum Anzeigen der Schuld an einer Datei ermöglicht es Ihnen derzeit nicht, die Schuld an einer Datei aus der --first-parentSicht anzuzeigen (beachten Sie, dass dies nur in Git 2.6.2 behoben wurde, sodass wir GitHub verzeihen konnten, dass dies nicht der Fall war verfügbar)

Wenn Sie also alle drei oben genannten Situationen kombinieren, erhalten Sie eine Situation, in der nicht gequetschte Commits, die zusammengeführt werden, auf der GitHub-Benutzeroberfläche hässlich aussehen.

Ihr Verlauf mit gequetschten Commits sieht ungefähr so ​​aus

1256556316... Merge pull request #423 from jrandom/add-slideshows
7hgf8978g9... Added new slideshow feature
56556316ad... Merge pull request #324 from ahacker/fix-android-display
787g8fgf78... Hotfix for android display issue
f56556316e... Merge pull request #28 from somwhere/select-lang-popup
9080gf6567... Implemented pop-up to select language

Während ohne gequetschte Commits die Geschichte ungefähr so ​​aussieht

1256556316... Merge pull request #423 from jrandom/add-slideshows
7hgf8978g9... Added new slideshow feature, JIRA # 848394839
85493g2458... Fixed slideshow display issue in ie
gh354354gh... wip, done for the week
789fdfffdf... minor alignment issue
56556316ad... Merge pull request #324 from ahacker/fix-android-display
787g8fgf78... hotfix for #5849564648
f56556316e... Merge pull request #28 from somwhere/select-lang-popup
9080gf6567... implemented feature # 65896859
gh34839843... minor fix (typo) for 3rd test

Wenn Sie in einer PR-Ablaufverfolgung viele Commits haben, bei denen eine Änderung eingetreten ist, kann dies zu einem Albtraum werden, wenn Sie sich auf die Verwendung der GitHub-Benutzeroberfläche beschränken .

Sie finden beispielsweise einen Nullzeiger, auf den irgendwo in einer Datei nicht mehr verwiesen wird. Sie sagen also "Wer hat das getan und wann? Welche Release-Versionen sind betroffen?". Dann wandern Sie zur Schuldansicht in der GitHub-Benutzeroberfläche und sehen, dass die Zeile in geändert wurde789fdfffdf... "Oh, aber warte mal, die Einrückung dieser Zeile wurde nur so geändert, dass sie in den Rest des Codes passt." Nun müssen Sie zum Baumstatus für diese Datei im übergeordneten Festschreiben navigieren und erneut besuchen die Schuld Seite ... irgendwann finden Sie das Commit ... es ist ein Commit von vor 6 Monaten ... "Oh, das könnte die Benutzer für 6 Monate beeinflussen", sagen Sie ... ah, aber warten Sie, das Commit war eigentlich in einem Pull Request und wurde erst gestern zusammengeführt und noch hat niemand eine Veröffentlichung gekürzt ... "Verdammt ihr Leute für das Zusammenführen von Commits ohne die Geschichte zu quetschen" ist der Schrei, der normalerweise nach etwa 2 oder 3 Code-Archäologie-Expeditionen über das Internet zu hören ist GitHub UI

Lassen Sie uns nun überlegen, wie dies funktioniert, wenn Sie die Git-Befehlszeile verwenden (und Super-Awesome 2.6.2, für das es das Update gibt git blame --first-parent).

  • Wenn Sie die Git-Befehlszeile verwenden, können Sie die Merge-Commit-Nachricht vollständig steuern, sodass das Merge-Commit eine schöne Zusammenfassungszeile haben kann.

So würde unsere Commit-Historie aussehen

$ git log
1256556316... #423 Added new slideshow feature
7hgf8978g9... Added new slideshow feature, JIRA # 848394839
85493g2458... Fixed slideshow display issue in ie
gh354354gh... wip, done for the week
789fdfffdf... minor alignment issue
56556316ad... #324 Hotfix for android display issue
787g8fgf78... hotfix for #5849564648
f56556316e... #28 Implemented pop-up to select language
9080gf6567... implemented feature # 65896859
gh34839843... minor fix (typo) for 3rd test

Aber wir können es auch tun

$ git log --first-parent
1256556316... #423 Added new slideshow feature
56556316ad... #324 Hotfix for android display issue
f56556316e... #28 Implemented pop-up to select language

(Mit anderen Worten: Mit der Git CLI können Sie Ihren Kuchen haben und ihn auch essen.)

Wenn wir nun auf das Nullzeiger-Problem stoßen ... nun, wir verwenden es einfach git blame --first-parent -w dodgy-file.cund erhalten sofort das genaue Commit, bei dem die Nullzeiger-De-Referenz in den Master-Zweig eingefügt wurde, wobei einfache Leerzeichenänderungen ignoriert wurden.

Natürlich, wenn Sie Merges mit der GitHub-Benutzeroberfläche durchführen, git log --first-parentist das wirklich beschissen, da GitHub die erste Zeile der Merge-Commit-Nachricht erzwingt:

1256556316... Merge pull request #423 from jrandom/add-slideshows
56556316ad... Merge pull request #324 from ahacker/fix-android-display
f56556316e... Merge pull request #28 from somwhere/select-lang-popup

Um es kurz zu machen:

Die GitHub-Benutzeroberfläche (Okt. 2015) weist eine Reihe von Mängeln bei der Zusammenführung von Pull-Anforderungen, der Darstellung des Commit-Verlaufs und der Attributierung von Schuldinformationen auf. Die derzeit beste Möglichkeit, diese Fehler in der GitHub-Benutzeroberfläche zu umgehen, besteht darin, die Benutzer aufzufordern, ihre Commits vor dem Zusammenführen zu quetschen.

In der Git-CLI gibt es diese Probleme nicht, und Sie können einfach auswählen, welche Ansicht Sie anzeigen möchten, damit Sie beide den Grund für eine bestimmte Änderung ermitteln können (indem Sie sich den Verlauf der nicht unterdrückten Festschreibungen ansehen) siehe die effektiv gequetschten Commits.

Post Script

Der letzte Grund, der häufig für das Squashing von Commits genannt wird, ist die Erleichterung des Backports. Wenn Sie nur ein Commit für den Backport haben (dh das Squashed-Commit), ist es einfach, das richtige zu finden.

Wenn Sie sich den Git-Verlauf ansehen git log --first-parent, können Sie einfach die Merge-Commits auswählen. Die meisten Leute sind verwirrt, weil Sie die -m NOption angeben müssen, aber wenn Sie den Commit erhalten haben git log --first-parent, wissen Sie, dass dies das erste übergeordnete Element ist, dem Sie folgen möchtengit cherry-pick -m 1 ...

Stephen Connolly
quelle
1
Gute Antwort! Aber ein Sortiment mit Kirschen zu pflücken ist einfach genug, ich bin mir nicht sicher, ob ich es als Grund dafür kaufe.
Stiggler
1
@stiggler Ich persönlich kaufe es nicht als Grund, aber ich habe es von anderen als Grund angeführt gesehen. Meiner Meinung nach ist das Git-Tool genau das, was Sie wollen, und das Zusammendrücken von Commits ist böse ... aber ich würde sagen, dass ich das Fixieren --first-parentmeiner selbst vorangetrieben habe, um ein Argument gegen das Zusammendrücken von Commits zu gewinnen ;-)
Stephen Connolly
1
Dies sollte die akzeptierte Antwort sein. Weit weniger Dogma und es zeigt, dass die Verlaufsfilterung verwendet werden kann, um "Ihren Kuchen zu haben und ihn auch zu essen". Sie müssen die Geschichte nicht vernichten, um die Erkundung der Git-Geschichte zu verdeutlichen.
CTPENROSE
Es wird nicht so einfach sein, eine Auswahl zu treffen, wenn Sie durch das Zusammendrücken Ihrer Commits am Ende viele Änderungen an verschiedenen Dateien zu einem einzigen Commit zusammenfassen. Ich schätze, das hängt stark von der Codebasis ab, welche Änderungen vorgenommen wurden, wie viele Personen zusammenarbeiten und so weiter. Ich glaube nicht, dass wir eine einzige allgemeine Regel finden können, die in allen Fällen gültig ist.
Amy Pellegrini
2

Ich stimme den in anderen Antworten in diesem Thread zum Ausdruck gebrachten Ansichten zu, wonach ein klarer und prägnanter Verlauf der hinzugefügten Funktionen und behobenen Fehler angezeigt werden soll. Ich wollte jedoch auf einen anderen Aspekt eingehen, auf den Ihre Frage nicht eingegangen ist, den Sie jedoch nicht ausdrücklich ausgeführt haben. Ein Teil des Problems, das Sie möglicherweise mit einigen der Arbeitsmethoden von git haben, ist, dass Sie mit git den Verlauf neu schreiben können, was seltsam erscheint, wenn Sie in git eingeführt werden, nachdem Sie andere Formen der Quellcodeverwaltung verwendet haben, bei denen solche Aktionen unmöglich sind. Darüber hinaus verstößt dies auch gegen das allgemein anerkannte Prinzip der Quellcodeverwaltung, dass Sie nach dem Festschreiben / Einchecken in die Quellcodeverwaltung in diesen Zustand zurückkehren können sollten, unabhängig davon, welche Änderungen Sie nach dem Festschreiben vornehmen. Wie Sie in Ihrer Frage implizieren, ist dies eine dieser Situationen. Ich denke, Git ist ein großartiges Versionskontrollsystem. Um es jedoch zu verstehen, müssen Sie einige der Implementierungsdetails und die Entwurfsentscheidungen dahinter verstehen. Infolgedessen weist es eine steilere Lernkurve auf. Denken Sie daran, dass git ein verteiltes Versionskontrollsystem sein sollte, und dies hilft zu erklären, warum die Designer das Umschreiben des Git-Verlaufs zulassen, wobei Squash-Commits ein Beispiel dafür sind.

Fred Thomsen
quelle
Genau genommen erlaubt Git Ihnen nicht, den Verlauf zu ändern. Commit- Objekte sind unveränderlich. Es sind nur Zweigzeiger , die veränderbar sind, und nur dann mit einem "erzwungenen Update", das im Allgemeinen als etwas angesehen wird, das Sie nur für Entwicklungszwecke ausführen, nicht für den Hauptzweig. Mit dem Reflog können Sie jederzeit zu einem vorherigen Status zurückkehren, es sei denn, es git gcwurde ausgeführt, um nicht referenzierte Objekte zu verwerfen.
Jon Purdy
Sie haben Recht, und ich hätte das vielleicht oben erwähnen sollen. Ich würde mich jedoch für eine Art Force-Push aussprechen oder Commits, die bereits auf ein Remote-Repo verschoben wurden, als Writing-History qualifizieren, da die Reihenfolge und Anordnung der Commits genauso wichtig sind wie die Commits selbst.
Fred Thomsen
Das gilt für ein bestimmtes Commit. Im Großen und Ganzen stelle ich mir vor, dass interaktives Umbasieren und Filtern die Geschichte effektiv umschreiben, indem man ihre Zusammensetzung ändert.
Michael Durrant
1
Um ehrlich zu sein, behält SVN den Ansatz "Jeder Commit ist heilig" bei, aber beim Zusammenführen wird ein einziger Commit mit diesem Merge erstellt und die dazu beigetragenen Überarbeitungen ausgeblendet, sodass es so aussieht, als ob alle SVN-Merges "neu basieren". Dies ist nicht der Fall, Sie müssen lediglich den Befehl history angeben, um die zusammengeführten Komponenten anzuzeigen. Ich mag diesen Ansatz am besten.
Gbjbaanb
1

Aufgrund der Perspektive ... Die beste Vorgehensweise ist, <<issue-management-system>>wenn möglich, ein einzelnes Commit pro Ausgabe durchzuführen.

Sie können beliebig viele Commits in Ihrem eigenen Feature-Zweig / Repo haben, aber es ist Ihre Historie, die für das, was Sie jetzt für IHRE Perspektive tun, relevant ist. Es ist nicht die GESCHICHTE für das gesamte TEAM / PROJEKT oder die Anwendung von diesem Perspektive wird in einigen Monaten beibehalten ...

Wenn Sie also eine Fehlerbehebung oder ein Feature für ein allgemeines Repo durchführen möchten (in diesem Beispiel für den Entwicklungszweig), können Sie dies folgendermaßen tun:

So bauen Sie Ihre Feature-Verzweigung schnell wieder auf

    # set your current branch , make a backup of it , caveat minute precision
    curr_branch=$(git rev-parse --abbrev-ref HEAD); git branch "$curr_branch"--$(date "+%Y%m%d_%H%M"); git branch -a | grep $curr_branch | sort -nr

    # squash all your changes at once 
    git reset $(git merge-base develop $curr_branch)

    # check the modified files to add 
    git status

    # add the modified files dir by dir, or file by file or all as shown
    git add --all 

    # check once again 
    git log --format='%h %ai %an %m%m %s'  | less

    # add the single message of your commit for the stuff you did 
    git commit -m "<<MY-ISSUE-ID>>: add my very important feature"

    # check once again 
    git log --format='%h %ai %an %m%m %s'  | less

    # make a backup once again , use seconds precision if you were too fast ... 
    curr_branch=$(git rev-parse --abbrev-ref HEAD); git branch "$curr_branch"--$(date "+%Y%m%d_%H%M"); git branch -a | grep $curr_branch | sort -nr

    # compare the old backup with the new backup , should not have any differences 
    git diff <<old-backup>>..<<new-backup-branch>>


    # you would have to git push force to your feature branch 
    git push --force 
Jordan Georgiev
quelle
Dies versucht nicht einmal, die Frage zu beantworten, warum Squash Git sich für Pull-Anfragen einsetzt. Sehen Sie, wie man antwortet
Mücke
nach dem erklärungsversuch sollte es
klappen
Ich kann nicht irgendwie sehen , wie hinzugefügt Erklärung alles wesentliche über Punkte bietet gemacht und erklärt in Top-gestimmt Antworten , die vor einigen Jahren geschrieben wurden (Aufwand bei der ersten Revision verbessern wird geschätzt , obwohl)
gnat
das Schlüsselwort ist die "Perspektive", das Perspektivenkonzept erleichtert beispielsweise die Erklärung derartiger Probleme in der IT erheblich - Ihre Perspektive für die Beantwortung dieser Frage ist die bereits bereitgestellte, meine Perspektive verwendet das Schlüsselwort "Perspektive" und ein praktisches Beispiel für die Implementierung derselben bewährten Methode, erklärt aus verschiedenen Perspektiven ...
Yordan Georgiev,
1

Ich würde sehen, ob der Code öffentlich wird oder nicht.

Wenn Projekte privat bleiben:

Ich würde empfehlen, nicht zu quetschen und die Herstellung der Wurst zu sehen. Wenn Sie gute und kleine Commits verwenden, sind Tools wie git bisect sehr praktisch und die Benutzer können schnell Regressions-Commits ermitteln und sehen, warum Sie dies getan haben (aufgrund der Commit-Meldung).

Wenn Projekte an die Öffentlichkeit gehen:

Squash alles, weil einige Commits Sicherheitslücken enthalten können. Zum Beispiel ein Passwort, das bestätigt und wieder entfernt wurde.

Vince V.
quelle