同時に作業するとどうなる？ コンフリクトと作業の整理

同時の作業と変更の重なり

第7記事で、作業場所を分けるブランチを学びました。第8記事では、プルリクエスト（PR）で変更を提案し、マージで取り込む流れを見ました。では、複数の作業が同じサイトを変更したら、どうなるでしょう。

別々に直した変更をまとめる

たとえば、元の見出しが「AIの学習」だったとします。作業Aでは「AIとGitHubの学習」に、作業Bでは「AIを楽しく学ぼう」に直しました。どちらも同じ元の見出しから出発した、別々の変更です。

先にAをmainに取り込んだ後、Bもmainへ取り込もうとすると、同じ部分について違う変更が重なります。Gitが完成形を判断できない場合、コンフリクト（衝突）として、どの内容を残すか確認が必要になります。

同じファイルなら必ず衝突する？

同じファイルに触れたからといって、必ず衝突するわけではありません。離れた部分の変更などは、Gitが自動でまとめられる場合もあります。逆に、同じ箇所の変更や、一方が削除したファイルを他方が変更した場合などには、判断が必要になることがあります。

自動でまとめられた場合も、内容として正しいとは限りません。たとえば見出しと本文を別々に直して、言葉の意味が食い違うこともあります。衝突の表示がないことと、完成した内容が正しいことは別なので、取り込み後の確認が大切です。

「同時」は作業の時刻だけではない

ここでいう「同時」は、同じ瞬間に操作した場合だけではありません。古い共通の状態から分かれた変更が、それぞれ進んだ後で合流するときにも起こります。ひとりがChatGPTに複数の作業を依頼した場合も同じです。

別々の作業場所は、互いの作業をすぐ上書きせず進める助けになります。ただし、分けた時点から片方が進めば、もう片方にはその新しい変更がまだ入っていないことがあります。取り込み前には、それぞれがどこから分かれ、何を変更したかを確認します。

例として、Aはタイトル、Bはページ下の案内文を変更した場合を考えてみましょう。Gitが両方をまとめられることがありますが、タイトルを「初心者向け」にしたのに案内文が上級者向けのままなら、読者にはちぐはぐです。動作だけでなく、文章のつながりも見直します。

なるほど！ まずは何が起きているか、ひとつずつ確かめればいいんだね。

コンフリクトは何を知らせる？

コンフリクトは「Gitが変更を安全に自動でまとめられず、判断を求めている」という知らせです。衝突の表示だけで、作業が消えたと決めつける必要はありません。まず、どこで止まり、何が残っているかを確認しましょう。

2つの変更を比べる

先ほどの例では、main側には「AIとGitHubの学習」、作業B側には「AIを楽しく学ぼう」があります。表示された両方を見て、依頼の目的を確かめます。ChatGPTには「それぞれの変更の目的と、重なった部分を説明して」と頼めます。

見出しなら、たとえば「AIとGitHubを楽しく学ぼう」と両方の意図を反映する案も考えられます。ただし、組み合わせれば常に正解というわけではありません。文章の意味や依頼者の意図を確認し、必要ならどちらかを採用します。

どちらか一方だけとは限らない

片方を残す・両方を生かす・別の形に直すという選択肢があります。自動で正解が決まるわけではないため、ChatGPTが提案した完成形も、自分の意図と合っているか確認しましょう。

別の人や別の会話で進めた作業なら、変更した理由がまだ分からないこともあります。不要だと判断して消す前に、誰のどの作業なのか、取り込む予定があるかを確かめるのが安心です。

画面上の表示に慌てない

ツールや画面によっては `<<<<<<<`、`=======`、`>>>>>>>` のような記号で衝突箇所が示されます。記号を暗記したり、意味を知らず削除したりする必要はありません。ChatGPTに両側の内容と最終案を説明してもらいましょう。

コンフリクトは、どちらかの作業者が失敗したという意味でもありません。別々には正しい変更でも、重なった部分を合わせるには意図の確認が必要になることがあります。問題を報告してもらったら、まずは内容を見るための合図だと受け止めましょう。

衝突したときの確認から解決まで

コンフリクトが起きたときは、慌てて最初からやり直すより、今の状態を確かめることから始めます。実際の操作は環境や作業手順によって異なるため、まずは状況をChatGPTに説明してもらいましょう。

① どこで止まったか確認

「どのリポジトリ・ブランチで、何をしようとして止まった？」「衝突しているファイルは？」「完了済みと未完了は？」と聞きます。マージ中なのか、別の操作中なのかも大切です。推測だけで同じ操作を繰り返しません。

② 両方の変更を読む

次に、それぞれの変更内容と目的を比べます。「取り込み先と作業側の変更を初心者向けに見せて。どちらが何のための変更？」と尋ねれば、残す内容を考えやすくなります。分からない意図は勝手に決めず、必要に応じて確認します。

③ 意図を残して調整する

内容が決まったら、意図した形に調整し、使用している手順に沿って解決を完了します。例えば見出しを一つにまとめる場合でも、他の文章や画像まで消さないか、差分を確認することが大切です。

④ 解消後に確認する

調整後は差分や画面を見て、両方の必要な変更が残っているか確かめます。必要なテストも行い、失敗・未実施は分けて報告してもらいます。衝突表示が消えただけでは、内容の確認まで終わったとは限りません。

最後に、変更をどこに保存したか、マージは完了したか、公開は行ったかをそれぞれ確認します。解決に成功しても、自動的に本番公開まで終わったとは限りません。公開される条件はサイトごとに異なります。

報告の例は「作業ブランチをmainに取り込もうとしたところ、見出しのファイルで衝突しました。まだマージは完了していません」です。この報告なら、止まった工程と未完了の操作が分かります。保存や公開の状態が書かれていなければ追加で聞いてみます。

ほかの作業を守りながら整理する

複数の作業を並行するときに大切なのは、コンフリクトだけでなく、どの変更を今回まとめるかを確認することです。衝突がなくても、関係のない変更を一緒に取り込む可能性があります。

作業ごとの保存先を確かめる

たとえば記事Aの文章、記事Bの図解、メニューの修正を別々に進めていたとします。それぞれのブランチと作業状況、保存済みかどうか、関連するPRがあるかを整理します。名前だけで中身を決めず、変更内容を確認します。

ChatGPTには「作業中の変更とブランチを一覧にして、未保存や未確認があれば教えて」と頼めます。別の作業環境にしかない変更など、今の環境から見えないものもあるため、一覧が何を確認した結果なのかも尋ねましょう。

取り込む範囲を決める

今回は記事Aだけをmainに反映したいなら、記事Aに必要な変更を特定し、提案される差分に記事Bやメニューの作業が意図せず混ざっていないか確かめます。実際のまとめ方は、そのサイトの運用に従います。

コツエイゴでも、作業の保存とmainへの反映、本番公開は別の段階として扱います。作業ブランチに保存されていることだけで公開済みとは言えません。また、自動公開の設定があるサイトではmainへの反映が公開のきっかけになる場合があります。

整理と削除は別の判断

古そうなブランチや途中の変更を見つけても、すぐ削除せず、目的・保存先・関連する作業を確認しましょう。「今回は触らず残して」と伝えることもできます。次の記事では、保存・main反映・本番公開の違いをさらに整理します。

反対に、全部をまとめたい場合も「全部」の中身を一覧で確認します。別のタイミングに公開したい変更が入っていれば、まとめる対象を調整できます。何を残すかは、技術的にマージできるかだけでなく、今回の目的で決めます。

もし状況が分からなくなったら「現在の状態を読むだけで確認し、変更や削除はまだしないで」と依頼できます。確認後、必要な作業と影響の説明を受けてから、どこまで進めるか伝えましょう。