はじめに
前に書いた、コードレビューを実施する際の流れの記事の中で、レビューをもらいやすい細かいプルリクの切り分け方のページを参照しました。大きな機能は一度トピックブランチに切り出して、更にそこから小さな派生ブランチを作成していくという運用です。そもそも小さくできないPull Requestでありがちな内容として
- 古いフレームワーク、ライブラリの置き換え
- GUIのデザインリニューアル
等があるんですが、この作業って、派生ブランチの名称を毎回変更できるような特徴って少なかったりするんですよね。どうしても「feature/xxx_version_up__part1」「feature/xxx_version_up__part2」みたいな単調な名称になります。また、
- そもそも、派生ブランチを都度作るのが面倒
- レビューなどで指摘部分があった時、後続の派生ブランチに差分を適応するのが面倒
だったりします。何度も派生ブランチ作るのが面倒なので、1つの派生ブランチをずっと使えないかなと思って考えたのが今回の運用になります。
想定するブランチ運用
基本、記事通りですが、今回の運用は派生ブランチ「feature/xxx_yyy」をずっと使い続けます。複数人で作業する場合は、派生ブランチが1人の開発者に付き1つあるみたいな感じですね。
Gitコマンド
今回は「development」「feature/version_up」「feature/version_up/developer_1」というブランチがある想定で進めていきます。ただ、「feature/version_up/developer_1」でしか作業しないので、上記のような開発ブランチと、トピックブランチがあるんだなー程度に思ってもらえば大丈夫です。
Pull Requestに過去のコミットをpush
開発はfeature/version_up/developer_1 で基本的な作業を行います。作業が一段落したらPull Requestを投げるため、リモートリポジトリにpushします。しかし、最新のブランチをpushすると大きくなりすぎるので過去のコミットをpushしたい時は、下記のコマンドを実行します。
$ git log
commit xxxxxxxxxxxxxxxxxxxx
Author: John Doe
Date: Tue Jul 2 18:30:00 2020 ＋0900
現在の作業
commit yyyyyyyyyyyyyyyyyyyy
Author: John Doe
Date: Tue Jul 2 18:20:00 2020 ＋0900
pushしたい作業
リビジョン番号は、commit の横にある文字列です。それを使って
$ git checkout [REVISION_ID]
$ git push origin [REVISION_ID]:[ORIGIN_BRANCH]
このコマンドで過去のコミットをリモートリポジトリにpushできます。今回のケースだとREVISION_IDは「yyyyyyyyyyyyyyyyyyyy」で、ORIGIN_BRANCHは「feature/version_up/developer_1」になります。
レビューで指摘された部分を修正
$ git log
$ git checkout [REVISION_ID]
pushしてあるコミットを選択します。選択した状態でファイルの修正を実施します。
$ git add [FILE_PATH]
$ git commit -m 'ミスタイプの修正'
その後、現在のリビジョン番号を確認し、pushします。
$ git log
commit zzzzzzzzzzzzzzzzzzzz
Author: John Doe
Date: Tue Jul 2 18:45:00 2020 ＋0900
ミスタイプの修正
commit yyyyyyyyyyyyyyyyyyyy
Author: John Doe
Date: Tue Jul 2 18:20:00 2020 ＋0900
pushしたい作業
$ git push origin [REVISION_ID]:[ORIGIN_BRANCH]
今回のケースだとREVISION_IDは「zzzzzzzzzzzzzzzzzzzz」で、ORIGIN_BRANCHは「feature/version_up/developer_1」になります。
修正したコミットの統合
修正を差し込んだら、その修正を現在のブランチにも適応する必要があります。
$ git rebase -p [REVISION_ID] [BRANCH]
このコマンドで修正した内容を、現在のブランチに適応できます。今回のケースだとREVISION_IDは「zzzzzzzzzzzzzzzzzzzz」で、BRANCHは「feature/version_up/developer_1」になります。
pオプションなしだと、過去のマージコミットが消えるので必ずpオプションつけてください。
参照：git rebase時にマージコミットを保持する
終わりに
当初想定していた運用を形にできましたが、ローカルとリモートブランチでどうしても差分が出てしまうのがデメリットですね。また実行しているコマンドがややトリッキーなので、慣れてないとミスしたときのリカバリが面倒な感じはします。