アジャイルチーム向け Git ブランチ

Git への移行により、まったく新しいレベルのアジリティがソフトウェアチームにもたらされる理由

Sarah Goff-Dupont Sarah Goff-Dupont

集中型のバージョン管理を悩ませる、ぎくしゃくしたコードフリーズと一枚岩の大規模マージから解放され、開発者は進行中の作業を分離し、狭い垂直スライス型の開発により簡単にビルドできます。Git を使用したブランチとマージはまったく手間がかからないため、多くのチームでは、実装するユーザーストーリーやバグ修正ごとに新しいブランチを作成しています。このモデルはいち早くアジャイルチームの新しい業界標準になりつつあります - それには当然の理由があります!

ポップコーンを手にくつろぎながら、これまでで最も人気あるウェビナーの一つをご覧ください。このウェビナーで学習する内容: 

  • 各課題にブランチを作成するモデルによって、チームが動作するコードを継続的に提供しやすくなるのはなぜか
  • 開発者にはワークフローがどのように見えているか
  • このモデルを既存の継続的インテグレーションやコードレビュー業務とどのように統合するのか
  • このモデルを評価する際に考慮すべきトレードオフ

見て学ぼう

Q & A

いい内容でしょう? 

さて、あなたが私と似たようなタイプだったら、ウェビナーの Q&A までずっと見ていることはないでしょうね。大丈夫です。よくあることですから。それで、さっと目を通して、あとで時間のあるときに読めるように、質問の一部を転載しておきました。 

Q:こうしたブランチすべてのバージョン番号をどうやって取り扱うのですか。コード行をどのように区別しますか。 

A:一般的に、チームは対応するリリースバージョン名をとってブランチに名前をつけます。たとえば、Stash を作成するチームがリリース 2.9 の準備を終えた時は、「stash-2.9」という名前の安定ブランチを作成しました。そうすると、そのブランチをリポジトリ内で見た時に、どういう内容か大変わかりやすいのです。チームでどのような命名規則を使用してもかまわないのですが、ただどこかにバージョン番号を含めてください。

Q:例では、各ブランチに 1 人が作業していました。2 人で 1 つのストーリーの作業をしている場合は、どのようなブランチ構造と命名規則が適切でしょうか。

A:同じ課題のブランチを 2 人で作業してもかまいません。ただ、リベースしないなど、ブランチを共有する際の基本的なエチケットに従い、ブランチのローカルコピーでの作業は他の人の悩みの種となるので、通常は避けるようにしてください。もう一つの選択肢として、共同で作業する人が課題のブランチをそれぞれ作成し、そのあと頻繁に互いにマージする方法があります。2 人で作業する際の命名規則は、<名前/イニシャル>-<課題キー>-<説明> (たとえば、sarah-DEV-1234-company-name-misspelled-on-homepage) としてもいいでしょう。開発者が 1 人で担当するブランチに使用するのと似たようなものです。

Q:開発ブランチに変更が生じるたびに、すぐに 1 つのブランチに変更をマージしない場合、依存性をどう処理するのでしょうか。

A:進行中の作業の両方に依存部分がある場合、コードの各部分に取り組んでいる開発者が互いの変更部分を相互に頻繁にマージするようにします。Git では、まず始めにどちらかの開発者のブランチを中央ブランチにマージしなくても、両方の開発者が直接ブランチ同士をマージするだけで、この処理ができます。他のオプションは、前にお話しした共有統合ブランチを使用する方法です。

Q:しばらく前に、Martin Fowler 氏はフィーチャーブランチがリファクタリングを妨げ、ブランチの使用中は継続的なビルドは行っていても、継続的なインテグレーションは行っていないと、このブランチに反対しました。

A:はい、そのテーマについての彼の投稿はよく知っています。かなり前のことでした - 多分 2008 年か、2009 年です。その時からすると、フィーチャーブランチ上で CI を実行する機会はかなり多くなったと考えています。さらに、このウェビナーの "考慮事項" の部分でお話ししたように、課題ごとにブランチを作成するアプローチでは、純粋な CI を行っていません。継続的なビルドと継続的なテストは行っていても、継続的なインテグレーションは行っていないのです。しかし、ブランチスキームに共有統合ブランチを含めることによって、純粋な CI に近づけることができます。