Rendre votre historique de commit git propre avec trois lignes de code

Cet article vous apporte des connaissances pertinentes sur git. Il explique principalement comment garder vos enregistrements git propres. Les amis intéressés peuvent jeter un œil ci-dessous. J'espère que cela sera utile à tout le monde.

Avant-propos

L'auteur a récemment dirigé le travail de migration d'architecture d'un projet. En raison du lourd fardeau historique du projet de migration et du grand nombre de collaborateurs, il est inévitable d'effectuer plusieurs branches et plusieurs engagements au cours. le processus de migration. Au fil du temps, l'enregistrement de soumission git est en désordre, je viens de prendre un historique graphique de soumission git pour vous donner une idée.

Diverses branches se battent comme des folles dans un harem, tout comme des concubines rivalisant pour les faveurs dans le harem. La raison pour laquelle cette situation se produit est principalement due à l'abus de la commande git merge et au manque de compréhension ultérieure. Les programmeurs travaillant aujourd'hui dans les grandes usines acceptent souvent les changements.Une fois qu'ils ne sont pas soigneusement examinés au début, un grand nombre de journaux de validation dénués de sens apparaissent inévitablement, couplés à la promotion du concept « agile » et à l'itération rapide des changements en ligne des produits. Après être devenus les indicateurs principaux, ces journaux de validation dénués de sens ont été « traités la prochaine fois » et sont devenus chaotiques au fil du temps.

Lorsque nous examinons certains référentiels open source, nous constaterons que leurs enregistrements de commit sont très soignés. En fait, ce n'est pas parce que les programmeurs de la communauté sont plus compétents, mais parce qu'ils n'ont pas de bâtons KPI pour les fouetter. et ils passent du temps avant de soumettre le code. Organisez votre propre journal de validation. Et c'est le protagoniste de cet article : "Git Rebase".

git rebase et git merge

git rebase, traduit par "rebase" en chinois, est généralement utilisé pour la fusion de branches. Puisque la fusion de branches est mentionnée, la commande git merge doit être indispensable. 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

Je crois que chaque programmeur novice entendra les mots « xxx, veuillez fusionner cette branche » lorsqu'il entrera pour la première fois sur le lieu de travail. Voici donc le problème. Si vous avez 6 programmeurs travaillant ensemble, vous aurez 6 branches de programmeurs. Si vous utilisez la fusion, votre arbre d'historique de code aura six branches entrelacées avec cette branche principale.

En haut L'image est un organigramme de l'opération git merge. La commande Merge conservera l'heure historique de toutes les validations. Les soumissions de code de chacun sont variées. Bien que ces horaires ne signifient rien pour le programme lui-même. Mais l’intention initiale de la commande de fusion est d’empêcher que ces heures ne soient modifiées. En conséquence, une structure d'historique de réseau basée sur l'heure de fusion est formée. Chaque branche continuera à conserver ses propres enregistrements de code et seul l'historique des fusions sera conservé sur la branche principale. Les sous-branches peuvent être supprimées à tout moment. Une fois la sous-molécule supprimée, l'enregistrement que vous pouvez voir est la fusion d'une certaine branche dans une certaine branche. Ce récit historique n’a fondamentalement aucun sens.

Et git rebase est traduit par "rebase" en chinois, et cette base fait référence à la ligne de base. Comment comprendre ce benchmark ? Jetons un coup d'œil à l'image ci-dessous. 🎜🎜 🎜🎜 us Vous pouvez voir que la branche de base de la branche de fonctionnalités a changé après le rebasage et est devenue le dernier maître. C'est ce qu'on appelle le "rebasage". 🎜🎜Il ressort clairement des deux images ci-dessus que la plus grande différence entre ces deux méthodes de fusion de branches est que la branche fusionnée conservera les enregistrements d'opération des deux branches, qui seront affichés sous forme de croix dans le journal de validation git. arbre enregistré dans le formulaire. La branche après le rebase sera basée sur la dernière branche principale, il n'y aura donc pas de fourches et ce sera une ligne droite et nette du début à la fin. 🎜

🎜L'utilisation détaillée de git rebase et git merge dépasse la portée de cet article. Pour plus de détails, vous pouvez vous référer à d'autres informations sur Internet. 🎜

🎜Pendant le processus de rebase, nous devons généralement apporter des modifications de validation, ce qui nous offre également la possibilité d'organiser les enregistrements git. 🎜

Gardez les derniers enregistrements propres🎜🎜Supposons que nous ayons un entrepôt et que j'ai exécuté 4 commits dans cet entrepôt, via la commande git reflog Afficher le dossier de soumission ci-dessous. 🎜🎜🎜🎜Si nous voulons Les commits de Commit-3, Commit-2 et Commit-1 sont fusionnés en un seul commit (en supposant que certains fichiers pom ont été modifiés dans un certain commit Nous pouvons directement exécuter la commande suivante 🎜

git rebase -i d2b9b78

🎜-i signifie est <code>--interactive, HEAD~3 fait référence aux trois derniers commits. 🎜🎜Bien sûr, nous pouvons également spécifier directement l'ID du dernier Commit🎜 que nous souhaitons conserver. Dans l'exemple ci-dessus, il s'agit de l'ID du Commit-0, nous pouvons donc également l'écrire comme 🎜

git rebase -i xxx
git push -f
git pull

🎜Après avoir exécuté cette commande, nous entrerons ainsi dans l'interface suivante : 🎜

这个界面是一个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视频教程》

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!