git-rebase を多用した開発の流れ
git-rebase を使った開発の流れが固まってきたので、ブログで晒してみます。
この呟きから日数が経っている理由は察してください。
とりあえず、マグナ・ゼロは2週して、黄金魔剣士は2回撃破しました。
まず初めに
- git-rebase に不慣れな方は真似しない方がいいです
- reflog でgit-rebase の失敗を戻せない人も真似しない方がいいです
- 無名ブランチに移動しても泣かないように
開発の流れ
前提
- git-pull は使わず、git-fetch を使う
- 追跡ブランチでは作業をしない(必ずトピックブランチを作る)
- bashにgitのブランチ名を表示しておく(rebaseでコンフリクト起きるのが見えないと危険なので)
0. 作業準備
プロジェクトのディレクトリに移動する。
$ cd ~/Projects/FizzBuzz
作業前にリモートリポジトリの変更を取得する。
$ git fetch
その後、gitk を起動しておく
$ gitk --all &
1. 作業着手
作業するために、トピックブランチを作ります。
トピックブランチは必ずリモートのブランチから作ります。
$ git checkout -b feature/foo origin/develop
2. 作業中
作業は必ずトピックブランチで行います。
トピックブランチのコミットログは下書きなので、綺麗に書いても、適当に書いても、git-now(tmp コミットのための独自サブコマンド git-now)でも構いません。
2.1. 作業中にリモートの変更を取得する
作業中にリモートの変更が気になった場合、git-fetchでリモートの変更を取得する。
git-pull と違い、マージが発生しないため、気軽にfetchできる。
2.2. 今の作業に必要な変更がpushされていた場合
git-fetch 後にログを確認し、変更が必要であればgit-rebase で変更を取り込みます。
$ git fetch $ git log --oneline -n 10 origin/develop $ git rebase origin/develop
3. 作業終了
トピックブランチでの作業が終わったら、コミットを整理する。
整理するポイントは2点です。
- プロジェクトの他メンバとコミットの粒度を合わせる
- コミットログの文章を整形する(変更の意図が分かるか、チケット番号があるか、誤字・脱字チェック...etc)
まずは、作業中の他の人の変更内容を取得します。
$ git fetch
その後、コミットを整理します。
$ git rebase -i origin/develop
4. 作業終了の確認
rebase で失敗していないか、gitk で確認します。
4.1. git-rebase で失敗した場合
もし意図したコミットログになっていない場合、reflog(もしくはgitk)とgit-resetを使って戻します。
5. 変更内容を追跡ブランチに反映する
「3. 作業終了」のgit-rebase が終わると、今いるブランチはトピックブランチになるはずです。
ここでdevelopブランチにトピックブランチの内容を反映させます。
$ git rebase HEAD develop
6. 追跡ブランチに反映した内容の確認
gitk で確認する。
基本的に、git-rebase の後はgitk で意図したログになっているか確認する。
7. 作業内容をpushする
「5. 変更内容を追跡ブランチに反映する」が終わると、今いるブランチはdevelopになるはずです。
ここで、git-push をします。
$ git push
まとめ
メリット
- git-fetch だと気軽にリモートの変更を取得できる
- トピックブランチのコミットログを必ず書き換えるので、作業中はログに拘らなくて良い
- git-rebase を多用するとgit-checkout が減って、タイプ数が減る
- git rebase -i, git rebase HEAD, git pushのテンポが良い
デメリット
- git-rebase はWindowsだと遅い
- git-rebase に不慣れだと手順ミスった時に泣きたくなる