3 行のコードで Git コミット履歴をクリーンにする

この記事では、git に関する関連知識をお届けします。主に、git レコードをクリーンに保つ方法について説明します。興味のある友人は以下を参照してください。すべての人に役立つことを願っています。

まえがき

著者は最近、プロジェクトのアーキテクチャ移行作業を主導しています。移行プロジェクトの歴史的負担が大きく、多くの人員の協力が必要なため、移行はプロセスには必然的に複数のブランチが含まれます。複数のコミットの場合、時間が経つにつれて、Git 送信レコードは混沌としたものになります。誰にでも感じてもらえるように、Git 送信履歴をグラフィカルに見てみましょう。

さまざまなブランチがハーレムで狂ったように争い、側室が好意を争うかのようです。この状況の理由は主に git merge コマンドの乱用と、その後の理解コストの。現在、大規模な工場で働くプログラマは頻繁に変更を受け入れますが、最初に変更を慎重に考慮しないと、必然的に意味のないコミット ログが大量に作成されます。「アジャイル」コンセプトの推進と相まって、オンラインでの製品の変更は急速にイテレーションされています。これらの無意味なコミットログは、コア指標になってから「次回処理」され、時間の経過とともに混乱していきました。

いくつかのオープン ソース ウェアハウスを見ると、コミット レコードが非常に整然としていることがわかります。実際、これはコミュニティのプログラマーの方が有能だからではなく、彼らに鞭打ちの能力がないからです。コードを送信するときに KPI がスティックされるので、その前にコミット ログを整理することに時間を費やします。そしてこれがこの記事の主役「Git Rebase」です。

git rebase と git merge

git rebase は中国語で「リベース」と訳され、通常はブランチのマージに使用されます。ブランチのマージについて言及されているため、git merge コマンドは必須である必要があります。

初心者プログラマーは誰でも、最初に職場に入ったときに「xxx、このブランチをマージしてください」という言葉を聞くことになると思います。ここで問題が発生します。6 人のプログラマが一緒に作業している場合、6 つのプログラマのブランチが存在します。マージを使用すると、コード履歴ツリーには、このメイン ブランチと絡み合った 6 つのブランチが存在します。

上の図は、 git merge 操作のフロー図です。Merge コマンドは、すべてのコミットの履歴時間を保持します。全員が提出したコードはさまざまです。ただし、これらの時間はプログラム自体にとっては何の意味もありません。しかし、マージ コマンドの本来の目的は、これらの時間を変更しないようにすることです。その結果、マージ時間に基づいたネットワーク履歴構造が形成されます。各ブランチは引き続き独自のコード レコードを保持し、マージ履歴のみがメイン ブランチに保持されます。サブブランチはいつでも削除できます。サブ分子が削除された後、特定のブランチが特定のブランチにマージされたレコードが表示されます。この歴史的記述は基本的に無意味です。

そして、git rebase は中国語で「リベース」と訳され、このベースはベースラインを指します。このベンチマークをどのように理解すればよいでしょうか?下の画像を見てみましょう。

feature ブランチのベース ブランチがリベース後に変更され、最新のマスターになっていることがわかります。これを「リベース」と呼びます。

上の 2 つの図から、ブランチをマージするこれら 2 つの方法の最大の違いは、マージされたブランチが 2 つのブランチの操作記録 (git コミット ログ ツリーにある) を保持することであることが明確にわかります。クロス形式で保存されます。リベース後のブランチは最新の master ブランチをベースにするため、フォークがなく最初から最後まできれいな直線になります。

git rebase と git merge の詳細な使用法については、この記事の範囲を超えています。詳細については、インターネット上の他の情報を参照してください。 。

リベース プロセス中は、通常、コミットの変更を行う必要があります。これにより、git レコードを整理するオプションも提供されます。

最近のレコードを整理整頓する

ウェアハウスがあり、このウェアハウスで 4 つのコミットを実行したと仮定します。次のように git reflog コマンドを使用してコミット レコードを表示します。 。

Commit-3、Commit-2、Commit-1 のコミットを 1 つのコミットにマージする場合 (特定のコミットでいくつかの pom ファイルが変更されたと仮定します)次のコマンドを直接実行できます。

git rebase -i HEAD~3

-i は --interactive を指します。 HEAD~3 は最後の 3 つを指しますコミットします。

もちろん、保持したい最新のコミットのIDを直接指定することもできますが、上記の例ではCommit-0のIDなので#のように書くこともできます。 ##

git rebase -i d2b9b78

このコマンドを実行すると、次のインターフェイスに入ります:

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

以上が3 行のコードで Git コミット履歴をクリーンにするの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。