Gitの基本とAWS開発サービスとの連携

ソフトウェア開発では、ソースコードを変更するだけでなく、どの変更をいつ誰が加えたかを追跡し、複数人の作業を安全にまとめる必要があります。Gitは、このために広く使われている分散バージョン管理システムです。AWSがGitそのものを提供しているわけではありませんが、AWSのビルド・デプロイサービスはGitリポジトリをソースとして利用できます。

Gitを使うときは、変更を記録する仕組みであるGitと、リポジトリをホストするサービスを区別します。GitHub、GitLab、Bitbucket CloudなどはGitリポジトリを共有するためのサービスです。AWS CodePipelineが外部のGitプロバイダーに接続する場合は、通常AWS CodeConnectionsを利用します。

Gitリポジトリと分散管理

Gitリポジトリには、ファイルの現在の状態だけでなく、コミット履歴やブランチなどの情報が保存されます。中央のサーバーだけに履歴を置く方式とは異なり、開発者はリポジトリを複製し、自分の端末にも履歴を持った環境を作ります。そのため、ローカルで履歴を確認したり、ネットワークに接続していない間に変更を記録したりできます。複数人で変更を共有する段階では、GitHubなどのリモートリポジトリへ変更を送ります。

Gitには、作業中のファイルを置くワーキングツリー、次のコミットに含める変更を選ぶインデックス（ステージング領域）、確定した履歴を持つローカルリポジトリがあります。変更は次の段階を通ります。

段階	主な操作	役割
ワーキングツリー	ファイルを編集する	ローカルで追加・変更・削除を行う場所
インデックス	git add	次のコミットに含める変更を選択する
ローカルリポジトリ	git commit	選択した変更をローカル履歴として記録する
リモートリポジトリ	git push	ローカルのコミットを共有先へ送る

git addは変更をリモートへ送る操作ではありません。ワーキングツリーの変更からコミットに含めるものをインデックスへ登録します。登録後にファイルを再度編集した場合、最後にgit addした状態と最新のワーキングツリーの状態は異なることがあります。コミットに含めたい変更を確認してから記録することが大切です。

git commitはローカルリポジトリに変更を記録します。コミットには変更内容を特定する情報、作成者や日時、変更の意図を説明するメッセージが含まれます。コミット後も、その変更はまだ共有先に送信されていません。git pushを行うと、ローカルにあるコミットをリモートリポジトリへ転送できます。

リリースの区切りを示す場合は、特定のコミットにタグを付けられます。タグはバージョン名などをコミットに結び付ける目印です。コミットの履歴を置き換えるものではなく、どのコードをリリースしたかを後から参照するのに役立ちます。

リポジトリの取得と更新

プロジェクトに初めて参加するときは、git cloneでリモートリポジトリをローカルに複製します。通常のcloneでは履歴を含むリポジトリデータを取得し、リモートのブランチを追跡できるようにします。また、既定ブランチの内容がチェックアウトされ、ワーキングツリーとインデックスに展開されます。履歴を省略する深さ指定などを行わない一般的なcloneは、作業開始に必要なローカルリポジトリとファイルを用意します。

チェックアウトは、作業対象のブランチやコミットを選び、ワーキングツリーにその内容を反映する操作です。現在作業しているブランチを切り替えるほか、新しいブランチを作成して切り替える際にも使われます。チェックアウト後は、そのブランチ上で行ったコミットがブランチの履歴に追加されていきます。

作業中にリモートの更新を確認するには、git fetchを使います。fetchはリモートから新しいコミットや参照を取得し、ローカルのリモート追跡ブランチなどを更新しますが、通常は現在のブランチやワーキングツリーを自動的に変更しません。どの変更が届いたかを確認してから、統合方法を選べます。

git pullは、リモートから更新を取得したうえで、現在のブランチに取り込む操作です。一般にはfetchの後にmergeを行いますが、設定やコマンドの指定によってはrebaseで統合することもあります。つまり、pullはfetchより一段進み、取得した変更を現在の作業ブランチへ反映します。未コミットの変更があると統合できなかったり、意図しない競合が発生したりするため、作業状態を確認してから実行します。

複数人での開発とプッシュの拒否

複数人が同じリモートブランチから作業を始め、それぞれコミットを作成したとします。一人が先にpushすると、リモートブランチはそのコミットを含む状態へ進みます。もう一人が古いリモート状態を基にしたコミットをpushすると、相手の変更を失わせる可能性があるため、Gitは更新を拒否することがあります。これは一般にnon-fast-forwardの拒否と呼ばれます。

拒否されたときは、リモートの最新変更をfetchまたはpullで確認してローカルの作業へ統合します。同じファイルの同じ行などを両方が変更している場合は、Gitが自動で統合できずマージ競合になります。競合箇所を確認し、両方の意図を反映した内容へ編集した後、統合結果をコミットしてからpushします。無理に相手の更新を上書きするのではなく、共有履歴に沿って変更をまとめます。

日常的な共同開発では、統合先のmainブランチへ全員が直接pushする方法だけに頼りません。機能ごとのブランチで変更し、レビュー後に統合する流れがよく使われます。

たとえば、図書館の座席予約アプリを開発するチームで、ある担当者が予約時間の変更機能を作るとします。担当者は最新のmainから機能用ブランチを作り、そのブランチ上で編集・テストを行います。変更をgit add、git commitで記録し、そのブランチをリモートへpushした後、プルリクエスト（GitHubではPull Request、他のサービスではMerge Requestなどと呼ぶ）を作成してレビューを依頼します。

レビュー担当者は差分を確認し、必要なら修正を依頼します。問題がなければ、機能ブランチをmainへマージします。こうすると、共有ブランチへ入る前に変更内容を確認でき、ブランチ保護や必須レビューなどのルールも適用できます。担当者ごと・機能ごとにブランチを分けることで、各人の作業を独立して進めやすくなります。

ブランチを分ければ競合がなくなるわけではありません。複数ブランチが同じ箇所を変更した場合、マージ時に競合を解決する必要があります。また、長い間mainの変更を取り込まずに作業すると、統合する変更量が増えて解決が難しくなります。小さく頻繁に統合し、レビューで変更の意図を共有することが有効です。

AWS開発サービスからGitリポジトリを使う

GitリポジトリはAWS外部のサービスに置くことができます。AWS CodePipelineのソースアクションは、対応する外部プロバイダーのリポジトリからソースを取得し、変更イベントに応じてパイプラインを開始できます。GitHubやBitbucket Cloudなどを接続する際に、AWS側とプロバイダー側の連携を管理するサービスがAWS CodeConnectionsです。

接続を作るときは、Gitプロバイダー側でアプリケーションを認可し、AWS側でその接続をパイプラインのソースアクションに指定します。単にリポジトリ名やブランチ名を入力するだけでは、プロバイダー側の認可やAWS側の権限設定まで完了したことにはなりません。組織リポジトリでは組織の所有者や管理者による承認が必要になる場合があります。

CodeConnectionsは、AWSのリソースと外部ソースプロバイダーをつなぐ接続を提供します。CodePipelineは接続を使ってソースを取得し、対象ブランチへのpushなどのイベントをパイプラインの起動に結び付けます。その後のビルドはCodeBuildなどのアクションが実行します。権限を考えるときは、パイプラインの実行ロールが接続を利用できること、プロバイダー側で対象リポジトリへのアクセスが認可されていることを両方確認します。

CodeConnectionsは2024年3月にAWS CodeStar Connectionsから名称変更されました。既存の接続やcodestar-connectionsを含むリソース名・権限表記も引き続き存在するため、古い手順やポリシーを扱うときは、接続のARNとIAMポリシーのサービスプレフィックスが一致していることを確認してください。接続アクションや利用できるプロバイダーはリージョンによって異なる場合があります。

AWSのGitベースのリポジトリホスティングサービスであるAWS CodeCommitの提供状況にも変更がありました。CodeCommitは2024年7月に新規顧客向けの提供を停止しましたが、既存顧客は継続して利用でき、2025年11月25日からは新規顧客にも再び提供されています。したがって「CodeCommitは終了した」と一律に判断せず、設問の時点やAWSの現在の案内を確認します。CodeCommit、GitHubなどの外部ホスティングサービス、CodeConnectionsは役割が異なります。CodeCommitはリポジトリをホストし、CodeConnectionsは外部プロバイダーとの接続を管理します。

コマンドの役割を順序で理解する

コマンド	主な用途	変更が反映される場所
git clone	リモートリポジトリを初回取得する	新しいローカルリポジトリとワーキングツリー
git checkout	作業ブランチやコミットを切り替える	ワーキングツリーとインデックス
git add	次のコミットに含める変更を選ぶ	インデックス
git commit	変更を履歴として記録する	ローカルリポジトリ
git fetch	リモートの新しい履歴を取得する	ローカルリポジトリのリモート追跡情報
git pull	リモートの変更を取得して現在のブランチへ統合する	ローカルブランチと、統合結果に応じたワーキングツリー
git push	ローカルのコミットを共有先へ送る	リモートリポジトリ

学習中は、git add、git commit、git pushを一つの操作として覚えず、「ステージする」「ローカル履歴に記録する」「共有先に送る」の三段階として捉えます。また、git fetchは状況を確認するために取得し、git pullは取得した変更を現在のブランチに統合する点で異なります。

試験で押さえるポイント

• GitとGitHubなどの違い：Gitはバージョン管理の仕組み、GitHub・GitLab・Bitbucket CloudはGitリポジトリをホストして共同作業を支援するサービス。
• 変更の記録と共有：git addでインデックスへ登録し、git commitでローカル履歴へ保存し、git pushでリモートへ共有する。
• 初回取得と更新：初回の複製はgit clone、リモートの履歴だけを取得する操作はgit fetch、取得内容を現在のブランチへ統合する操作はgit pull。
• 並行作業：機能ブランチとプルリクエストでレビュー後に統合する。ブランチ分割は作業を整理するが、同じ箇所の編集による競合は解決が必要。
• AWSとの接続：CodePipelineで外部Gitサービスのリポジトリを使う構成ではCodeConnectionsで接続し、プロバイダー側の認可とAWS IAM権限を設定する。
• AWS CodeCommitの提供時期：2024年に新規顧客向け提供を停止した後、2025年11月25日から新規顧客にも提供を再開した。既存顧客は提供停止期間中も継続利用できた。

公式ドキュメント

• Git公式ドキュメント：Gitの基本
• Git公式ドキュメント：ブランチとマージ
• CodePipelineの外部Gitプロバイダー向けソースアクション
• AWS CodeConnectionsの名称変更について
• AWS CodeCommitユーザーガイドの変更履歴