🐱

【Git・Github】~ レビューを待ちながら別作業 ~

に公開
GitHub
初心者
チーム開発
tech

はじめに

個人開発でGit・GitHubを利用してきましたが、チーム開発、特に長期インターンだからこそ出会う、「これどうする？」みたいな場面があったので、場面を想定しながら、改めてGit・GitHubの使い方を考えてみます！

レビューを待ちながら他の作業をする

  • PRを出したけどレビューを待つ必要がある（PR Draftで一旦確認して欲しい）
  • PRの別作業を待っている間に進めたい
  • コミット履歴は綺麗に保ちたい（不要なコミットは避けたい）

基本開発スタイル

PRブランチからローカル開発用のブランチを切って開発を進める。
うまくいったらfast-forward-mergeでPRブランチに綺麗にmerge、微妙ならブランチを捨てる。

fast-forward マージについて

ブランチが分岐せず直線的に進んでいる時のみ使用できる。
特徴：マージコミットが作られない（履歴が綺麗）

例）
feat/AがPRブランチであり、localDevブランチで作業をしてうまくいったら、feat/Aブランチにfast-forward-mergeすることでPRブランチ（feat/A）のコミット履歴を綺麗に保つ

fast-forward-merge前
前

fast-forward-merge後
後

レビュー依頼

キリのいいところまで進んだので一旦みてもらいたい！かつ作業は止めたくない！
PRブランチをDraftでレビュー依頼しつつ、localDevで作業を進める。
レビュー依頼

出戻りがない場合

PRブランチに作業用ブランチ（localDev）をfast-forward-mergeする！
fast-forward-merge

出戻りがある場合

レビュー修正 --> 作業の続きという順番になる。
この場合、レビュー修正用のブランチを切りそこでレビュー修正作業をする。

レビュー修正作業

レビューOK
レビュー用のブランチをPR用のブランチにfast-forward-mergeする。
レビューマージ

この時、localDevブランチをPRブランチにmergeしようとすると、mergeコミット（不要なコミット）が作られる。

作業中のブランチ（localDev）をrebaseして、PRブランチの最新の状態から生やすようにする。

rebase について

一言で言うと：
作業ブランチの付け根を、元のブランチの特定のコミットに付け替えること。
これにより履歴を書き換えて、最新のブランチから作業しているブランチを切った状態にできる。

rebase

これで通常の開発フローに戻る！

最後に

ハッカソン・長期インターンなどチーム開発だからこそ直面できる場面での対処を考えました。Git・GitHubを上手に操って開発に集中できるように精進します！

最後まで読んでいただきありがとうございました！

今回の調べごと・深掘りしたいこと

  • fast-forward-mergeってなに？普通のmergeと何が違うの？
  • rebaseって何？

Discussion