コードフロー戦略を選ぶ
チームの作業方法に適合するコードフロー戦略を選択することが重要です。 検討すべき戦略がいくつかあります。 このモジュールを完了すると、各オプションを調べることができるようになります。 Tailspin Web チームでは、Git と GitHub に基づくコードフロー戦略を開発することにしました。
Mara が Azure Boards を設定したときに、彼女とチームは、対処すべきいくつかの初期タスクを特定しました。 タスクの 1 つは、Git ベースのワークフローを作成することでした。
共同作業を行うより優れた方法を特定しようとしているチームの話し合いを聞いてみましょう。 現在は集中型バージョン管理システムを使用していますが、分散型システムである Git への移行を計画しています。
Andy が入ってきたとき、Mara は自分に割り当てられた機能に関する作業を熱心に行っています。
Andy: やあ、Mara。 今朝のリーダー会議で、自分たちのチームとゲーム開発チームが異なるバージョン管理システムを使用していることが話題になりました。 チーム間でリソースを共有する方法を合理化するため、コラボレーションにより適切に対応できる分散型のバージョン管理システムに移行するよう求められました。
Mara: それがわかってよかったです。 覚えていますか。それについてチームのボードに書きました。 現在は、集中型のバージョン管理システムを使用しています。 これは今でも良好に機能していますが、チーム間での共有を開始し、チームが大きくなったときには、分散型バージョン管理システムの方が良い選択肢であると承知しています。 また、可視性を向上させ、皆が何をしているかすべての関係者が分かるようにすることも、チームのボードに書いてあるタスクです。 また、Git のような分散型ソース管理システムも役立つと考えています。
Andy: しばらくの間、Git を試したいと思っていました。 時間があるように思えなかったのです。 学習や設定は難しいですか。 理にかなっているように思われる場合は、たぶんすぐに、それに取り組めるでしょう。 いつも物事を先延ばしにするのには飽きました。 そして、皆が何をしているのか確認でき、リポジトリ全体にアクセスできればすばらしいことです。 では、どんな選択肢があるのでしょうか。
Mara: それについて説明させてください。その後で、すぐに実装したいもののように思えるかどうか、判断していただけます。
Mara と Andy は、バージョン コントロールについての議論のため、ホワイトボードに移動します。
Git と分散型バージョン コントロールについて
Mara: 左のイラストは、私たちが現在使用しているもののような "集中バージョン コントロール" です。 全員が使用している Team Foundation バージョン管理 (TFVC) 内に、主要バージョンのコード ベース 
があります。 私たちそれぞれが、変更する必要があるファイルに対して作業を行い、作業が完了したら、それらをメイン リポジトリに戻してマージします。
Andy: そうだね、そして、私たちにとっては、それがうまく機能している。 ただ、私がブロックされた、破壊的変更が中央リポジトリにマージされたあのときを除いては、だね。
Mara: そうです! あなたはブロックされました 
。 TFVC でブランチ戦略を使用してブロックの問題を解決することもできますが、現在の構成では、マージの複雑さが少し高まる可能性があります。 その破壊的変更 
が行われたときは、それが解決されるまで誰も作業を完了できませんでした。 私たちすべてがコードの同じコピーを使用しているため、その問題は常に潜んでいます。
右側は、"分散バージョン コントロール" の図です。 安定バージョンのコード ベースである中央リポジトリ 
はまだありますが、各開発者は、その独自のコピー 
を持っており、それを基に作業を行います。 このため、中央リポジトリに影響を与えることなく、自由に実験してさまざまなアプローチを試すことができます。
また、分散型のバージョン管理では、確実に作業コード 
のみが中央リポジトリにマージされます。 レビューされるまでコードをマージできないように設定することさえできます。
Azure DevOps がすばらしいのは、集中型バージョン管理システムと分散型バージョン管理システムの両方で機能することです。
Andy: 複数の人が同じファイルを変更するとどうなりますか。
Mara: 多くの場合、Git で自動的に、複数の変更をマージできます。 もちろん、変更の組み合わせが、正しく機能するコードになることを確認したいといつも思っています。 Git で自動的に変更をマージできないときには、どの変更を受け入れるか人が選択できるように、ファイル内で直接、競合項目にマーク付けが行われます。
Andy: 現在、私たちのコードは、私たち独自のサーバーに格納されています。 分散バージョン コントロールを使用することにした場合、コードはどこに格納されますか。
Mara: 聞いてくれて嬉しく思います。 まさにそこで、ホスティングが役割を担います。
私のリポジトリをホストできるのはどこか
Mara: リポジトリをホストする場所を決定しようとしているときには、いくつかのオプションがあります。 たとえば、ローカル サーバー、Bitbucket、GitHub でそれらをホストすることができます。 Bitbucket と GitHub は、Web ベースのホスティング ソリューションです。 それらには、どこからでもアクセスできます。
Andy: それらのいずれかを使用したことがありますか。
Mara: 以前に GitHub を使用していました。 これには、コマンド ラインまたはオンライン ポータルのいずれかから変更ログとバージョン管理機能に簡単にアクセスできるといった、開発者にとって重要な機能があります。
Andy: では、Git はどのように機能するのですか。
Git を使用してどのように作業するか
Mara: 前に触れたように、分散システムでは、開発者はリポジトリの独自のコピーを持っているため、他の開発者の作業に影響を与えずに、必要なすべてのファイルに自由にアクセスできます。 "クローン" は、リポジトリのあなた用のローカル コピーです。
私たちは、ある機能やバグ修正プログラムについて作業するときに、最適なソリューションが見つかるまで、さまざまなアプローチを試したいと考えます。 ただし、メイン コード ベースのコピーに対してコードを試してみることはお勧めできません。最初の数回の試行は保持したくない場合があるためです。
より良い選択肢を提供するため、Git には "ブランチ" と呼ばれる機能があります。これを使用すると、必要なだけ多くのコピーを保持し、保持したいものだけをマージして戻します。 これで、メイン ブランチの安定が維持されます。
Andy: ここまでの概念は理解しました。 どのようにすれば自分のコードをチェックインできますか。
ローカルの変更は、どのようにメイン コード ベースに到達しますか。
Mara: Git では、既定のブランチ (すなわち "トランク") は、一般に main という名前です。
すべての開発者によって共有されている中央リポジトリ内の main ブランチにコードをマージする準備ができたら、pull request と呼ばれるものを作成します。 pull request を作成すると、レビューの準備ができているコードがあり、それを main ブランチにマージしたいと考えていることを他の開発者に伝えることになります。 pull request が承認されてマージされると、それは中央コード ベースの一部になります。
ブランチ ワークフローはどのようなものか
ステップ 1: 新しい機能やバグ修正プログラムの作業を開始するときに、最初に行うべきことは、最新の安定したコード ベースで作業を開始していることの確認です。 これを行うために、main ブランチのローカル コピーを、サーバーのコピーと同期できます。 これを行うと、自分が最後に同期して以降サーバー上の main ブランチにプッシュされた他の開発者によるすべての変更が、ローカル コピーにプルされます。
ステップ 2: コードの "コピー" に対してのみ作業を行うように、その機能またはバグ修正プログラム専用の新しいブランチを作成します。 ご想像のとおり、実行するあらゆる作業のために多くのブランチがあると、覚えておくのが難しくなるかもしれません。そのため、適切な名前付け規則を使用することが非常に重要です。
ファイルに変更を加える前に、別のブランチではなく、そのブランチからのファイルに対して作業していることが分かるように、新しいブランチをチェックアウトします。 そのブランチをチェックアウトすることで、いつでもブランチを切り替えることができます。
ステップ 3:これで、どのような変更でも安全に行えるようになりました。それらの変更は自分のブランチ内にしか存在しないためです。 作業する際に、自分のブランチに変更を "コミット" して、作業内容が失われないようにしたり、行った変更を以前のバージョンにロールバックできるようにしたりすることができます。 変更をコミットする前に、コミットの準備ができているものが Git で認識されるように、ファイルをステージする必要があります。
ステップ 4: 次のステップは、あなたが取り組んでいることを他の人が見られるように、あなたのローカル ブランチをリモート リポジトリ (GitHub など) に プッシュ (アップロード) することです。 心配しないでください。これによって、あなたの変更はまだマージされません。 自分が必要と思う頻度で作業をプッシュできます。 実際にはこれが、自分の作業をバックアップしたり、自分が複数のコンピューターから作業できるようにしたりする良い方法です。
ステップ 5: このステップは一般的なものですが、必須ではありません。 コードが希望どおりに動作していることを確認したら、あなたのリモートの main ブランチをローカルの main ブランチに戻して "プル" (マージ) することができます。 そこでは、あなたのローカル main ブランチにはまだ存在しない変更が行われてきました。 リモートの main ブランチを自分のものと同期したら、ローカルの main ブランチを自分の作業用ブランチにマージし、ビルドを再度テストします。
このプロセスは、あなたの機能が最新のコードで正しく動作することを確認する助けとなります。 また、pull request を送信したときに、あなたの作業がスムーズに統合されるようにする助けになります。
ステップ 6: ここで、あなたのローカル コードをコミットし、ホストされているリポジトリにプッシュする必要があります。 これは、ステップ 3 および 4 と同じです。
ステップ 7: あなたの変更を、ついにリモート main ブランチに提出する準備ができました。 これを行うために、pull request を開始します。 Azure Pipelines または別の CI/CD システムで構成した場合、このステップによってビルド プロセスがトリガーされ、あなたの変更がパイプライン内を移動するのを確認できます。 ビルドが成功し、他の開発者があなたの pull request を承認すると、あなたのコードをリモート main ブランチにマージすることができます。 (変更をマージするのは、これまで同様、人が判断します。)
Andy: このすべてが、複雑で学ぶのが困難に思えます。
Mara:Git は非常に高機能であるため、臆してしまうことがありますが、フローのコツをつかむと普通に作業できるようになります。
毎日使用することになるコマンドはわずか数個です。 次に概要を示します。
| カテゴリ | 作業 | 使用するコマンド |
|---|---|---|
| リポジトリ管理 | Git リポジトリを作成する | git init |
| リモート リポジトリをダウンロードする | git clone |
|
| [Branch]\(ブランチ) | 分岐を作成する | git checkout |
| 変更をステージしてコミットする | どのファイルが変更されているかを確認する | git status |
| コミットするファイルをステージする | git add |
|
| ファイルをあなたのブランチにコミットする | git commit |
|
| リモート同期 | リモート リポジトリからブランチをダウンロードする | git pull |
| リモート リポジトリにブランチをアップロードする | git push |
Andy: それはすばらしい出発点のように思えます。 私はそれを、確かに扱うことができます。 私は、必要になったときにより高度なコマンドを学習できます。