Machen Sie Ihren Git-Commit-Verlauf mit drei Codezeilen sauber

Dieser Artikel vermittelt Ihnen relevantes Wissen über Git. Es geht hauptsächlich darum, wie Sie Ihre Git-Datensätze sauber halten. Ich hoffe, dass er für alle hilfreich ist.

Vorwort

Der Autor leitete kürzlich die Architekturmigrationsarbeit eines Projekts. Aufgrund der hohen historischen Belastung des Migrationsprojekts und der großen Anzahl an Personalkooperationen ist es unvermeidlich, währenddessen mehrere Zweige und Commits durchzuführen Der Migrationsprozess ist im Laufe der Zeit im Chaos. Ich habe nur einen grafischen Git-Übermittlungsverlauf erstellt, um Ihnen ein Gefühl zu geben.

Verschiedene Zweige kämpfen wie verrückt in einem Harem, genau wie Konkubinen im Harem um Gunst konkurrieren. Der Grund, warum diese Situation auftritt, ist hauptsächlich auf den Missbrauch des Git-Merge-Befehls und das Fehlen nachfolgender Verständniskosten zurückzuführen. Programmierer, die heute in großen Fabriken arbeiten, akzeptieren häufig Änderungen, wenn sie zu Beginn nicht sorgfältig überlegt werden. In Verbindung mit der Förderung des „agilen“ Konzepts werden die Produkte schnell iteriert. Nachdem sie zu Kernindikatoren geworden waren, wurden diese bedeutungslosen Festschreibungsprotokolle „das nächste Mal verarbeitet“ und wurden mit der Zeit chaotisch.

Wenn wir uns einige Open-Source-Repositorys ansehen, werden wir feststellen, dass ihre Commit-Datensätze sehr ordentlich sind. Das liegt tatsächlich nicht daran, dass die Programmierer in der Community leistungsfähiger sind, sondern daran, dass sie keine KPI-Sticks haben, um sie zu peitschen. und sie verbringen Zeit damit, Ihr eigenes Commit-Protokoll zu organisieren, bevor Sie den Code einreichen. Und das ist der Protagonist dieses Artikels: „Git Rebase“.

Git Rebase und Git Merge

Git Rebase, auf Chinesisch als „Rebase“ übersetzt, wird normalerweise zum Zusammenführen von Zweigen verwendet. Da das Zusammenführen von Zweigen erwähnt wird, muss der Befehl git merge unverzichtbar sein. git merge这个命令。

相信每个新手程序员刚进入职场的时候，都会听到“xxx你把这个分支merge一下”这样的话。那么问题来了，假如你有6个程序员一起工作， 你就会有6个程序员的分支， 如果你使用merge, 你的代码历史树就会有六个branch跟这个主的branch交织在一起。

上图是 git merge 操作的流程示意图，Merge命令会保留所有commit的历史时间。每个人对代码的提交是各式各样的。尽管这些时间对于程序本身并没有任何意义。但是merge的命令初衷就是为了保留这些时间不被修改。于是也就形成了以merge时间为基准的网状历史结构。每个分支上都会继续保留各自的代码记录，主分支上只保留merge的历史记录。子分支随时都有可能被删除。子分子删除以后，你能够看到的记录也就是，merge某branch到某branch上了。这个历史记录描述基本上是没有意义的。

而 git rebase 中文翻译为“变基”，变得这个基指的是基准。如何理解这个基准呢？我们看一下下图。

我们可以看到经过变基后的feature分支的基准分支发生了变化，变成了最新的master。这就是所谓的“变基”。

通过上面的两张图可以很明显的发现，这两种合并分支的方式最大的区别在于，merge后的分支，会保留两个分支的操作记录，这在git commit log 树中会以交叉的形式保存。而rebase后的分支会基于最新的master分支，从而不会形成分叉，自始至终都是一条干净的直线。

关于 git rebase 和 git merge 的详细用法不在本文的介绍范围内，详情可以参考互联网上的其他资料。

在变基过程中，我们通常需要进行commit的修改，而这也为我们整理git记录提供了一个可选方案。

保持最近的几条记录整洁

假设我们有一个仓库，我在这个仓库里执行了4次提交，通过 git reflog 命令查看提交记录如下。

如果我们想将Commit-3、Commit-2和Commit-1的提交合并成一次提交（假设某次提交至改了一些pom文件），我们可以直接执行下面的命令

git rebase -i HEAD~3

-i 指的是 --interactive ，HEAD~3

Ich glaube, dass jeder Programmieranfänger beim ersten Betreten des Arbeitsplatzes die Worte „xxx, bitte führen Sie diesen Zweig zusammen“ hören wird. Hier liegt also das Problem. Wenn Sie 6 Programmierer haben, die zusammenarbeiten, haben Sie 6 Zweige, die mit diesem Hauptzweig verflochten sind.

Up Das Bild ist ein Flussdiagramm der Operation git merge. Der Merge-Befehl behält die historische Zeit aller Commits bei. Die Codeeinreichungen jedes Einzelnen sind unterschiedlich. Obwohl diese Zeiten für das Programm selbst keine Bedeutung haben. Die ursprüngliche Absicht des Befehls merge besteht jedoch darin, zu verhindern, dass diese Zeiten geändert werden. Als Ergebnis wird eine Netzwerkverlaufsstruktur basierend auf der Zusammenführungszeit gebildet. Jeder Zweig behält weiterhin seine eigenen Codedatensätze und nur der Zusammenführungsverlauf wird im Hauptzweig beibehalten. Unterzweige können jederzeit gelöscht werden. Nachdem das Untermolekül gelöscht wurde, ist der Datensatz, den Sie sehen können, die Verschmelzung eines bestimmten Zweigs mit einem bestimmten Zweig. Diese historische Beschreibung ist grundsätzlich bedeutungslos.

Und git rebase wird auf Chinesisch als „rebase“ übersetzt, und diese Basis bezieht sich auf die Grundlinie. Wie ist dieser Benchmark zu verstehen? Werfen wir einen Blick auf das Bild unten. 🎜🎜 🎜🎜 Sie können sehen, dass sich der Basiszweig des Feature-Zweigs nach der Neubasierung geändert hat und zum neuesten Master geworden ist. Dies wird als „Rebasing“ bezeichnet. 🎜🎜Auf den beiden Bildern oben ist deutlich zu erkennen, dass der größte Unterschied zwischen diesen beiden Arten des Zusammenführens von Zweigen darin besteht, dass der zusammengeführte Zweig die Betriebsdatensätze der beiden Zweige behält, die als Kreuz im Git-Commit-Protokoll angezeigt werden Baum gespeichert. Der Zweig nach dem Rebase basiert auf dem neuesten Master-Zweig, sodass es keine Abzweigungen gibt und vom Anfang bis zum Ende eine klare, gerade Linie entsteht. 🎜

🎜Die detaillierte Verwendung von git rebase und git merge geht über den Rahmen dieses Artikels hinaus. Weitere Informationen finden Sie im Internet. 🎜

🎜Während des Rebase-Prozesses müssen wir normalerweise Commit-Änderungen vornehmen, und dies bietet uns auch die Möglichkeit, Git-Datensätze zu organisieren. 🎜

Halten Sie die neuesten Datensätze sauber🎜🎜Angenommen, wir haben ein Lager und ich habe in diesem Lager 4 Commits ausgeführt, und zwar über den Befehl git reflog Einreichungsdatensatz unten. 🎜🎜🎜🎜Wenn wir wollen Die Commits von Commit-3, Commit-2 und Commit-1 werden zu einem Commit zusammengeführt (vorausgesetzt, dass einige POM-Dateien in einem bestimmten Commit geändert wurden). Wir können den folgenden Befehl 🎜

git rebase -i d2b9b78

🎜-i bedeutet <code>--interactive, HEAD~3 bezieht sich auf die letzten drei Commits. 🎜🎜Natürlich können wir auch direkt die ID des letzten Commits angeben🎜, den wir behalten möchten. Im obigen Beispiel ist es die ID von Commit-0, also können wir sie auch als 🎜

git rebase -i xxx
git push -f
git pull

🎜 schreiben. Wir werden die folgende Schnittstelle wie folgt eingeben: 🎜

这个界面是一个Vim界面，我们可以在这个界面中查看、编辑变更记录。有关Vim的操作，可以看我之前写的文章和录制的视频《和Vim的初次见面》

在看前三行之前，我们先来看一下第5行的命令加深一下我们对git rebase的认识。

翻译过来就是，将d2b9b78..0e65e22这几个分支变基到d2b9b78这个分支，也就是将Commit-3/2/1/0这几次变更合并到Commit-0上。

回到前面三行，这三行表示的是我们需要操作的三个 Commit，每行最前面的是对该 Commit 操作的 Command。而每个命令指的是什么，命令行里都已经详细的告诉我们了。

• pick：使用该commit
• squash：使用该 Commit，但会被合并到前一个 Commit 当中
• fixup：就像 squash 那样，但会抛弃这个 Commit 的 Commit message

因此我们可以直接改成下面这样

这里使用fixup，而不是squash的主要原因是squash会让你再输入一遍commit的log，图省事的话，可以无脑选择fixup模式。

然后执行:wq退出vim编辑器，我们可以看到控制台已经输出Successful了。

这个时候我们再来看下log 记录，执行git log --oneline

于是最近三次的提交记录就被合并成一条提交记录了。

保持中间某些记录整洁

那如果不是最后的几个commit合并，而是中间连续的几个Commit记录，可以用上述方法整理合并吗？答案是可以的，只不过需要注意一下。

我们重新创建一个新的仓库

如果这次我们想将"third commit"和"second commit"合并为一个提交，其实和上面的方式一样，我们只需执行git rebase -i HEAD~3，然后将中间的提交改成fixup/squash模式即可，如下图所示：

之所以是HEAD~3，是因为我们要做的变更是基于first commit做的，因此我们也可以写成git rebase -i a1f3929

我们来看下更改完的commit log，如下图所示：

是不是就干掉了third commit了。

三行代码让git提交记录保持整洁

上面我们都是在本地的git仓库中进行的commit记录整理，但是在实际的开发过程中，我们基本上都是写完就直接push到远程仓库了，那应该如何让远程的开发分支也保持记录的整洁呢？

第一种做法是在push代码前就做在本地整理好自己的代码，但是这种做法并不适用于那种本地无法部署，需要部署到远程环境才能调试的场景。

这时我们只需要执行git push -f命令，将自己的修改同步到远程分支即可。

-f是force强制的意思，之所以要强制推送是因为本地分支的变更和远程分支出现了分歧，需要用本地的变更覆盖远程的。

而远程分支更新后，如果其他人也在这条分支上更改的话，还需要执行一个git pull命令来同步远程分支。

这里我们来总结下让git提交记录保持整洁的三行代码。

git rebase -i xxx
git push -f
git pull

❗️❗️❗️Tips：由于rebase和push -f是有些危险的操作，因此只建议在自己的分支上执行哦。

推荐学习：《Git视频教程》

Das obige ist der detaillierte Inhalt vonMachen Sie Ihren Git-Commit-Verlauf mit drei Codezeilen sauber. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!