AWS 認定ソリューションアーキテクト – アソシエイト（SAA）は、
「AWS で現実的なシステム構成を考えられるか」を問われる試験です。
サービス名の暗記だけでは太刀打ちできず、
シナリオを読み解いて「この条件なら、この構成だな」と選べるようになる必要があります。
この記事では、私が SAA 学習で一番使った
『一夜漬け AWS認定ソリューションアーキテクト-アソシエイト【C03対応】直前対策テキスト（山内貴弘 著）』
の紹介と、
この本を軸にした 3 ステップの勉強方法をまとめます。
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