Azure DevOpsのソースコード管理ツール「Azure Repos」を使いこなそう

Azureのクラウド環境でDevOpsを実現する「Azure DevOps」入門 第3回

Azure Reposでソースコードを管理してみよう

　ここからは実際に、Azure Reposを使ってソースコードのバージョン管理を行っていきます。まずは、既存のソースコードをAzure Repos上にプッシュするところから始めます。

（1）ソースコードの準備

　プッシュするソースコードは任意のもので構いません。本記事では例として、Visual Studio Code（VS Code）を使用し、ASP.NET CoreのWebアプリケーション用のソリューションを作成したものをプッシュしていきます。

　ソリューション作成時点では、ソリューションはGit管理外となっています。VS Codeの左端にあるアクティビティバー上にある「ソース管理」のアイコンを選択すると、Gitリポジトリの初期化を行うことができます。「Initialize Repository」（VS Codeを日本語化している場合は「リポジトリを初期化する」）ボタンを選択するとソリューションがGitで管理されるようになります。

図1：ソリューションをGitリポジトリとして初期化する

　そのままソース管理の画面でコミットを行います。任意のメッセージを入力し、「コミット」ボタンでコミットを実施します。初回コミットのためソリューション内のすべてのファイルがコミットされます。

図2：ソースコードの初回コミット

（2）ソースコードのプッシュ

　プッシュするソースコードが用意できたら、次にAzure Reposへのソースコードのプッシュ方法を確認します。Azure DevOpsのプロジェクトのトップ画面を表示し、左側のメニューから「Repos」を選択します。

図3：Azure Reposの初期画面

　初期状態ではソースコードのクローン方法やプッシュ方法の手順が表示されています。この画面上の「Clone to your computer」のセクション内にある「Generate Git Credentials」を選択すると、Azure Repos用のユーザー名とパスワードが表示されるので控えておきます。

　次に「Push an existing repository from command line」に記載されているコマンドをコピーしてソースコードをプッシュします。VS Code上でターミナルを開き、コピーしたコマンドをペーストします。

　するとAzure Reposのパスワードを要求されるため、先程控えておいたパスワードを入力します。

　認証に成功すると、ソースコードがAzure Reposにプッシュされます。ブラウザをリロードすると、プッシュされたファイルを参照できるようになります。

図4：ソースコードをプッシュした後の画面

（3）プッシュ後の画面を確認する

　各メニューを選択した場合に表示される画面の内容は、以下の通りになります。

Files

　このリポジトリにコミットされている全てのファイルを確認できる画面です。他にもファイルのアップロードやダウンロード、編集なども行えます。

Commits

　このリポジトリに対して行われた全てのコミット履歴が表示される画面です。

図5：コミット履歴の例

　一覧から任意のコミットを選択することで、そのコミットで行われた修正内容をファイルごとに参照できます。

Pushes

　ローカルリポジトリでの更新内容をリモートリポジトリへ反映するプッシュの履歴を確認できる画面です。

図6：プッシュ履歴の例

　コミット履歴と似ていますが、プッシュでは複数のコミットを一度にまとめられるため、プッシュ履歴では各プッシュに紐づくコミットを確認できます。

Branches

　Gitのブランチとは作業の分岐点であり、元のコードに影響を与えずに変更を加えるための仕組みです。例えば新機能の開発やバグの修正を本番環境に影響を与えずに行えるようになります。ブランチは「マージ」と呼ばれる操作によって別のブランチに統合できます。

　Branchesの画面では、このリポジトリに現在存在しているブランチの一覧を確認したり、新たにブランチを作成したりできます。

図7：ブランチ一覧の例

　Gitでは通常、リポジトリ作成時にmain（以前はmasterという名称）というブランチが作成されます。新しいブランチは既存のブランチや特定のコミットを起点に作成できます。

　また、この画面からブランチポリシーをブランチごとに設定することも可能です。ブランチ名の右端にあるメニューボタンから「Branch Policies」を選択するとポリシーを設定できます。

図8：ブランチポリシーの選択

　ブランチポリシーを設定すると、後ほど説明するプルリクエストによるマージが必須となります。

　ポリシーには、レビュアーの最小人数の設定、Azure Boardsのワークアイテムの紐づけの要求、Azure Pipelinesでのビルド成功の必須化などがあります。

図9：ブランチポリシーの設定例

Tags

　Gitのタグは特定のコミットに名前をつけて目印とする機能です。主にリリース時などの重要な節目を示すために使い、後からその時点の状態を簡単に参照する際に用いられます。

　Tagsの画面では、タグの一覧を確認できます。

Pull requests

　プルリクエストはGitに備わっている機能ではなく、GitHubやAzure ReposなどのGitホスティングサービスが提供する機能です。プルリクエストは他者に自分の変更内容をレビューしてもらい、対象となるブランチへのマージの可否を判断してもらうためのスペースです。コードの確認、議論、承認といったレビューのためのプロセスが提供されます。

　Pull requestsの画面は、このプルリクエストの作成や確認を行う画面です。

　「Pull requests」以外のメニュー名は、Gitの用語に準ずるものなので、Gitの使用経験があればすぐに理解できるメニュー構成となっています。