3 Schritte, um es zu schaffen! Führen Sie einen sauberen Git-Commit-Datensatz

Dieser Artikel vermittelt Ihnen relevantes Wissen über das Sauberhalten von GitCommit-Datensätzen, einschließlich Fragen im Zusammenhang mit „git commit –amend“, „git rebase -i“ und „rebase“.

Empfohlene Studie: „Git Tutorial“

Jeder hat gelernt, wie man Code auf standardisierte und prägnante Weise schreibt, aber selten lernt man, Code auf standardisierte und prägnante Weise einzureichen. Heutzutage verwendet jeder Git als Quellcode-Verwaltungstool. Wir übermitteln/zusammenführen Code gemäß verschiedenen Arbeitsabläufen. Wenn diese Flexibilität nicht gut kontrolliert wird, verursacht dies auch viele Probleme Unordentlicher Git-Log-Verlauf, der wirklich der Fußwickel einer alten Dame ist, stinkend und lang. Ich persönlich mag diese Art von Log nicht. Die Hauptursache für dieses Problem ist die zufällige Codeübermittlung.

Der Code wurde übermittelt. Gibt es eine Möglichkeit, ihn zu speichern? Drei Tipps können das Problem perfekt lösen

Machen Sie git commit –amend gut aus

Das Hilfedokument dieses Befehls wird wie folgt beschrieben:

--amend               amend previous commit

Mit anderen Worten, es kann uns helfen, den

letzten Commit zu ändern

beides Wir können die von uns übermittelte Nachricht und die von uns übermittelte Datei ändern und schließlich die letzte Commit-ID ersetzen. Wir können beim Senden eine bestimmte Datei übersehen, und wenn wir sie erneut senden, kann es zu mehreren nutzlosen Fehlern kommen commit-id, das macht jeder, und das Git-Protokoll wird nach und nach zu chaotisch, um die gesamte Funktion zu verfolgen

Angenommen, wir haben so eine Protokollinformation

* 98a75af (HEAD -> feature/JIRA123-amend-test) feat: [JIRA123] add feature 1.2
* 119f86e feat: [JIRA123] add feature 1.1
* 5dd0ad3 feat: [JIRA123] add feature 1
* c69f53d (origin/main, origin/feature/JIRA123-amend-test, origin/HEAD, main) Initial commit

Angenommen, wir möchten die letzte Protokollnachricht ändern Folgender Befehl:

git commit --amend -m "feat: [JIRA123] add feature 1.2 and 1.3"

Schauen wir uns noch einmal die Protokollinformationen an. Wir können feststellen, dass wir die alte Commit-ID 98a75af durch die neue Commit-ID 5e354d1 ersetzt, die Nachricht geändert und keine Knoten hinzugefügt haben

* 5e354d1 (HEAD -> feature/JIRA123-amend-test) feat: [JIRA123] add feature 1.2 and 1.3
* 119f86e feat: [JIRA123] add feature 1.1
* 5dd0ad3 feat: [JIRA123] add feature 1
* c69f53d (origin/main, origin/feature/JIRA123-amend-test, origin/HEAD, main) Initial commit

Jetzt Dateien in unserem Repo lauten wie folgt:

.
├── README.md
└── feat1.txt

0 directories, 2 files

Angenommen, wir haben beim Senden von Feature 1.3 eine Konfigurationsdatei config.yaml vergessen und möchten das Protokoll nicht ändern oder eine neue Commit-ID hinzufügen, dann ist der folgende Befehl sehr einfach use

echo "feature 1.3 config info" > config.yaml
git add .
git commit --amend --no-edit

git commit --amend --no-edit ist die Seele. Werfen wir einen Blick auf die aktuelle Repo-Datei:

.
├── README.md
├── config.yaml
└── feat1.txt

0 directories, 3 files

Werfen wir einen Blick auf das Git-Protokoll

* 247572e (HEAD -> feature/JIRA123-amend-test) feat: [JIRA123] add feature 1.2 and 1.3
* 119f86e feat: [JIRA123] add feature 1.1
* 5dd0ad3 feat: [JIRA123] add feature 1
* c69f53d (origin/main, origin/feature/JIRA123-amend-test, origin/HEAD, main) Initial commit

Wenn wir diese Technik kennen, können wir das sicherstellen Jede unserer Einsendungen enthält gültige Informationen. Ein Bild, das den Prozess beschreibt, sieht so aus:

Mit dem Buff-Bonus von --no-edit ist es leistungsfähiger

Machen Sie Git Rebase -i gut aus

Sie können sich das Protokoll oben ansehen Wir entwickeln Feature 1. Bevor wir den Feature-Zweig mit dem Hauptzweig zusammenführen, sollten wir mit dem Zusammenführen der Protokoll-Commit-Knoten fortfahren. Dies wird verwendet

git rebase -i HEAD~n

wobei n die letzten paar Commits darstellt. Oben haben wir drei Commits für Feature 1, also Sie kann Folgendes verwenden:

git rebase -i HEAD~3

Nach dem Ausführen wird ein vim-Editor mit dem folgenden Inhalt angezeigt:

 1 pick 5dd0ad3 feat: [JIRA123] add feature 1
 2 pick 119f86e feat: [JIRA123] add feature 1.1
 3 pick 247572e feat: [JIRA123] add feature 1.2 and 1.3
 4
 5 # Rebase c69f53d..247572e onto c69f53d (3 commands)
 6 #
 7 # Commands:
 8 # p, pick <commit> = use commit
 9 # r, reword <commit> = use commit, but edit the commit message
10 # e, edit <commit> = use commit, but stop for amending
11 # s, squash <commit> = use commit, but meld into previous commit
12 # f, fixup <commit> = like "squash", but discard this commit's log message
13 # x, exec <command> = run command (the rest of the line) using shell
14 # d, drop <commit> = remove commit
15 # l, label <label> = label current HEAD with a name
16 # t, reset <label> = reset HEAD to a label
17 # m, merge [-C <commit> | -c <commit>] <label> [# <oneline>]
18 # .       create a merge commit using the original merge commit's
19 # .       message (or the oneline, if no original merge commit was
20 # .       specified). Use -c <commit> to reword the commit message.
21 #
22 # These lines can be re-ordered; they are executed from top to bottom.
23 #
24 # If you remove a line here THAT COMMIT WILL BE LOST.
25 #
26 #   However, if you remove everything, the rebase will be aborted.
27 #
28 #
29 # Note that empty commits are commented out</commit></oneline></label></commit></commit></label></label></commit></command></commit></commit></commit></commit></commit>

Die am häufigsten verwendeten zusammengeführten Commit-IDs sind Squash und Fixup, letzteres nicht hier und dann :wq Exit

1 pick 5dd0ad3 feat: [JIRA123] add feature 1
2 fixup 119f86e feat: [JIRA123] add feature 1.1
3 fixup 247572e feat: [JIRA123] add feature 1.2 and 1.3

Schauen wir uns noch einmal das Protokoll an, es ist sehr klar

* 41cd711 (HEAD -> feature/JIRA123-amend-test) feat: [JIRA123] add feature 1
* c69f53d (origin/main, origin/feature/JIRA123-amend-test, origin/HEAD, main) Initial commit

Rebase gut nutzen

Das obige Feature1 wurde vollständig entwickelt, der Hauptzweig wurde auch von anderen aktualisiert, und dann das Feature wieder mit dem Hauptzweig zusammenführen. Im Falle von Codekonflikten müssen Sie zuerst den Inhalt des Hauptzweigs mit dem Feature zusammenführen. Wenn Sie den Zusammenführungsbefehl verwenden, gibt es dort einen zusätzlichen Zusammenführungsknoten wird auch ein Wendepunkt im Protokollverlauf sein, der nicht linear ist, also können wir hier den Rebase-Befehl für den Feature-Zweig verwenden

git pull origin main --rebase

Der Pull-Befehl hilft uns automatisch bei der Zusammenführung, aber hier in Form von rebase, werfen wir einen Blick auf das Protokoll

* d40daa6 (HEAD -> feature/JIRA123-amend-test) feat: [JIRA123] add feature 1
* 446f463 (origin/main, origin/HEAD) Create main.properties
* c69f53d (origin/feature/JIRA123-amend-test, main) Initial commit

Der Übermittlungsknoten unserer Funktion „feature1“ über main oder behält die Linearität bei, dann können Sie den Code pushen, dann eine PR senden und Ihr Feature mit dem Hauptzweig zusammenführen

Eine einfache Beschreibung des Unterschieds zwischen Merge und Rebase lautet:

Ich verwende hier git pull origin main --rebase, um den Vorgang des Wechselns von main und des Zurückziehens des neuesten Inhalts und des anschließenden Zurückschaltens zu vermeiden. Das Prinzip dahinter ist wie im Bild oben dargestellt ist eine goldene Regel, die man bei der Verwendung von Rebase befolgen sollte. Ich habe das schon einmal gesagt, deshalb werde ich es nicht mehr wiederholen. Mit diesen drei Tipps ist meiner Meinung nach jedermanns Git-Protokoll äußerst klar Wenn Sie es noch nicht wissen, können Sie es auf jeden Fall bewerben. Diese Art von Repo wird gesünder aussehen. Empfohlenes Lernen: „

Git Tutorial“

Das obige ist der detaillierte Inhalt von3 Schritte, um es zu schaffen! Führen Sie einen sauberen Git-Commit-Datensatz. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!