今まで、"pull request" を作る際は、編集していたものをそのまま push していたのですが、いったん "git pull --rebase" を実行してから PR を作るように心がけようと思いました。
コマンド
"git pull" とは
リモートの更新をローカルに持ってくる以下のコマンドと同じことです。
git fetch + git merge
"git pull --rebase" とは
今いるブランチに別のブランチの情報を反映させるコマンドです。
git fetch + git rebase
補足
"git pull --rebase" なしで PR 作成
開発が進むと master と develop が以下のように更新されていきます。
このまま push すると conflict が起きやすくなってしまいます。
develop g-h-i
/
master a-b-c-d-e-f
"git pull --rebase" ありで PR 作成
差分が少ないので conflict が起きづらいです。
develop g-h-i
/
master a-b-c-d-e-f
そもそも"git pull --rebase”とは
"git pull --rebase” は fetch、merge、rebase、pull の理解が必要でした。
| git fetch | リモート環境の最新情報をローカル環境に反映するコマンド |
| git merge | 現在いるブランチの内容を他のブランチや master などに反映させるコマンド |
| git rebase | merge と同じで今いるブランチに別のブランチの情報を反映させるコマンド |
| git pull | "git merge" と "git fetch" を同時に行うコマンド |
"--rebase" オプションをつけて pull したほうがマージコミットが作られないため余計な履歴が残らないというメリットがあります。
自分ルール
特に取り決めがない場合は、プルリクエストを出す直前に一旦 "git pull --rebase" し最新のブランチを反映させてから push する開発スタイルにしようと思いました。
- PR 作成前に "git pull --rebase" を行い push する
- PR 作成後は修正しても "git pull --rebase" したものは push しない(reviewers の人が大変だから)
おまけ(はてなブログが504エラー)
そういえば、本日ブログを更新しようとしたら、以下のような画面が表示され 504 エラーが出てびっくりしました。
すぐに解消してよかったです。
