はじめに
世間ではGitHubがMicrosoftに買収されることが決定されたことでなおさらGitLabも注目を浴びていますね。1
今日はそんなGitLabが従来はStarter以上2じゃないと使えなかったSquash&Merge機能が11.0からCommunity Editionで使えるようになるので、一足先にTrialを使ってどんなものなのか確認してみようと思います。
いつ頃リリースされるの？
こちらによると、6/22の11.0のリリースで適用されるようです。
Squash&Mergeとはどんな機能なのか
公式の解説はこちら
平たく言うと、いくつかのCommitを１つのCommitとしてMergeすることができる機能になります。
どんなふうに使うの？
仮にサーバの設定ファイルが管理されているリポジトリで
新しく通信先が増えたため/etc/hostsにhoge.comにつながるような設定追加をしたいとします。
このファイルをpushしたGitフローが以下とします。
- hoge.comを追記してWIPでMRを発行
- レビュー中に実はapi.hoge.comもhostsに設定しないと駄目だと指摘される
- api.hoge.comをhostsに追記
- WIPを解除してMerge
肝なのは、本来はhostsファイルの修正は1つのコミットに纏められるのに、
WIPのレビューで指摘されて２回コミットしてしまっている点です。
これは、レビューする人や後にgit logを見る人はコミットの粒度が細かくなりすぎて見づらくなってしまいます。
(※会社やチームによってはgitのコミット粒度は様々なのでこれが絶対的に悪いわけではありません)
こういうシチュエーション時に、MergeRequest時に１つのコミットに見せることが出来るのがSquash&Merge機能というものになります。
実際に試してみる
では、Issueを切るところから実際に上記フローで試してみます。
- Issueを切る
- Issueからブランチを作成
- 赤枠を押してWIPなMergeRequestを作成
Mergeボタンが押せないWIPなMergeRequestが作成される
- レビューコメントを追記してみる
- 指摘の通り再度コミットしてMergeRequestに２つのコミットがされたことを確認
- MergeRequestの「Squash commits」にチェックを入れる
- Mergeした後にMerge元の1-fix-hostsブランチを確認してみる
- Merge先のmasterブランチではコミットが集約されていることを確認
Merge先のMergeCommitから纏める前の詳細コミットを見たい場合
場合によっては、Merge先からこの１つに集約されたコミットはどういう経緯でコミットされたのか確認したい場合があります。
例えば、今回のhostsファイルは実は最初はhoge.comのIPを1.1.1.100で設定したけど、うまくいかなくて1.1.1.1に修正した場合は、纏まった後のコミットからは試行錯誤の経緯が読み取ることができません。
コミットログにどこまで意味を持たせるかは会社やチームによって色々ありますが、
一つの考え方としてはコミットログからも過去の経緯がわかるようにしたいといった場合に有効です。
- masterブランチのMergeCommitを確認し、「See merge request !X」を押す
- 元のブランチのMergeRequestが確認できるので、ここのCommitsから確認する
最後に
簡単にではありますが、GitLabの今後追加される一機能についてレポートしてみました。
GitLabでは現在は有償機能であっても、GitLabのコアに入れたほうが良いよねっていう場合は今回のようにIssueで意見を募集して取り込まれることが多々あるようです。
今回は言及していませんが、GitLabはCommunityEditionであってもIssue管理、ブランチ戦略、CI/CDの機能などなど本当にたくさんの機能に溢れています。
ぜひGitだけの機能ではなく、GitLabの全機能を使い倒すつもりで色々試されてみてはいかがでしょうか😊