分岐は継続的な統合を中断しますか？

この記事「成功したGit分岐モデル」は、経験豊富なDVCSユーザーの間で非常によく知られていると思います。

私はhg主に使用しますが、この議論はどのDVCSでも問題ないと主張します。

現在のワークフローは、各開発者がマスターリポジトリのクローンを作成することです。独自のローカルリポジトリにコードを記述し、テストを実行し、すべてがうまくいけばマスターにプッシュします。

そこで、JenkinsのようなCIサーバーをセットアップし、将来のプロビジョニングシステム（シェフ、パペット、アンシブルなど）でワークフローを改善したいと考えています。

実部

さて、上記のモデルはうまく機能しますが、ブランチはCIを壊す可能性があります。機能ブランチは、developmentCIとマージをスムーズにするために、オリジンと同期する必要があります（記事によると、ブランチになります）。

アリスとボブが2つの機能に取り組んでいると言います。しかし、アリスは翌日に行われます。ボブの機能には1週間かかります。Bobが完了するまでに、彼の変更は古くなっています（おそらく、Aliceは一部のクラスをリファクタリング/名前変更しています）。

1つの解決策は、毎朝、開発者がプルmaster/originして、変更があるかどうかを確認する必要があることです。Aliceがコミットした場合、Bobは自分のワークスペースにプルしてマージし、機能ブランチが最新になるようにします。

1. これは良い方法ですか？
2. これらのブランチは（ローカルクローンではなく）マスターリポジトリに存在する必要がありますか？つまり、すべての開発者がGitHub / Bitbucketのマスターリポジトリにコミット権限を与えて、新しいブランチを作成できるようにする必要がありますか？または、これはローカルで行われますか？
3. 最後に、記事が提示するモデルは、ブランチがと同期していない場合、CIを破壊する必要がありorigin/masterます。ナイトリービルドを実行したいので、開発者は仕事を離れる前にプルしてマージし、各機能ブランチでもCIを実行する必要がありますか？

まず、機能ブランチ（機能で行われた作業を分離するため）とCI（統合の問題がコミットされるとすぐに発見するため）の使用は、少し対立しています。

私の意見では、機能ブランチでCIを実行するのは時間の無駄です。機能ブランチが頻繁に行き来するため、CIツールを何度も再構成する必要があります。そして、CIシステムが検出する問題を回避するためにチェックインを調整する1つまたは2つのソースからのみ更新を取得する可能性が最も高いブランチの場合。
したがって、マスターリポジトリサーバーで機能ブランチを使用しても意味がありません。

質問1と3に関しては、機能ブランチをマージするときにメイン開発ブランチのビルドが壊れないようにするのは開発者の責任です。彼らがそれを行う方法は彼らの問題ですが、2つの可能な方法があります：

• メイン開発ブランチに加えられた変更を定期的に（たとえば毎日）機能ブランチにプルします。
• 機能が完了したら、メイン開発ブランチを機能ブランチにマージし、マージ結果をメイン開発ブランチにプッシュします。

どちらの場合でも、明らかな統合の問題（たとえば、名前が変更されたクラス/ファイル）が最初に検出され、機能ブランチで修正されます。より微妙な問題は、ナイトリービルドが実行されたときにのみ発生する可能性が高く、そこで修正する必要があります。

1）に対応して

動作する方法はすべて良い方法です。ただし、継続的統合の前提は、継続的に統合することです。考えは、できるだけ早くだけでなく、開発フィードバックサイクル内で統合バグをキャッチすることです。つまり、テスト中のコードのすべての詳細は、変更を行う開発者の短期記憶内にあります。これは、通常の日常的な状況では、コミットごとに機能ブランチ間で作業を統合する必要があることを意味します-15分程度に1回など。繰り返しますが、継続的統合の主な目的は、すべての詳細が変更を行っている開発者の短期記憶にある間に統合バグを公開することです。

2）

ほとんどの場合、ブランチはリポジトリのクローンを作成することでMercurialで作成されるため、すべての開発者にマスターリポジトリへのコミット権限を付与する必要はありません。ただし、テストをローカルで実行することは常に実行可能であるとは限らないため、開発者が継続的インテグレーションサーバーでクローンリポジトリを作成できるようにすることをお勧めします。（かつて私は、ユニットテストが128コアクラスターで実行するのに8時間かかったCIシステムを持っていました）-言うまでもなく、開発者はテストをローカルで実行できませんでした。

3）

計算リソースがある場合は、はい、特に仕事を辞める前に、開発者は常にメインの開発ラインを完全に最新にして、すべての開発ラインで夜間テストを実行する必要があります（ほとんどのCIシステムこれを簡単にしないでください）。

方法は次のとおりです。機能の分岐。

1. 新しいタスク（バグ修正、機能など）の場合、新しいブランチを開始します（例：bugfix-ticket123-the_thingie_breaks）
2. 作業中、デフォルト（またはgitのmaster）を継続的に更新して機能ブランチにマージします。これにより、デフォルトのブランチで作業しなくてもブランチを更新できます
3. あなたの機能は準備ができているし、あなたの場合はユニットテストに合格し、その後、より多くの、あなたの枝を閉じてマージすることなく、それを押したら、あなたのブランチにデフォルトを引き、マージ、あなたのインテグレータは、新しいヘッドに気づくでしょうし、それが閉じられたブランチであることを、彼/彼女はそう統合の世話をします。積分器がない場合は、デフォルトに切り替えて機能ブランチをdefaultにマージします。

ここで重要なことは、機能ブランチをマージすると、デフォルトブランチで競合が0になり、すべてのテストが成功することです。

この単純なワークフローを使用すると、常に初期状態の安定したデフォルトブランチが作成され、リリースブランチでも同じようになりますが、デフォルトから統合されます。修正プログラムをリリースブランチに直接統合する必要がある場合は、デフォルトブランチをスキップすることでこれを実行できますが、ターゲットブランチから更新されたばかりで競合のないユニットのみを選択し、ユニットテストに合格します。