前回の記事では、GitHub を使った基本的な開発フローとして、
「main からブランチを切る → 作業 → プルリクを作成 → main へマージ」
という一連の流れを整理しました。
この流れに慣れてくると、次のステップとしてほぼ確実に出会うのが
コンフリクト（conflict） です。
プルリク画面で見かける 「This branch has conflicts that must be resolved」 というメッセージですね。
今回はあえて前編・後編に分けて、まず前編では次のような内容を扱います。
GitHubでプルリクエストをマージするときに出てくる、「Squash and merge」というボタン。
なんとなく押しているけれど、普通の「Merge」と何が違うのか？
「とりあえず Squash にしておけば良いと聞いたけど、本当に大丈夫？」
とモヤモヤしている方も多いのではないでしょうか。
この記事では、GitHubのマージ方法のひとつであるSquash and mergeについて、
をコンパクトに整理していきます。
Contents
前回の記事では、GitHubのブランチとプルリクエストの基本的な仕組みについて解説しました。
今回はその続きとして、プルリクエストを使ったレビューの進め方や、マージ方法の違い・よくあるトラブルとその回避方法を、より実務寄りの視点で整理していきます。
GitHubでチーム開発をしていると、
といった疑問や戸惑いがよく出てきます。
この記事では、僕が実際の現場で使っている運用イメージをベースに、小〜中規模チームでも無理なく回せるプルリク運用をイメージできるように解説していきます。
GitHubでチーム開発をしているとよく聞く「ブランチ」や「プルリクエスト」。
なんとなく使っているけれど、本当の意味や仕組みはよくわからない…という方も多いのではないでしょうか。
この記事では、GitHubの開発フローにおける「ブランチ」と「プルリクエスト」の仕組みや使い方を、初心者にもわかりやすく丁寧に解説していきます。
チーム開発やコード管理で「GitHub（ギットハブ）」という名前を聞いたことがある人も多いのではないでしょうか。
でも実際に使ってみようと思うと、「登録の仕方が難しそう」「組織やブランチってなに？」と戸惑う方も少なくありません。
この記事では、GitHubの基本から登録方法、リポジトリ・ブランチの概要までを、インフラ初心者やこれからWeb開発を始める人に向けて、やさしく丁寧に紹介していきます。