コードフロー戦略を選ぶ

チームの作業方法に適合するコードフロー戦略を選択することが重要です。 検討すべき戦略がいくつかあります。 このモジュールを完了すると、各オプションを調べることができるようになります。 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 を使用してどのように作業するか

マラ： 前述のように、分散システムでは、開発者はリポジトリの独自のコピーを持っているため、他の開発者の作業に影響を与えることなく、必要なファイルに自由にアクセスできます。 "クローン" は、リポジトリのあなた用のローカル コピーです。

私たちは、ある機能やバグ修正プログラムについて作業するときに、最適なソリューションが見つかるまで、さまざまなアプローチを試したいと考えます。 ただし、メイン コード ベースのコピーに対してコードを試してみることはお勧めできません。最初の数回の試行は保持したくない場合があるためです。

より良い選択肢を提供するため、Git には "ブランチ" と呼ばれる機能があります。これを使用すると、必要なだけ多くのコピーを保持し、保持したいものだけをマージして戻します。 これで、メイン ブランチの安定が維持されます。

Andy: ここまでの概念は理解しました。 どのようにすれば自分のコードをチェックインできますか。

ローカルの変更は、どのようにメイン コード ベースに到達しますか。

Mara: Git では、既定のブランチ (すなわち "トランク") は、一般に main という名前です。

すべての開発者によって共有されている中央リポジトリ内の main ブランチにコードをマージする準備ができたら、pull request と呼ばれるものを作成します。 pull request を作成すると、レビューの準備ができているコードがあり、それを main ブランチにマージしたいと考えていることを他の開発者に伝えることになります。 pull request が承認されてマージされると、それは中央コード ベースの一部になります。

ブランチ ワークフローはどのようなものか

Andy: このすべてが、複雑で学ぶのが困難に思えます。

Mara:Git は非常に高機能であるため、臆してしまうことがありますが、フローのコツをつかむと普通に作業できるようになります。

毎日使用することになるコマンドはわずか数個です。 次に概要を示します。

Andy: それはすばらしい出発点のように思えます。 私はそれを、確かに扱うことができます。 私は、必要になったときにより高度なコマンドを学習できます。