分岐は継続的な統合を壊しますか？
この記事 成功したGit分岐モデル は、経験豊富なDVCSユーザーの間で非常によく知られていると思います。
私は主にhgを使用しますが、この議論はどのDVCSでも問題ないと主張します。
現在のワークフローは、各開発者がマスターリポジトリを複製することです。独自のローカルリポジトリにコードを記述し、テストを実行し、すべてがうまくいけばマスターにプッシュします。
したがって、JenkinsのようなCIサーバーをセットアップし、将来のプロビジョニングシステム（シェフ、パペット、ansibleなど）でワークフローを改善したいと考えています。
実数部
さて、上記のモデルはうまくいきますが、ブランチはCIを壊す可能性があります。 CIとマージをスムーズにするために、機能ブランチはOriginと同期する必要があります（記事によると、developmentブランチになります）。
アリスとボブが2つの機能に取り組んでいるとしましょう。しかし、アリスは次の日に行われます。ボブの機能には1週間かかります。ボブが完了するまでに、彼の変更は古くなっています（おそらく、アリスはいくつかのクラスをリファクタリング/名前変更します）。
1つの解決策は、毎朝、開発者がmaster/Originをプルして、変更がないかどうかを確認することです。アリスがコミットした場合、ボブは自分のワークスペースにプルしてマージし、彼の機能ブランチを最新にする必要があります。
- これは良い方法ですか？
- これらのブランチは（ローカルクローンではなく）マスターリポジトリに存在する必要がありますか？すべての開発者が新しいブランチを作成できるように、GitHub/Bitbucketのマスターリポジトリにコミット権限を持っている必要がありますか？またはこれはローカルで行われますか？
- 最後に、ブランチが
Origin/masterと同期していない場合、記事で提示されているモデルはCIを壊すはずです。私たちは夜間のビルドを行いたいので、開発者が仕事を辞める前にプルしてマージし、各機能ブランチでもCIを実行する必要がありますか？
まず、機能ブランチ（機能で行われた作業を分離するため）とCI（統合の問題がコミットされるとすぐにそれを見つけるため）の使用は少し矛盾しています。
私の意見では、機能ブランチでCIを実行することは時間の無駄です。機能ブランチが頻繁に行き来するため、CIツールを何度も再構成する必要があります。そして、CIシステムが検出する問題を回避するためにチェックインを調整する1つまたは2つのソースからのみ更新を取得する可能性が最も高いブランチの場合。
したがって、マスターリポジトリサーバーで機能ブランチを作成しても意味がありません。
質問1と3に関しては、メインの開発ブランチでのビルドが機能ブランチをマージするときに中断しないことを保証するのは、開発者の責任です。それがどのように行われるかが問題ですが、考えられる2つの方法は次のとおりです。
- メインの開発ブランチに加えられた変更を定期的に（たとえば、毎日）機能ブランチにプルします
- 機能が完了したら、メイン開発ブランチを機能ブランチにマージし、マージ結果をメイン開発ブランチにプッシュします。
どちらの場合でも、明らかな統合の問題（例：名前が変更されたクラス/ファイル）が最初に発見され、機能ブランチで修正されます。より微妙な問題は、おそらくナイトリービルドの実行時にのみ検出され、そこで修正する必要があります。
1）への対応
機能する方法はどれも良い方法です。 ただし：継続的統合の前提は、統合継続的です。統合のバグをできるだけ早期に発見するだけでなく、開発フィードバックサイクル内で、つまり、テスト中のコードのすべての詳細が、変更を加えた開発者の短期記憶の範囲内にあることを発見するという考え方です。これは、通常の日常的な状況下では、コミットごとに機能ブランチ全体で作業を統合する必要があることを意味します。おそらく15分ごとに1回程度です。繰り返します：継続的インテグレーションの主な目的は、すべての詳細が変更を行った開発者の短期記憶にある間にインテグレーションのバグを公開することです。
2）
ほとんどの場合、ブランチはリポジトリを複製することによってMercurialで作成されるため、すべての開発者にマスターリポジトリへのコミット権限を与える必要はありません。ただし、ローカルでテストを実行することが常に可能であるとは限らないため、継続的インテグレーションサーバー上に複製されたリポジトリを作成する機能を開発者に提供することをお勧めします。 （私はかつて、ユニットテストを128コアクラスターで実行するのに8時間かかったCIシステムを持っていました）-言うまでもなく、開発者はローカルでテストを実行できませんでした。
3）
そのための計算リソースがある場合、はい、開発者は常に、特に仕事を辞める前に、開発の主要ラインを完全に最新にしておく必要があり、開発のすべてのラインで夜間テストを実行する必要があります（ほとんどのCIシステムこれを簡単にしないでください）。
これを行う方法は次のとおりです。機能の分岐。
- 新しいタスクの場合（バグ修正、機能など）新しいブランチを開始（たとえば、bugfix-ticket123-the_thingie_breaks）
- 作業中、継続的に更新してデフォルトをマージ（またはgitのマスター）機能ブランチに。これにより、デフォルトのブランチで作業しなくてもブランチを更新できます
- 機能の準備が整い、単体テストに合格、次にデフォルトをもう一度プルしてブランチにマージし、ブランチを閉じてマージせずにプッシュするの場合、インテグレーターは新しいヘッドであり、それが閉じたブランチであるため、彼/彼女はそれを統合するのを世話します。 インテグレーターがない場合は、デフォルトに切り替えて、機能ブランチをデフォルトにマージします。
ここで重要なことは、機能ブランチをマージすると、デフォルトブランチにconflictsが含まれ、すべてのテストがdo passになることです。
この単純なワークフローを使用すると、常に手付かずの安定したデフォルトブランチが作成されますリリースブランチでも同じようになりますが、デフォルトから統合します。修正プログラムをリリースブランチに直接統合する必要がある場合でも、デフォルトのブランチをスキップしてこれを行うことができますが、ターゲットブランチから更新されただけで、競合のないブランチのみを選択し、それらのユニットテストに合格します。