Gemini を使っていると、ふと
「これ、Mac のアプリみたいにすぐ起動できたら最高なのに」
と思うことはありませんか。
ChatGPT には専用アプリがあるのに、Gemini は基本的にブラウザで使う前提。
その結果、タブの海に沈んでいく……というのは、わりと“あるある”です。
この記事では、Gemini には Mac アプリがないという前提を整理しつつ、
Chrome で Gemini を「アプリ化」して快適に使う方法をまとめます。
前回の記事では、GitHub を使ったチーム開発の中で、
コンフリクト（conflict）がなぜ起こるのか を整理しました。
今回はその続きとして、
「実際にコンフリクトが起きたとき、どう解消していけばいいか」 にフォーカスしていきます。
合わせて、「コンフリクト＝悪」ではなく、調整のサインとして捉える考え方も整理してみましょう。
Contents
前回の記事では、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でチーム開発をしていると、
といった疑問や戸惑いがよく出てきます。
この記事では、僕が実際の現場で使っている運用イメージをベースに、小〜中規模チームでも無理なく回せるプルリク運用をイメージできるように解説していきます。