機能が具体化され、製品ロードマップに追加され、開発チームの準備が整ったら、Git の出番です。しかし、ここで一歩引いてしまうと、アジャイル機能開発はあっという間に失敗してしまいます。製品、デザイン、QA (品質保証)、エンジニアリング チームで機能キックオフ ミーティングを開催し、どのような機能を作成するか (要件)、プロジェクトのスコープ、完了するために機能を分割して作成すべきタスクは何かについての理解を共有します。ユーザー ストーリーとも呼ばれるこれらのタスクは、その後個々の開発者に割り当てられます。

Git はこの時点で、アジャイル ワークフローに適合し始めます。アトラシアンでは、すべての課題に対して新しいブランチを作成しています。新しい機能でも、バグ修正でも、既存コードにおける小さな改良でも、すべてのコード変更に独自のブランチが割り当てられます。

ブランチングはシンプルで、チームは 1 つの中心的なコード ベース内で簡単にコラボレーションできます。開発者がブランチを作成すると、実質的に分離された固有のコード ベースのバージョンができ上がり、それに変更を加えることができます。アジャイル チームにとってこれは、機能をユーザー ストーリーに、それからブランチに分割することで開発チームが個々にタスクに取り組み、同じコード上でも異なるリポジトリでより効率的に作業できるようになることを意味します。作業の重複はありません。個人が主要なリポジトリからは離れたリポジトリで、小さく分割された作業に集中できるため、開発プロセスの速度を落とすような依存関係が減少します。

ブランチが完了してコード レビューの準備ができたら、Git はアジャイル開発のワークフローにおけるもう 1 つの主要な役割であるテストを行います。成功を収めるアジャイル チームと DevOps チームは、コード レビューを実施して自動化テストを設定します (継続的なインテグレーションまたは継続的なデリバリー)。開発者はコード レビューとテストのために、ブランチ作業のレビューの準備ができたこととプル リクエストを通じてレビューする必要があることを、簡単にチームの他のメンバーに通知できます。プル リクエストをさらに掻い摘んで説明すると、ブランチの 1 つのテスト準備が整ったのでメイン ブランチにマージしてほしいと他の開発者にリクエストする方法だと言えます。

適切なツールを使用すれば、継続的インテグレーション サーバーを構築し、マージする前にプル リクエストをビルドおよびテストできます。これにより、マージによって問題が発生しないことを確信できます。この確信により、バグ修正や競合の再ターゲットが一般的に容易になります。これは、Git によってブランチが分岐した後のブランチとメイン コード ベースの違いが明確になるためです。

Git やアジャイルのストーリーは、効率性、テスト、自動化、全体的なアジリティに関するものです。ブランチをメイン ブランチにマージすれば、アジャイル ワークフローは完了です。また、プル リクエストを通じてコードをマージするということは、コードが完了したときに、作業に問題がなく、他のチーム メンバーもコードを終了してリリースの準備ができていると自信を持って把握するための文書があるということです。これが、アジャイル チームをスピーディーに動かして、頻繁にリリースする自信に繋がります。そう、優れたアジャイル チームの印です。