More than 1 year has passed since last update.

NECソリューションイノベータ株式会社

CodeCommitを使用した開発におけるGit操作（Part1）

Last updated at 2023-09-27Posted at 2023-09-27

はじめに

AWS CodeCommitを使用した開発では、Gitコマンドによる操作を頻繁に行います。ですが、私も含めGit初学者の方は、なんとな〜くコマンドを叩いている方も多いのではないでしょうか？

そこで本記事では、開発の流れに沿ったGitコマンドの使い方を解説していきます。

今回想定している開発の流れは大まかに以下の通りで、この流れの中で登場するGitコマンドについて紹介していきたいと思います。なお、以下の流れではGitのブランチ機能を使用した運用方法であるGit-flowを活用した開発を前提としています。

※本記事の内容は、2023年9月時点のものです。AWS CLIやGitのバージョンの違いなどが発生する場合があります。

対象者

CodeCommitを使用した開発プロジェクトに参加している方
Git初学者の方

準備

CodeCommitのリポジトリでソースコードを管理する場合、GRC(git-remote-codecommit)を使用すると、AWSアカウントの認証情報だけを設定しておくだけで、CodeCommitにアクセスできます。

またGRCの場合、1つのGitクライアント(自分のPCなど)から、別アカウントのリポジトリなど複数のリポジトリを使用できます。使用する際は、後ほど説明するプロファイルを切り替えることで、それぞれのAWSアカウントの認証情報で、それぞれのCodeCommitにアクセス可能になります。

まずは、それらの設定をしましょう！

Python3とAWS CLIのインストール

git-remote-codecommitはpipを使用してインストールするので、Python3とAWS CLIが必要になります。

まず、以下の手順を参考にPython3をインストールしてください。Pythonの場合は、Pythonのダウンロードページからインストーラーをダウンロードしても問題ありません。
git-remote-codecommit を使用して AWS CodeCommit への HTTPS 接続をセットアップする手順 - AWS CodeCommit

次に、以下の手順を参考にAWS CLIをインストールしてください。
AWS CLI の最新バージョンを使用してインストールまたは更新を行う - AWS Command Line Interface

Python3とAWS CLIがインストールされたら、pipコマンドを使用し以下のコマンドを実行してください。

pip install git-remote-codecommit

プロファイルの設定

次に、プロファイルを設定し、コマンドラインからCodeCommitにアクセスできるようにします。まずは以下の手順を参考に、AWS IAMのコンソール画面で、IAMユーザーの認証情報となるアクセスキーを取得しておきます。
AWS アカウントとアクセスキー - AWS Tools for PowerShell

アクセスキーを取得したら、以下のコマンドでプロファイルを作成します。

aws configure --profile [プロファイル名]

[プロファイル名]：任意の値
AWS Access Key ID：アクセスキーの値
AWS Secret Access Key：シークレットアクセスキーの値
Default region name：CodeCommitのあるリージョン名(例: 東京リージョンならば、ap-northeast-1)
Default output format：何も入力しない

プロファイルが作成できたら、以下のコマンドで確認しましょう。

LinuxまたはmacOSの方：

cat ~/.aws/credentials

Windowsの方(USERNAMEディレクトリ配下で)：

type .aws\credentials

※認証情報ファイルは、LinuxやmacOS では~/.aws/credentialsに、WindowsではC:\Users\USERNAME\.aws\credentialsにあります。(USERNAMEはご自身のユーザー名です。)

上記のコマンドを実行して、先ほど作成したプロファイルの情報が表示されていれば、成功です。

ここまでできれば、準備OKです！

CodeCommitにリポジトリを作成

CodeCommitを開き、「リポジトリを作成」からリポジトリを作成します。

プロジェクトによっては、リポジトリのクローンから始める場合もありますし、他のリポジトリの情報をコピーして始める場合もあります。その場合は、リポジトリのクローンから見てください。

リポジトリのクローン(`Clone`)

クローン(`Clone`)

Cloneとは、ローカルの作業ディレクトリにリモートリポジトリ(ここではCodeCommitのリポジトリ)を複製することです。Cloneには、以下のコマンドを使用します。

git clone codecommit://[プロファイル名]@[リポジトリ名]

なお、[プロファイル名]には、準備のときに作成したプロファイル名を、[リポジトリ名]には、対象のCodeCommitのリポジトリ名を入れます。

プル(`Pull`)

すでにローカルリポジトリが存在し、最新コードを反映したい場合には、Pullすることでローカルリポジトリをリモートリポジトリの情報に更新できます。

まずは、以下のコマンドでリモートリポジトリを追加しましょう。

git remote add origin codecommit://[プロファイル名]@[リポジトリ名]

このコマンドにより、リモートリポジトリをcodecommit://[プロファイル名]@[リポジトリ名]ではなく、originで指定できるようになります。またこの場合、origin以外の文字列を使用すれば、他のリモートリポジトリも追加できます。

次に、以下のコマンドで、追加したリモートリポジトリ(origin)とブランチを指定して、Pullしましょう。

git pull origin [ブランチ名]

なお、[ブランチ名]を省略した場合には、現在いるブランチ(カレントブランチ)が入ります。

これで、コードの編集を開始できます！と言いたいところですが、まず以下のコマンドでご自身のカレントブランチを確認してください。

ブランチの確認

git branch

おそらく、mainかdevelopブランチにいると思います。

各ブランチの特徴がわからない方はこちら

mainブランチは、リモートリポジトリを作成した時点で自動的に作成されるデフォルトブランチで、開発プロジェクトにおけるmainブランチは本番環境の運用のために使用されるブランチです。

そのため、リリース中のサービスなどに影響を及ぼさないようmainブランチ上でコードを修正したりすることはありません。そこで、developブランチと呼ばれる、最新コードを管理するための開発の中心となるブランチを、mainブランチから派生させます。

ですが、このdevelopブランチもmainブランチ同様に、このブランチ上でコードを修正したりすることはありません。あくまでも、本番環境と開発中の環境を切り分けるために設けるブランチで、機能の開発や修正のための実際に作業を実施するブランチは、このdevelopブランチからさらに派生させたfeatureブランチと呼ばれるブランチ上で行います。

`feature`ブランチの作成

ブランチの作成

開発プロジェクトでは、「ブランチを切る」と言ったりしますが、カレントブランチを元にしてfeatureブランチを作成する場合は、以下のコマンドを実行します。

git branch feature_xxx

派生元のブランチを指定したい場合は、feature_xxxの後ろに、派生元のブランチ名を入れてください。

feature_xxxはご自身のプロジェクトにおける命名ルールに則ってください。プロジェクトによって、featureの後は、_や-や/だったりしますが、その後の文字列は作業内容がわかるような名前やバックログ名などが入るようです。

ブランチの切り替え

ブランチを作成したら、そのブランチに移動しましょう。ブランチを作成してもブランチが切り替わっているわけではないので、以下のコマンドでブランチを切り替えます。

git switch feature_xxx

ちゃんと移動できたかどうかは、git branchで確認してください。

ブランチの作成＆切り替え

ちなみに、ブランチの作成と切り替えを同時に行うこともできて、その場合には-cオプションを付けて、コマンドを実行します。

git switch -c feature_xxx

こうしてはじめて、コードを編集し機能の実装や修正作業を開始できます。

ステージング(`Add`)

Gitにおけるコードの在り処

コードの修正が完了したら、ステージング環境にその修正したファイルを登録します。

Gitにおけるコードの格納場所があやふやな方はこちら

Gitではコードの格納場所ごとにいろんな名前が付いていますので、それらをおさらいしましょう。

場所	説明
リモートリポジトリ	AWS CodeCommitなど、ネットワークに接続されたサーバ上にあるリポジトリのことです。複数人で共有できます。
ローカルリポジトリ	「リモート」に対して「ローカル」なので、自分のPCなどにある自分専用のリポジトリのことです。`git clone`した場合は、指定したリモートリポジトリが複製されます。
ワーキングツリー	Gitで管理されている、実際に作業をしているディレクトリのことです。つまり、作業中のファイルパスのことを指します。
ステージング環境(インデックス)	ワーキングツリーで作業した変更(ローカルリポジトリとワーキングツリーの差分)を一時的に登録しておく場所です。ローカルリポジトリからリモートリポジトリの修正の反映は、このステージング環境を介して行われます。

差分(`Diff`)の確認

Addする前に、以下のコマンドを実行しておきましょう。

git diff

これは、ローカルリポジトリとワーキングツリーの差分を確認するためのコマンドです。自分が修正した内容や範囲を把握できます。

git diffで自分が修正したファイル以外の内容が表示されるのであれば、他のファイルに何か余計な操作をしたことになります。(例えば、コードフォーマッターを全ファイルに適用したとか。)

本当にその変更でいいのか確認するために、git diffコマンドを実行する癖をつけましょう。

変更したファイルをステージング環境に登録する

コードの修正が完了し、差分を確認して問題なければ、以下のコマンドで作成や修正、削除した(総じて変更を加えた)ファイルをステージング環境に登録(Add)します。

git add .

ただし、上記のコマンドの場合は、変更範囲すべてがAddされます。特定のファイルのみAddしたい場合は、以下のように対象のファイルのファイルパスを指定します。

git add [ファイルパス]

Addしたいファイルが複数ある場合は、[ファイルパス1] [ファイルパス2] ...のように続けて書いてください。

コミット(`Commit`)

`Add`したファイルをローカルリポジトリに登録する。

git addでステージング環境に登録したファイルを、次はローカルリポジトリに登録します。

git commit -m 'コミットメッセージ'

コミットメッセージには、作業した内容などを簡潔に書きます(例：△△機能を実装)。これも、featureブランチの命名ルールと同様にプロジェクトのルールに則りましょう。

また、Commitは次の章で行うPushまでに複数回実行できます。例えば、△△機能を実装するにあたって、□□機能と◇◇機能の2つの機能を先に実装しなければいけないなどの場合に、それぞれの機能の実装ごとにCommitしておくこともできます。

プッシュ(`Push`)

ローカルリポジトリのコミット履歴をリモートリポジトリに反映する

Pushとは、ローカルリポジトリのコミット履歴をリモートリポジトリにアップロードすることです。Push時は、リモートリポジトリのブランチ名を指定して行います。

featureブランチを切って作業した内容をPushする場合は、Push先のブランチは、ローカルで作成したfeatureブランチ名を指定してください。

git push -u origin feature_xxx

Push前は、リモートリポジトリに対象のブランチは作成されていませんが、その状態でPushすると、自動的にそのブランチを作成します。ですので、ローカルで切ったブランチ名を指定してあげれば、同じ名前でリモートのブランチが作成されます。

初回Push時に-uオプションを付けることで、次回以降のPushはgit pushのみで、feature_xxxブランチを指定してのPushとみなされます。-uとは、--set-upstreamの省略形で、Push対象のリモートリポジトリのブランチを上流ブランチとして指定するために使用します。Pushはこの上流ブランチを対象として行われます。

プルリクエスト(`Pull Request`)

リモートリポジトリにコードの変更を反映する

Pull Requestとは、ローカルリポジトリでの変更(Pushした内容)をリモートリポジトリに反映するために、他の開発メンバにレビューやマージ(Merge)を依頼することです。よく、「プルリク」と言われてます。

レビューとは、他の開発メンバにコードの修正が適切かどうかチェックしてもらうことで、Mergeとは、コードの変更内容を取り込むことです。今回の場合では、featureブランチでの変更内容をdevelopブランチに取り込むことになります。

Pushした内容が自分以外の誰の目も介さず、Mergeされてしまうと、思わぬバグを引き起こしてしまう可能性もあります。なので、Mergeされる前に、他のメンバにレビューを行ってもらうことで、コードの品質をより向上させることができるようになります。

CodeCommit上でのプルリクの出し方

CodeCommitのコンソール画面で対象のリポジトリを開きます。次に、「ブランチ」タブから、Pushしたブランチ(feature_xxxブランチ)を選択し、「プルリクエストの作成」をクリックします。

すると、以下のようにdevelopブランチにfeature_xxxブランチの内容をMergeしようとしていることがわかります。

詳細には、適切な「タイトル」と「説明」を入力します。

また、下にスクロールすると、今回のコードの変更箇所が確認できます。特に問題なければ、一番下の「プルリクエストの作成」をクリックします。

画像の例だと、index.htmlの11行目を修正したということがわかります。

ここまでが、開発者として実際に作業する内容ですが、レビュアーの目線でマージまで行ってみたいと思います。

先ほど作成されたプルリクは、「プルリクエスト」タブから確認できます。

コードの変更がこの内容で問題なければ、右上の「マージ」をクリックします。一方、コードの変更に問題があれば、コメントを記載することもできます。(対象のファイルの対象の行にカーソルを合わせてクリックすると、コメントを入力できます。)

レビューにより指摘があった場合は、開発者は指摘箇所の修正を行い、再び同じブランチにPushすれば、レビュアーは改めてコードの変更を確認できます。

最後に、Mergeを行いましょう。「マージ」をクリックすると、以下の画面に遷移します。

マージの種類を選択できますが、ここでは複数のコミットを１つにまとめてリポジトリの履歴を簡素にするために、「スカッシュしてマージ」を選択します。

それぞれのMergeの説明は以下を参考にしてください。
AWS CodeCommit リポジトリでプルリクエストをマージする - AWS CodeCommit

下にスクロールし、「作成者名」と「Eメールアドレス」を入力したら、一番下の「プルリクエストのマージ」をクリックします。

なお、「マージ後にソースブランチ feature_xxx を削除しますか?」にチェックが入っていますが、featureブランチは作業内容やバックログ単位で作成されるものなので、Merge後は不要なブランチになります。なので、Merge時に削除します。

これで、ローカルで作業した内容が無事developブランチに取り込まれました！

さいごに

今回、開発の流れに沿って、よく使用するGitコマンドをまとめてみました。当初はよく分からず行っていた操作でも、改めて何を行っているのか整理するのは大事だと感じました。

そして実は、今回の記事ではまだ説明できていないのですが、リベース(Rebase)というよく行う操作があります。この操作についても追々記事にできたらなと考えていますので、乞うご期待ください。

参考

本記事を執筆するにあたって、参考にしたページを以下に記載いたします。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up