😃

レビュー待ちが長いと、PR(プルリクエスト)運用が破綻しやすい理由（開発者視点の一般論）

に公開
Docker
Git
プロジェクト管理
開発プロセス
idea

この記事で言いたいこと

「feature ブランチを切って PR を出す」運用は、開発者にとって魅力的です。
ところが レビュー／本流へのマージが遅い状態が常態化すると、現場では次のような “やりにくさ” が積み重なります。

  • 次タスクが、前PRを 前提（依存） にしてしまう
  • 依存がある以上、「動くまとまり」単位でしか提出できない状況が増える
  • それでも「1機能ずつPR」を形式だけで続けようとすると、作業が余計に複雑化する

★★★★★★
はじめから、PRの単位を、動くまとまり　にしようという現場ルールにすることも
1つの解決策にはなります

ただし、これだけでは、完全な解決策ではありません

共通処理部のローカル一時コピペ問題があるからです。
一時的に、発生するのは、やむを得ないとは思いますが、
レビュー／マージが遅すぎて、そういう一時対応の量が増えるのは、
望ましい状況ではありません
★★★★★★

この話を、特定プロジェクトの事情や具体的な機能名に依存しない形で整理します。

前提：この話は「レビューが遅い」ことがトリガー

ここでの話は、次の前提を置きます。

  • PRを小さく切る方針自体は良い（レビューが読みやすい）
  • しかし、レビュー／マージが詰まると、小さく切るほど次が詰まる
  • そして現実には「小さく切るためだけにスタブ／ドライバを作る」「依存を切るための追加実装を入れる」ほど、スケジュールに余裕がないことが多い

つまり “理想のPR粒度” と “現実のレビュー速度” が噛み合っていないと破綻します。

まず押さえるべきポイント：PRは「レビューのための単位」、進捗報告は別物

PRは、差分のレビューを円滑にし、議論や記録を残すのに向いた仕組みです。
一方で「顧客への進捗報告」を PR のマージ状況に寄せると、次のズレが起きやすくなります。

  • 「報告の都合」で PR を無理に分割しようとしても、
    実現不能だったり、ごり押しでやろうとすると余計な煩雑作業が増える。
  • レビューが遅いほど、「前PRを待てない」ため、次の作業が前PRにぶら下がる
  • 結果として、PRが “進捗報告の道具” に引っ張られて、開発者の作業が煩雑になる

Git／PRはソースコード管理とレビューのための道具であって、進捗報告の道具ではありません。
進捗報告を思い通りにしたいなら、別の軸で、別の方法で考えるほうが衝突が少なくなります。

レビューが遅いと現場で起きること（一般論）

1) 「前PRの実装に依存する次タスク」が普通に起きる

よくあるのは、次タスクが「前PRで作った共通処理」や「前PRの機能実装」が
存在するのが、前提で、それをベースにした実装が必要になるケースです。
これは割り当てや設計の都合で避けられないことが多いです。

まず、“理想の流れ” はこうです。

  • 前PRがレビューされて本流にマージ
  • 本流をpullして最新化
  • その最新本流から次のfeatureを切って開発開始

しかしレビューが遅いと、この理想の流れを待つのが現実的ではなくなります。

2) レビュー待ちを避けるために「不本意な選択」を迫られる

レビューが遅い状態で次タスクを進めると、現場ではだいたい次のいずれかになります。

  • 既存PRのブランチに追加pushして、差分を積み増す
    （動く状態を維持するには最短。ただしPRが肥大化しやすい）

  • 本流に未マージの共通差分を、動作確認のためだけにローカルへ一時取り込みし、次タスクのコミットには混ぜない
    （後で競合を増やさないための防衛策。ただし “覚えておくこと” が増える）

    ここで増える “覚えておくこと” とは、たとえば次のような 運用上のメモ です。

    まず前提として、ここで言う「一時コピペ」が必要になるのは、だいたい次の状況です。

    • あるPRで、将来の複数タスクから使い回す予定の**共通処理（ヘルパー／共通コンポーネント等）**を先に用意し、push している
    • 次のタスクでもその共通処理を使って実装したい（= その共通処理が無いと実装・動作確認がしづらい）
    • しかし、その共通処理を含むPRのレビューが遅く、本流にまだマージされていない
    • その結果、次タスクを先行して進めるために、やむを得ず 「既存PRで作ったが、まだ、本流未マージが、されていない 共通処理コード」をローカルへ一時的にコピペして動作確認する状況が発生する

    この前提があるとき、増える “覚えておくこと” は、たとえば次のような 運用上のメモ です。

    • 「既存PRで作ったが本流未マージの共通処理コード」を、どこへ・どの状態で一時コピペしたか
      例：どのPR（どのブランチ／どのコミット相当）の共通処理を、どのローカル環境／作業ツリーへ持ち込んだか。
      次タスクでも同じ共通処理を使い回し始めると、取り込み元を追跡できないと整合（結合レベルの齟齬）が崩れる。

    • 一時コピペは「動作確認のためだけ」で、次タスクのコミット／push には入れない
      そのため意図的に「ローカルにはあるが、Git上（履歴）には存在しない」状態が発生する。
      → どこまでが “動作確認用の一時コピペ” で、どこからが “次タスクとして提出すべき差分” か を自分で切り分けて管理する必要がある。

    • 共通処理側に手直しが必要になったときの手順とオーバーヘッドを覚えておく必要がある
      結合レベルの齟齬を防ぐため、共通処理に変更が必要になった場合は、基本的に次の流れになる。

      1. 共通処理のPR（未だ、本流へマージされてない）のブランチ上で修正する
      2. 共通処理を変更後に動作確認し、再pushし、レビューワーへ連絡する
      3. そのうえで、先行タスク側のローカルに一時コピペしている共通処理へも、手作業で最新化反映してから、先行タスクの開発を再開する
        さらに、共通処理の作者が自分ではなく別メンバーなら、**意思疎通（修正方針、取り込みタイミング、レビュー順）**のコストも発生する。

    • （補足）この種の手間は本流へマージされた後でも発生し得るが、未マージ状態だと “ローカル一時コピペ分への手作業反映” が追加で乗る
      つまり、レビュー／マージが遅いほど「追加の手作業」が増えやすい。

    これらは、作業を止めないための現実的な防衛策ですが、レビューが遅いほど「覚えておくこと」が積み上がり、運用コストが上がります。

  • 複数の開発環境を回して、レビュー待ちと先行開発を並行する
    （現実的な回避策。複数環境構築してることが前提）
    このノウハウは、
    複数環境を使って、レビュー待ちがある前提で、作業を止めずに回すためのノウハウ（レビュー待ちの回避、環境ローテーション、など）
    を参照のこと。

どれを選んでも、「レビューが速い前提」の運用より作業は重くなります。

3) 依存がある以上、「動くまとまり」で出す方向に寄る

機能Aと機能Bが結合していて、片方だけだと動かない（動作確認もできない）状況はよくあります。

★★★★★★★★★★★★★★★★★★★
この時、スタブ／ドライバなどを用意してまで「1機能ずつ」で動かすほどのスケジュールに余裕がないなら、PRは結局、下記のようになります。
★★★★★★★★★★★★★★★★★★★

  • 動くまとまり（依存を含む単位）で提出せざるを得ない
  • ★ 結果としてレビューが遅い既存の前プルリクへの追加プッシュする形でないとエンジニアは対応できない(スケジュール余裕がない)
  • ★ レビューが遅いほど、その “まとまり” はさらに大きくなりがち

★★★★★★
はじめから、PRの単位を、動くまとまり　にしようという現場ルールにすることも
1つの解決策にはなります

ただし、これだけでは、完全な解決策ではありません

共通処理部のローカル一時コピペ問題があるからです。
一時的に、発生するのは、やむを得ないとは思いますが、
レビュー／マージが遅すぎて、そういう一時対応の量が増えるのは、
望ましい状況ではありません
★★★★★★

例：既存PRのfeatureブランチ名を feature/00100 とする

以降、説明を簡潔にするため、既に出しているPRのブランチを feature/00100 と呼びます（ブランチ名は例です）。

  • feature/00100 のレビューが遅い
  • 次タスクは feature/00100 の実装に依存する
    （その実装がないと次タスクの実装ができない、動かせない／動作確認できない）

この条件だと、「PRを細かく切りたい」という理想とは別に、現場は次の現実に引っ張られます。

  • feature/00100 の上に次の変更が積まれ始める
  • 「本流から切り直す」タイミングが遅れるほど、差分の整理が難しくなる
  • その結果、作業者は 追加push か 一時取り込み のような運用をせざるを得ない

結論：レビュー速度を考えない「理想のPR運用」は、現場コストを確実に増やす

  • PRを細かく切る運用は、レビューが回る速度が前提
  • レビュー／マージが遅いと、「前PRに依存する次作業」が発生しやすく、現場は 動くまとまり でしか出せなくなる
  • 進捗報告をPRマージ状況に寄せるほど、実装と衝突しやすい
    → ★ 報告は別の軸や、別の方法で考えるほうが衝突が少ない
    ★ つまり、プロジェクトマネージャーがしたい顧客への進捗報告の仕方としては、gitのマージ状況とは別枠で考えてもらう必要があり
    ★ 別のやり方で、別のツールなどで考えていただきたいということになります。
    ★ そもそも、
    ★ Git／PRはソースコード管理とレビューのための道具であって、
    ★ 進捗報告の道具ではありません。
    ★ 進捗報告を思い通りにしたいなら、
    ★ 別の軸で、別の方法で考えるほうが衝突が少なくなります。
    ★ PRマージ状況を進捗報告として利用するのは、結構だが、
    ★ その進捗報告の都合に、ひっぱられて、エンジニアの作業が煩雑になるのは、避けてほしい。
    ★ PRマージ状況の履歴が各々の機能ごと、1機能ずつマージされてたほうが顧客が見やすいから
    ★ それにあわせこめと言われても、前タスクのレビュー／マージが詰まってて
    ★ 依存関係がある同じ動くまとまりの次の機能の実装／動作確認が先に完了しておれば、
    ★ エンジニアは、前プルリクのfeatureブランチに追加プッシュし、
    ★ 結果として、2機能を合算した形のプルリクにせざるを得ません。

補足）
Git／PRはソースコード管理とレビューのための道具
であって、進捗報告の道具ではありません。
とよく似た話で、
テストは誤りを発見するために行うためのものであり、
品質の説明をするに行うものではありません。
元の実装がよければ、ケース数に対してバグは少なく
そうでなければ、その逆ですので、そんなものは最終的な説明になりません。
ステップ数を分母にして、それらの数値がどうだったとか、しょーもない話だと思います。
テスト手法や残す結果などは、
エンジニアが誤りを発見するに、プロジェクトの状況により時間効率のよい方式を選ぶの筋であり
テストの結果として生み出されたものを検収時の条件として利用するあまり、
それにひっぱられるのは、筋が悪いと、個人的には思ってます。
直近の時間効率を落としてでも、今後の回帰テストのために自動テストの仕組みを導入しようかなど
仕組み的なところで、議論するのはよろしいと思いますが、
納品時の検収条件として、テスト結果の画像を残せ
見やすいテスト結果になるような資料整理をしろ
とか、そのような話が、しょーもないと思ってます。
進捗を重視したいならば、手を動かすエンジニア側の都合に何事も合わせる方向で考えるべきと
個人的に思ってます。
そして、そうなるように、調整するのが、プロジェクトマネージャーのはずなのに、
それができないことの吸収をエンジニアに要求するのは、筋違いと、思います。
テストに関する、この話題は、
今回の話題とは関係ないため、これ以上は、割愛します。

複数環境構築のノウハウの件

レビュー待ちがある前提で、作業を止めずに回すための「複数環境構築」をして回す
考え方があります。
ノウハウは、以下の記事にまとめています。

開発環境が「Docker Compose」、「Dev Container」を利用時の
「複数環境構築」のノウハウは、下記の記事にまとめてあります。

複数環境を使って、レビュー待ちがある前提で、作業を止めずに回すためのノウハウ（レビュー待ちの回避、環境ローテーション、など）

★★★★★★
ここのノウハウは、複数環境構築してることが前提です
開発環境が「Docker Compose」、「Dev Container」を利用時のケースでは、
複数環境構築時にコツがあります
それをしないと、docker compose buildの時点で前環境との重複でエラーになって
構築できません。その件は、
複数環境構築のノウハウの件
を参照のこと。
★★★★★★

プルリクを出した時に、レビュー待ちなる。
次のタスクは、レビュー中のプルリクでの実装をベースにして、追加実装が必要なケースもある。

本来は、レビューが承認され、マージされた後、本流のdevelopなどをプルして
最新のdevelopなどから分岐されたfeatureで次の開発をすべきである。

しかし、レビューが承認され、マージされるまで、待つのが時間の無駄である。

レビューが承認され、マージされる前に、
次のタスクの開発作業をはじめたいが、レビュー中のプルリクのソースコードもベースとしてある環境で
次のタスクを仕掛かりたい。なぜなら、レビュー中のプルリクの分の実装もベースにして、次のタスクは追加実装したかったりするからだ。
( 作業効率を考えて、同じエンジニアに同じテーマの開発をシリーズもので任せたりすれば、そのエンジニアにとっての次タスクに開発すべきものは、つい、さっき、プルリクを出したソースコードの実装をベースにした追加開発になることは多いだろう )

そんな時に、もし、複数の環境があれば、安定したやり方で、うまくやれる。
人によっては、gitのスタッシュをうまく活用すれば、１つの環境でもやりくりできる　という考え方もあるようだ。

ただ、複数環境があって、それを活用するのも、やり方として、よろしいのではないか。
その必要性は、人によりますので、強制はしませんが、考え方として参考までに知っておいてもよろしいのではないか

ここから具体的に書くと、

「環境1」で、最新のdevelopから分岐したfeature111にて、プルリクを出してレビュー待ちになったとします。
そのプルリクのレビューが承認され、developにマージされる前に、
次のタスクの開発作業をしたいが、feature111で実装したソースコードも、前提としてある状況で
次のタスクの開発作業をしたい。

そこで、
別の環境の「環境2」で、
git fetch --all
した後に
git checkout -t origin/feature111
または
git switch -t origin/feature111

補足:
上記のコマンドの意味がわからない人は、
https://zenn.dev/tazzae999jp/articles/07bed12c3ae6c0#gitの「リモート追跡ブランチをローカルブランチ化」方法
の
gitの「リモート追跡ブランチをローカルブランチ化」方法
の項目の説明を参照のこと

補足:
上記をする前に、先に、developブランチにいる状況で、
git pull origin develop
をしておいて、developが最新化された状況を作っておいたほうがよいです。
この「環境2」で、後ほど
feature111からdevelopへ
ブランチの切り替えをすることが想定されます。
ブランチを切替時に、切替元と、切替先の差異が少ない方がgit上のトラブルが起きにくいと
感じておりなるべく、差異を減らすため、一旦、先に、developブランチにいる状況で、
git pull origin develop
での最新化をする。（もしくは、最新化されているかの確認をする)
をした後に、
git fetch --all
した後
git checkout -t origin/feature111
または
git switch -t origin/feature111
したほうが、後ほどのトラブルの確率を下げれると思ってます。

をするとプルリクを出してる前タスクの「feature111」の状況を
リモートから直接、落としてきて、「feature111」のソースコードがある状況で、
次のタスクの開発作業を「環境2」で、はじめられます
この段階で「環境2」では現在のブランチが「feature111」になっています。

★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★
★　追記 2026/02/11
★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★
★ こうすることのメリットが、もう１つあります。
★ 「環境1」でプルリクを作成した「feature111」を直接
★ 「環境2」に落としてきて、次のタスク開発をはじめようとした場合のことです。
★ 「 あれ？ 前プルリクの「feature111」のコードが動かない。」となった場合、
★ 「環境1」で「feature111」プルリク作成時にプッシュ漏れがあったということです。
★ それに、自分で気が付くことができます。
★ なので「環境2」へ作業環境を切り替えて、次タスクの開発しはじめるほうが、
★ 「プッシュ」漏れに、気が付くトリガーも自動的に働くので、一石二鳥なのです。
★ 人間の注意力だけじゃなく、作業方法のシステムとして、自動的にミスがなくなる方式を
★ 入れ込んで、手をうごかすことで、スピードと精度を両立させるという思考です。
★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★

でも、この「環境2」での次タスクを開発している際中で実装した分は、
一旦は、コミットやプッシュはしないでおくべきだと思います。
なぜなら、最終的に次のタスクは、前の分のプルリクが承認されてマージされたdevelopから派生させたfeatureでプルリクを出す必要があるので、この状況でコミットやプッシュするのはまずいです

ですから、この「環境2」で次のタスクでの開発作業での分は、一旦は、
未ステージング領域で置きっぱなしにしておきながら、次のタスクの開発作業を進めておきます。
その状況で、実装、デバッグ、動作確認など、次のタスクの開発作業をすすめておきます。

しばらくすると、前のfeature111のプルリクについて、レビューが実施され、
レビューの指摘事項の対応をしてくれと、レビューワーから連絡が来ることがあると思います

そしたら、そのレビューの指摘事項対応を、先に、優先的にやるべきだと思います

しかし、「環境2」のほうでは、次のタスクの開発のためソースコードを変更しまくってるので
そこで、feature111のレビューの指摘事項対応はやりにくい状況ではある。

「環境1」のほうはfeature111についてのプルリクを出した時点の状況のままになっている
ですから「環境1」のほうで、feature111についてレビューの指摘事項対応をして、
再プッシュまでやればよろしいと思います。
そこまで「環境1」でやりきったら、また、feature111について、再レビュー待ちになると思います

そしたら、また、「環境2」に戻ってきて、次のタスクの開発作業の続きをやれば、よろしいのですが
今、feature111でレビューの指摘事項対応でプッシュした分の実装も取り込んだうえで、
次のタスクの開発作業の続きがしたいわけですよね。

「環境2」では、現在のブランチがfeature111で、
次のタスクの開発分は、未ステージング領域に置きっぱなしの状況です。
そのまま、
git pull origin feature111
をすればよいわけです。そしたら、先ほどのレビューの指摘事項対応の分も取り込めます
ただ、この「git pull origin feature111」は怒られてできない場合があります。
「git pull origin feature111」によって落ちてこようとするファイルと同じファイルが
未ステージング領域にある場合です。

その場合は、該当のファイルの相対パス ( gitコマンドはローカルのgitのリポジトリのルートで打ち込むのが基本だが、そこからの相対パス )
が示されたエラーメッセージがでて、「git pull origin feature111」自体が失敗します。
完全に失敗しますので中途半端な状態にはなりません。プルは失敗したら、プルの行為を行う前状態が保持されます。

そうなった場合の対応ですが、未ステージング領域などは、gitスタッシュなどをつかって一回退避して
未ステージング領域のファイルがなくなった状況で、プルを成功させ、
gitスタッシュからの復元時の自動マージ機能で復元すればよいよ。という考え方があるようですが。

私個人は、怒られた該当のものだけ、相対パスが示されてますので
cp コマンドのコピー元の第１引数にそのまま、その相対パスを指定し、別のフォルダを第２引数にして
怒られた分だけバックアップをとってしまいます。

そして、その後、
git checkout HEAD -- <<該当の相対パス>>
で、ローカルのHEADリビジョンに戻します

補足:
上記のコマンドの意味がわからない人は、
https://zenn.dev/tazzae999jp/articles/07bed12c3ae6c0#ローカル編集中の内容を元に戻す方法(-git現在のブランチの最新リビジョン（head）に戻す-)
の
ローカル編集中の内容を元に戻す方法( git現在のブランチの最新リビジョン（HEAD）に戻す )
の項目の説明を参照のこと

それを怒られたファイルの分だけやります。
そしたら、未ステージング領域から、その怒られた分だけ、消えます　（　ローカルのHEADリビジョンに戻ります )

その後、再度、
git pull origin feature111
をすれば、今度は、成功します。

その後、バックアップとった分と、WinMergeなどのソースコードの差分を見るソフトウェアで比較して
必要な個所（つまり、次のタスクの開発で実装している必要な分 )を手作業で戻してます

ここまでやれば、feature111でのレビューの指摘事項対応で対応した分の実装も取り込めて
それも、ベースにしたうえでの、次のタスクの開発作業の続きが行える状況になりましたので、

引き続き「環境2」での次のタスクの開発作業が続行できます。

そのうちに、他の人のプルリクが承認されてdevelopにマージされたとします。
そしたら、それも、取り込んだうえで、次のタスクの開発作業の続きができたらしたいわけですよね

★★★★★★★★★
自分のタスクに無関係ではないかと考えるかもしれませんが、私は、そうは思いません。
本来は、人の開発分も取り込んだうえで、なるべく、その時の最新状態のコードベースに
自分がいま開発してる分で、動作が問題ないかをすべきかとは思うです。
それをやっておけば、少なくても、自分が開発した分は、結合レベルでのトラブルがないと
品質保証できます。また、人の分を取り込んだ結果、動かなくなった場合
誰かが何かを間違ってるということです。自分かもしれません。
だから、それも含めて、早い段階で調査できます。そして、
その件を早い段階で連絡や、相談ができます。
・他の人の実装を取り込んで最新化したら結合レベルでバグってしまうような
実装を自分のタスクでやってしまってるケースがあれば、軌道修正できます。
人の分を取り込んで最新化することをさぼってしまったがゆえに、それを知らずに、
本当は、最新のコードベースで結合レベルでバグってるのにも関わらず、
できましたと、次のタスクの分をプルリクをだしてしまうなどの愚行を防ぐことができます。
・その軌道修正は、他の人が間違ってるのか、自分がおかしいのか、どちらも間違っていないが
単にインターフェースについて、意思疎通不足の可能性もあります
問題は、様々かもしれませんが、実際に、うまく結合して動かないということが
早期に発見できる可能性が高まるのですから、常に最新化したコードベースで自分の
開発をしてるほうがよいのではないかと考えています。
せっかく動作確認や、テストをするのであれば、常に最新化したコードベースに対して
自分の開発分がある状況でするほうがよいと思うのです。
この思想をもって、
「それも、取り込んだうえで、次のタスクの開発作業の続きができたらしたいわけですよね」
と、上記では書いています。
★★★★★★★★★

slackなどで、プルリクがマージされたので、取り込んでねって連絡があればよいですが、
その連絡を忘れていたり、こなかったり。

３つ目の「環境3」があればよいわけです。基本的に、developなどで頻繁に、
いつも、「環境3」でプルしておれば、特に、落ちてくるものがなければ、「Already up to date.」と表示されるわけです。
私は、しょっちゅう、プルしてます。たいてい「Already up to date.」でますが、気にせず、しょっちゅうプルしてます

誰かの変更を検知して、なるべく早く取り込みたいからです。
作業が一段落したタイミングで手癖のように頻繁にしてます。

普段、しょっちゅう、プルして、「Already up to date.」を出してる状況で、
実際に、「環境3」で何か落ちてくれば
追加で誰かのプルリクが承認されてマージされたことを気づくことができます。

ですので、私は、環境は最低３つあればよいのではないかと考えています

１つ目は、プルリクのレビューの指摘事項対応の環境
２つ目は、次のタスクの開発作業を行う環境
３つ目は、予備になにかあったときの環境で、他の人のプルリクが承認されたことを気づくトリガーにも使えます

なにか、git上でトラブルが起きてハマってぬけられなくなったとき、予備環境があれば、
そこに、
git fetch --all
した後
git checkout -t origin/featureXXX
または
git switch -t origin/featureXXX
で、リモートの分を復元した上で、
要る分の実装をそこに、Winmergeなどを使って、追加するなどで復元できます。

それが、できれば、トラブって、ぬけられなくなった環境は、最悪は、捨てればよいと思うです。
また、環境を作ればよいです。生きてる環境が最低、３つあればよく
開発の初期のできるだけ早い時期に、環境をもう１個作るために最低限なにをやればいいかのノウハウを確立させて
そのノウハウだけ、書いた資料を作り、それ、見ながら、素早く環境を１個増やせる状況を作ればよろしいと思います。

この３つの環境をローテーションして使えばよろしいのではないか、と考えています
場合によっては、すごく、めんどうで複雑なタスクを沢山こなす諸事情により、もっと環境増やした方が良いケースもありますが
そういうことがなければ、最低３つ環境あれば、よろしいのではないかと考えてます

話を元に戻しますが、

他の人のプルリクが承認されマージされたら、どうすればよいかですが、
現在の自分のプルリクのレビューの指摘事項対応の環境に割り当たってる
「環境1」でマージ作業すればよいかと思ってます

「環境1」は今、feature111についてのレビューの指摘事項対応の環境になってますが
ここで、
git checkout develop
または
git switch develop
で、developブランチに移動します

git pull origin develop
で、他の人の分の承認されたプルリク分を取り込んで最新化します。

再び、
git checkout feature111
または
git switch feature111
でfeature111にブランチを切り替えて、
git merge --no-edit develop
で、
developからfeature111にマージします。

補足:
マージの時に、「--no-edit」をつけてる件は、
私がUbuntu(WSL2)環境で開発しているからです。
そうでない人は、「--no-edit」はなしでもよく、気にしなくてもいいと思います
Ubuntu(WSL2)環境に興味があり、なぜ、ここで、「--no-edit」をつけているかの
話題に興味があれば、
https://zenn.dev/tazzae999jp/articles/07bed12c3ae6c0#git-mergeでエディタを起動しないようにする設定の話
の
git mergeでエディタを起動しないようにする設定の話
の項目の説明を参照のこと
エディタ起動抑止の設定が3種類あり、私は、3種類の対策を、すべてやってます。
その関係上で、私は、マージするときは、常に「--no-edit」指定することを
癖づけることにしてます。
そのため、「--no-edit」があるだけです。
「　そうでない人は、「--no-edit」はなしでもよく、気にしなくてもいいと思います　」
と上記で書きましたが、「--no-edit」をつけてれば、どんな環境でも
マージの時に、エディタ起動抑止できます。その環境の設定の問題です
Ubuntu(WSL2)以外であれば、デフォルトの設定が、「マージの時に、エディタ起動しない」
なのですから、「--no-edit」をつけなくてもマージの時にエディタ起動しない可能性が
高いだけです。でも、100%そうとは限らない。(環境の値がズレていたら限らない)
この点が気になるならば、上記の参照先を読んでいただければと思います。

もし、コンフリクトが起きたならば、その対応もして、コミットします。

git logでマージした分（および、コンフリクト対応したなら、その分のコミットも)
含まれた状況を確認して、

git push origin feature111
で、レビュー中のプルリクに自動反映すればよいです。

もし、コンフリクト対応があった場合は、レビュー対象の差分で表示される
ソースコードに変化あるかもなので、レビューワーに連絡したほうがと思います

その後、次のタスクを開発中の「環境2」で、
git pull origin feature111
をやれば、他の人の承認されたプルリク分も取り込んだうえで、
次のタスクの開発作業が続行できる状況になると思います

それから、もし、次のタスクの開発が、動作確認まで終わってるのにも関わらず、
前のタスクの自分のfeature111について、まだ、レビューが終わってない
( 指摘事項対応は迅速に自分が行って連絡しているのにも関わらず )

そんな状況は、あってはならないと思ってます
それは、はっきり言って、レビューワーが仕事してないです。（　遅すぎます　）
諸事情はあるかもしれませんが、それは、もっと早くしてくださいと、依頼を出してもよいのではないかと思ってます。

★　どうしても、レビュー／マージができないというのであれば、
★　前タスクのプルリクへの追加プッシュでいいですよね
★　と、話するしかありません。
★　この話題のエトセトラは、当記事の冒頭で、散々書いてる話です
★　１つのプルリクエストが肥大化しますが、レビュー／マージが遅いなら、
★　やむをえません

ですので、そこは、自分のほうが「レビューの指摘事項対応を迅速に適切に対応してる状況」
だと言える状況では、
レビューワーをつついても、全然問題ないとおもっております。

そのような事がない前提で、当記事の説明は続行します。

話を元に戻しますが、

しばらくすると、当初の自分のfeature111のプルリクが承認されて、developにマージされたとします。

そしたら、やるべきことは、
次の開発作業をしている「環境2」で
git checkout develop
または
git switch develop
した後、
git pull origin develop
だと思います

次のタスクの開発作業分は、未ステージング領域に置きっぱなしであるため
ブランチの切り替えをしても、プルしても、そのままついてきます。

そのままついてくるのですが

ブランチの切り替えや、プルのときに、怒られて失敗することがあります

理由は、未ステージング領域に置きっぱなしのファイルでありまして、
その場合は、怒られたメッセージで該当のファイルだけ、相対パスが表示されます

別にすべての未ステージング領域に置きっぱなしファイルが怒られるわけではないです。
経験上、それらが仮に、10ファイルあっても、怒られるのは、せいぜい、１ファイルや、２ファイルだったりしますので、
その怒られたものだけを対応すればよいのです。

ここで、gitスタッシュを使って云々の考え方の人もいますが
自分は、その怒られた分だけ、バックアップをとって、それをHEADリビジョンに戻して
ブランチの切り替えや、プルを成功させてから、
バックアップからWinmergeなどで差分を見て、手動で要る分（次のタスクの開発で要る分の実装）を反映させてます。

git checkout develop
または
git switch develop
した後
git pull origin develop
まで、成功させて、そこに、次のタスクの開発の実装分が入ってる状況を作ります

つまり、自分の前タスクのfeature111の分や、他の人の分も含めた最新分を取り込んで、
かつ、次のタスクの開発作業分の実装も、入ってる状況を作って
なおかつ、次のタスクの開発作業、動作確認まで終わりました

ということになれば、

git checkout -b feature222
または
git switch -c feature222
で、最新のdevelopから派生させて、feature222を作ります。

ブランチは、今、作ったfeature222に移動した状況になります。
未ステージング領域に置きっぱなしである、次のタスクの開発分の実装も、そのままついてきます。

ですので、それらの未ステージング領域に置きっぱなしの次のタスクの開発分の実装について、
ステージングに、追加し、コミットしてプッシュして、feature222についてのプルリクを出せばよろしいかと思います。

そして、feature222のプルリクを出したら、レビュー待ちになってしまうので、
別の「環境3」などで、
git fetch --all
した後
git checkout -t origin/feature222
または
git switch -t origin/feature222
で、
リモートから直でfeature222をそのまま落としてきて、
さらに、その次のタスクの開発作業を「環境3」で続行すればよろしいかと思います

すると、
「環境2」がfeature222のレビュー指摘事項対応の環境
「環境3」が先行開発環境
「環境1」が予備環境。および、他の人のプルリクが承認されてマージされたことを発見するためのトリガー環境
などのようにローテーションされる形となります。

以後は、同様のことの繰り返しになります

複数作ってる環境でローテーションさせながら、レビュー待ちの時間なしで、次のタスク、次のタスクの
開発作業が行える状況となってます。

ここで、

自分のほうが「レビューの指摘事項対応を迅速に適切に対応してる状況」だと言える状況を作り
次のタスクが動作確認まで終わってるのにも関わらず、前の分のレビューが終わってないことについては、
あってはならないこととして、適切にレビューワーに仕事するようにつつきまわしておけば
レビュー待ちのために作業が止まることがまったくなく
矢継ぎ早に、どんどん、プルリクが出せます

★　どうしても、レビュー／マージができないというのであれば、
★　前タスクのプルリクへの追加プッシュでいいですよね
★　と、話するしかありません。
★　この話題のエトセトラは、当記事の冒頭で、散々書いてる話です
★　１つのプルリクエストが肥大化しますが、レビュー／マージが遅いなら、
★　やむをえません

前の分のプルリクが承認され、マージされる頃には、次タスクが大半終わってる状況になってたりするので、効率よくタスクをこなすことができると思います

次タスクの開発のためにソースコードを編集しまくってる状況では、
前タスクのレビューの指摘事項対応がしにくい問題も
複数環境あって、これまで説明したようにやれば、問題がなくなると思います

もちろん、人によっては、gitスタッシュなどをいい感じに使いこなして、やりくりすれば、１つの環境でも全然、いけるよって
思想の持ち主もいらっしゃるのかもしれませんが、複数環境でやってたほうが、わかりやすいし、作業内容自体が安定するんじゃないでしょうか

また、タスクの割り振りや、スケジューリングしている人間にも、ここでの作業イメージを、是非とも伝えておきたいとは感じております

要するに、「プルリクのレビュー依頼を出して、それが承認され、マージされたら」、タスク完了で、
そこではじめて、次のタスクを割り振ればよい

みたいに、思われると、結局、次の作業が割り振られるまでの間、無駄な待ち時間になってしまうわけです。
そりゃ、レビューがなされて、指摘事項があれば、その指摘事項対応できますけど
レビューがなされるまでの待ち時間、指摘事項対応後の、再レビューの待ち時間
がすべて、無駄な待ち時間になるわけです。

そうじゃなくて、プルリクをだしたときには、次のタスクの開発が、これまで、説明したような要領でできるわけですから、
プルリクをだしたときには、次のタスクが割り当たってなければ、ならないわけです。（無駄な待ち時間をゼロにしようとしたら）
ですので、あと、１日で、あと半日で、プルリクをだせそうですので、今のタスクをプルリクをだした後の次タスクの割り当てを考えといてくださいね

そして、プルリクをだす、少し前、もしくは、プルリクをだすやいなや、すぐ、次タスクが割り当たって
これまで、説明した要領で、次タスクの開発が開始される。

それ前提でのタスク割り振りで、考えといてね
ということを、タスクを割り当てする人間に説明するには、これまでの要領でのやり方を説明し、理解しておいてもらう必要がありますよね

ネット上で、自作のこのような記事があれば、この記事を使って、それを説明できるわけで、
今後、自分自身が、その説明をするための、ネタとしても使えるので、このような記事を書いてます。

このような説明するのがメンドイ話は、ネット上で誰でも見れる形で記事にして、それをネタにして、説明するのが効率的だと
思ってますので、それを実践するための、私個人の記事であります。

ですが、それが、他の人にも役立てば、なおよしだよね。とは、考えております。

どうせ、業務中の時間は拘束時間であり、そこでの無駄時間を減らしたい
進捗を進めておけば、プライベート時間を守れます。
つまりは、
進捗遅れでの残業や、休日対応などを防げくことができます。
また、進捗がよければ、どうしても外せないプライベートな用事での休暇も取りやすい。

プライベート時間を確保すること、侵害されないこと、に貢献できます。

説明するのが、メンドイ話でしたが、プライベート時間を守るためには必要だと思います。

WSL2 ( Ubuntu ) のgit環境の話

結論から言うと

  • VS CodeのGit機能
  • VS Codeの拡張機能のGitGraph
  • Ubuntuのgitコマンド
    を活用すればよろしいでしょう。

ただし、「Ubuntuのgitコマンド」は初期状態では認証系が弱いですので
下記に示す補強が必要です。

WSL2でsourcetreeの利用はオススメしない

sourcetreeなどのWindows版のアプリは、WSL2の領域へは、
\wsl.localhost\　からはじまるようなパスでしかアクセスできません。これだと、スピードが遅くなります
大規模プロジェクトで、sourcetreeでWSL2の領域を見に行くと、固まって動かなくなるという報告があるようです。

VS Codeは、変態的だから、WSL2環境でも遅くならない

VS Codeは、Remote Developmentの拡張機能を入れることで、WSL2のUbuntuに対してログインし、
直接、Linuxのパスを見に行きます。
これにより、VS CodeはWindows版のアプリでありながら、
はじめから、UbuntuにインストールされたLinuxアプリであるかのうような挙動を取ります

そのため、

  • VS CodeのGit機能
  • VS Codeの拡張機能のGitGraph
  • Ubuntuのgitコマンド
    これらが、遅くなることがありません。
    ( / からはじまるLinuxパスを直接見に行って動くからです )

ただし、「Ubuntuのgitコマンド」は初期状態では認証系が弱いですので
下記に示す補強が必要です。

「Ubuntuのgitコマンド」の認証系の補強の話題

まとめてるのは、このリンク先です。
https://zenn.dev/tazzae999jp/articles/9284b82d5807df#gcmの使えるようにしておく(「たつお」のオススメ)

補強のやり方は、下記のどれかになると思います。

  • Git for Windowsを先にインストールして、Git for WindowsのGCMを間借りして、認証を解決する形でhttpsにてアクセスする方法
  • Linux純正のGCMをUbuntuにインストールして、そのGCMで、認証を解決する形でhttpsにてアクセスする方法
  • sshkeygenで公開鍵、秘密鍵のペアを作成し、公開鍵を、GitHubなどに登録し、sshにてアクセスする方法

Git for WindowsのGCMを間借り
のやり方が一番お手軽ですが、この方式の場合、
https://zenn.dev/tazzae999jp/articles/a1ef5bf1d41e2e
のGitBash側のgitに刺激を与えることを、時々、やる必要がある環境もあります。
GitBucketの時に、これが必要なケースがありました。

パーミッションエラーを起こさないための環境設定

WSL2で「Docker Compose」環境のとき

Zenn [POSIX ACLでのフル権限化の再構築]
https://zenn.dev/tazzae999jp/articles/2c235cc6f0e84d
のノウハウにて、作業ユーザのUID=1000、GID=1000に対してフル権限を与えて
コンテナ側でrootで作業し、root所有のファイルや、フォルダが混ざっていた時でも
権限エラーを起こさず、作業できる配慮をしよう。
その場合でも、コンテナ内部のwebアプリは、www-dataなどがアプリの実行ユーザだったりするので
動作確認や、デバッグ、テストには影響ないはずのため、そこも、確認しておこう

WSL2で「Dev Container」環境のとき

Zenn [WSL2でdevcontainerで気が付いたこと]
の目次項目「devcontainerでは、VSコードでコンテナ内にログインしターミナル操作をするユーザはUID=1000、GID=1000のユーザとしておくのがお作法。」

https://zenn.dev/tazzae999jp/articles/b60d353fd9329d#devcontainerでは、vsコードでコンテナ内にログインしターミナル操作をするユーザはuid%3D1000、gid%3D1000のユーザとしておくのがお作法。

devcontainer.jsonにて、
ghcr.io/devcontainers/features/common-utils
のfeatureで、

Dockerfileでの構成にプラスαする形で、
UID=1000、GID=1000のユーザを作成し、
UID=1000、GID=1000のユーザで、VS Codeがログインする形にしておこう
( sudoコマンドがパスワードなしで使えるようになるため、システムインストール作業もできる )

こうすることで、コンテナ内での作業も、システム作業以外は、なるべく、
UID=1000、GID=1000で行われるため、権限問題がおきない ( そもそも、root所有のファイルや、フォルダが作られない )

★★★★★★★★★★★★★★★★★★★★★★★★★★
＜重要＞
★★★★★★★★★★★★★★★★★★★★★★★★★★
UID=1000、GID=1000にこだわる理由、ネイティブLinux環境や、WSL2でのUbuntuで
初期設定値のデフォルトでは、一番最初に作る作業ユーザは、
UID=1000、GID=1000で作られるのが一般的であるため、
上記の、URLでの参照先の記事の項目では、

			"username": "vscode",
			"userUid": 1000,
			"userGid": 1000

のように設定しておくことを紹介している。
このことが、理解できてないMacユーザがいたら、UID=1000、GID=1000にしとけ！！！
と、説明しておくべきだ。
Macの初期の作業ユーザは、UID=501とかそういうので、作られるみたいですが、
おまえら、どうせ、virtioFSのファイル共有でバインドマウントして
コンテナ側にログインするユーザがなんであろうが、結果として、それで、
コンテナ側に作成されたファイルや、フォルダの所有者がどのユーザになろうが、
バインドマウントした領域について、ホスト側でみたときに、
今、作業してるユーザの所有者に見えるから影響ないだろ、
それなら、ネイティブLinux環境や、WSL2でのUbuntuに配慮して
Microsoftが推奨してるお作法にしたがって、
UID=1000、GID=1000でコンテナにログインする設定にしておけ
そうしないと迷惑だろ！！
と、説明しておく必要がある。
★★★★★★★★★★★★★★★★★★★★★★★★★★

ターミナルから直でUID=1000, GID=1000へのログイン

上記でDevContainerで、VS CodeがUID=1000, GID=1000へログインする設定ができるけど
VS Codeのターミナルだと画面が小さい。
Ubuntuのターミナルで大きな画面で作業したいケースで、
UID=1000, GID=1000でコンテナにログインするには、
下記の内容をコピペした
login1000.sh　などの名前のシェルを作成しておく
chmod +x login1000.sh　をしておく

docker compose -p proj_dir exec --user 1000:1000 app bash -l

proj_dirのところを、直下にdocker-compose.ymlが置いてるフォルダ名
app のところを、docker-compose.ymlでのサービス名
を指定してください。

以後、
./login1000.sh
を実行するだけでよい。

WSL2のインストールや、Ubuntuの初期ユーザ作成は、Docker Desktopや、Rancher Desktopのインストールよりも、先にやること！！！　（これ重要）

  1. Ubuntuのディストリビューションを使えようにする過程で初期ユーザを作成する
  2. Docker Desktopや、Rancher Desktopのインストール

この 1.、2.の順番で、必ずやること！！！！

先に、Docker Desktopや、Rancher Desktopのインストールをやってしまうと
dockerを表す、GIDが1000でできて、
作業ユーザがUID=1000、GID=1001になってしまうことで、

DevContainerで、コンテナ側に、UID=1000、GID=1000でログインする設定にしても、
GIDの違いでの権限トラブルの可能性がでてきます。

そうなった場合は、一旦、Docker Desktopや、Rancher Desktopをアンインストールしてから
dockerを表すグループを消して
作業ユーザのgroupをGID=1000に戻して、
また、Docker Desktopや、Rancher Desktopをインストールなど

そういうメンドイ、環境設定のやり直し作業が発生することがある。

実際に、私は、そうなったチームメンバーのPCを操作して、

環境設定のやり直しをやったことがある。

必ず、トラブル回避のため

  1. Ubuntuのディストリビューションを使えようにする過程で初期ユーザを作成する
  2. Docker Desktopや、Rancher Desktopのインストール

この1.、2.の順序性で、環境構築することを死守したうえで！！！

Ubuntuのターミナルで、id コマンドを打ち込んで

今の作業ユーザが、UID=1000、GID=1000となってることを
環境構築の初期段階で、確認することが鉄則だから、心得ておくこと！！！

WSL2の初期設定関係

Zenn [WSL2の初期導入。再整理。(2025/11)]
https://zenn.dev/tazzae999jp/articles/9284b82d5807df
にまとめてます。

Discussion