チーム開発でのGitHubの流れ

Git GitHub

先月から、フィヨルドブートキャンプでチーム開発に入らせてもらった。

これまでの課題も GitHub 上の自分のリポジトリに PR を作ってレビューしてもらっていたので、GitHub には慣れているつもりだったが、最初は戸惑うところがあったのでメモしておく。

チームによって方針が異なるので、ここに書くのは一例でしかなく、こうしなければいけないというものではない。

流れ

最初だけ必要な作業

  1. 自分の GitHub アカウントをコラボレーターに追加してもらう
  2. リモートリポジトリをローカル（自分のマシン）に clone する
  3. README を見てセットアップする

Issue ごとに繰り返す作業の流れ

  1. かんばんで、自分が作業する Issue を「作業中」に移動させる
  2. ローカルリポジトリのmasterブランチから開発用のブランチ（例: some-feature）を切る
    • $ git checkout -b some-feature
  3. some-featureブランチで作業してコミット
  4. 作業終了
  5. プル
    • $ git pull origin master
    • masterブランチを最新状態に
  6. リベース
    • some-featureブランチで、$ git rebase master
    • some-featureブランチの根元が、最新のmasterの先端になる
  7. リモートリポジトリにプッシュ
    • $ git push origin some-feature
  8. PR（プルリクエスト）作成
    • 作業前に Draft として PR を作成してもいい
  9. CI が通ったことを確認してから、レビュー依頼
  10. （修正作業など）
  11. 動作確認後、Issue を close する

備考

  • レビューやデザインを依頼するなどして「待ち」になるまで、他の Issue の作業を始めてはいけない
  • 今開発しているリポジトリはまだmainではなくmasterブランチを使っているのでそのまま書いている
  • 5〜6はpull --rebaseでまとめられる（プル・リベースについてはこちらの記事）

フォースプッシュは結構使う

Git を1からやり直す（リベース編） で、「一度プッシュしたコミットはリベースしない！」と書いたが、実際の開発ではしょっちゅうリベースしている。

作業途中でコードを見てもらいたいときや特に理由がなくても、作業完了前にプッシュすることはよくある。レビューを依頼するときには最新のmasterブランチを取り込んでおく必要があるため、上の手順の5以降をやることになる。

最初のプッシュをした後にmasterブランチが更新されていると、リベースかマージをする必要がある（どちらをやるかはチームにより異なる）。今のチームではリベースすることになっているため、同じコミットでもコミットのハッシュが変わり、プッシュできなくなる。

そこで、以下のコマンドでフォースプッシュ（強制プッシュ）する。

$ git push -f origin some-feature

フィヨルドブートキャンプの開発では、一つのブランチを複数人で触ることはないので特に問題は起こらない。

自分が作業するブランチを他の人も触る可能性がある場合は、--force-with-lease オプションを使うと、誰かがプッシュしている場合に強制プッシュできなくなるので安心。--force-with-leaseを-fのエイリアスにしてもよさそう。

（参考）現場で使える Ruby on Rails 5速習実践ガイド（9-1）