この記事では、git に関する関連知識をお届けします。主に、git レコードをクリーンに保つ方法について説明します。興味のある友人は以下を参照してください。すべての人に役立つことを願っています。
著者は最近、プロジェクトのアーキテクチャ移行作業を主導しています。移行プロジェクトの歴史的負担が大きく、多くの人員の協力が必要なため、移行はプロセスには必然的に複数のブランチが含まれます。複数のコミットの場合、時間が経つにつれて、Git 送信レコードは混沌としたものになります。誰にでも感じてもらえるように、Git 送信履歴をグラフィカルに見てみましょう。
さまざまなブランチがハーレムで狂ったように争い、側室が好意を争うかのようです。この状況の理由は主に git merge コマンドの乱用と、その後の理解コストの。現在、大規模な工場で働くプログラマは頻繁に変更を受け入れますが、最初に変更を慎重に考慮しないと、必然的に意味のないコミット ログが大量に作成されます。「アジャイル」コンセプトの推進と相まって、オンラインでの製品の変更は急速にイテレーションされています。これらの無意味なコミットログは、コア指標になってから「次回処理」され、時間の経過とともに混乱していきました。
いくつかのオープン ソース ウェアハウスを見ると、コミット レコードが非常に整然としていることがわかります。実際、これはコミュニティのプログラマーの方が有能だからではなく、彼らに鞭打ちの能力がないからです。コードを送信するときに KPI がスティックされるので、その前にコミット ログを整理することに時間を費やします。そしてこれがこの記事の主役「Git Rebase」です。
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
:使用该commitsquash
:使用该 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仓库中进行的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 サイトの他の関連記事を参照してください。