GitHub登録 | Linuxエンジニアの備忘Log

GitHubの開発フローを学ぼう！：コンフリクトが起きたときの解消手順と考え方

前回の記事では、GitHub を使ったチーム開発の中で、
コンフリクト（conflict）がなぜ起こるのか を整理しました。

今回はその続きとして、
「実際にコンフリクトが起きたとき、どう解消していけばいいか」 にフォーカスしていきます。
合わせて、「コンフリクト＝悪」ではなく、調整のサインとして捉える考え方も整理してみましょう。

Contents

前回の記事では、GitHub を使った基本的な開発フローとして、
「main からブランチを切る → 作業 → プルリクを作成 → main へマージ」
という一連の流れを整理しました。

この流れに慣れてくると、次のステップとしてほぼ確実に出会うのが
コンフリクト（conflict） です。
プルリク画面で見かける 「This branch has conflicts that must be resolved」 というメッセージですね。

今回はあえて前編・後編に分けて、まず前編では次のような内容を扱います。

Contents

GitHubでプルリクエストをマージするときに出てくる、「Squash and merge」というボタン。

なんとなく押しているけれど、普通の「Merge」と何が違うのか？
「とりあえず Squash にしておけば良いと聞いたけど、本当に大丈夫？」
とモヤモヤしている方も多いのではないでしょうか。

この記事では、GitHubのマージ方法のひとつであるSquash and mergeについて、

をコンパクトに整理していきます。

Contents

前回の記事では、GitHubのブランチとプルリクエストの基本的な仕組みについて解説しました。

今回はその続きとして、プルリクエストを使ったレビューの進め方や、マージ方法の違い・よくあるトラブルとその回避方法を、より実務寄りの視点で整理していきます。

GitHubでチーム開発をしていると、

といった疑問や戸惑いがよく出てきます。

この記事では、僕が実際の現場で使っている運用イメージをベースに、小〜中規模チームでも無理なく回せるプルリク運用をイメージできるように解説していきます。

Contents

GitHubでチーム開発をしているとよく聞く「ブランチ」や「プルリクエスト」。

なんとなく使っているけれど、本当の意味や仕組みはよくわからない…という方も多いのではないでしょうか。

この記事では、GitHubの開発フローにおける「ブランチ」と「プルリクエスト」の仕組みや使い方を、初心者にもわかりやすく丁寧に解説していきます。

Contents