git-rebase を多用した開発の流れ

Git

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 に不慣れだと手順ミスった時に泣きたくなる

まとめ（140文字）

エイリアスを設定していると、こんな手順です。

エイリアス コマンド
ft fetch
co checkout
rb rebase
rbh rebase HEAD
ps push