DVCSで間違ったブランチにコミットする開発者の停止

問題

私は約10人の開発者がいるソフトウェアプロジェクトに参加しており、Mercurialを介してソースコードを共有しています。リリースごとに開発ブランチと本番ブランチがあります。プロジェクトの過程で、1つのブランチ（v1など）からのソースコードが、ソフトウェアの以前のリリース（v2）のパッチブランチとメンテナンスブランチに入りました。

これにより、間違ったコミットのバックアウトに時間を費やしたり、コードが間違ったブランチに入ったことに気付かなかった場合、間違った（おそらくQAdでない）コードが間違ったブランチに到達してデプロイされます。

ブランチとマージの設計/方法

               v1-test   v1-patch1   v1-patch2
               ^---------^-----------^                v1-prod
              /         / \           \
-----------------------/   \           \              v1-dev
              \             \           \
               --------------------------\            v2-dev
                             \       \    \ 
                              ^-------^-------------  v2-prod
                              v2-test v2-patch1      

したがって、準備ができたと判断されるまでリリース開発ブランチに取り組み、すべてのリリースとメンテナンスが行われる単一のテスト/ UAT /生産ブランチに分岐します。タグは、このブランチのリリースをビルドするために使用されます。v1のテスト中に、v2のブランチが作成され、開発者は新しい機能の開発を開始します。

起こりがちなのは、開発者がv2-devブランチの作業をv1-devまたはv1-prodにコミットすることです。さらに悪いことに、v2-devをv1-prodにマージします（または同様のミス）。

ほとんどの開発者は-prodブランチにアクセスしないように指示しますが、コードはまだ潜入しています。

v2は開発を開始したばかりですが、v1には問題を修正するための非常に大きなパッチがまだ残っている可能性があることに注意してください。つまり、v1は単に奇妙な小さなパッチを取得しているだけではありません。

これまでに試したこと

• ゲートキーパーを備えた、独立した-prodブランチがあります。-prodブランチはその名前を通じて警告を発するはずであり、ほとんどの開発者はそのブランチにいる必要はありません。これは実際に問題を軽減していません。
• 開発者の間でこの問題に対する意識を高め、彼らをより警戒させようとしました。繰り返しますが、これはあまり成功していません。

開発者が間違ったブランチにコミットする場合に考えられる考えられる理由

• ブランチデザインが複雑すぎる
• 複数のブランチを並行して積極的に開発する。（プロジェクトは、雪崩モデルを使用するという症状を示します。）
• 開発者はDVCSを十分に理解していない

ある程度関連性のある私が読んだ質問

私は間違ったブランチにコミットしないことについてこの質問を読みました。視覚的なキューに関する答えは役に立つかもしれません。しかし、私たちが経験している問題は、より根本的な問題の症状ではないと完全に確信しているわけではありません。

視覚的な手がかりを使って、それらをコマンドラインに簡単に組み込むことができますが、チームの約半数が日食を使用していますが、視覚的な手がかりを組み込む方法はわかりません。

質問

ソフトウェア、プロジェクト管理、またはガバナンスの形で、間違ったブランチへのコミットを減らして（理想的には停止して）時間を浪費したり、デプロイされたコードを汚したりするために、どのような方法を使用できますか？

上記のように貢献していると思われる理由に関する特定のコメントをいただければ幸いですが、これは返信を制限するものではありません。

問題は、プロセスの途中でブランチの意味を変更していることです。

最初は、v1 devブランチは開発用です。すべての新機能がそこにあります。将来のある時点で、ブランチのメンテナンスブランチになりv1 releaseます。これが問題の核心です。

開発者がだらしないということではなく、ブランチの権限と役割がだらしないで変更される可能性があるということではありません。

必要なのは、各ブランチの役割を確立し、その役割を維持することです。ロールが変更された場合、分岐します。

例えば：

 developer
  commits    |   |  |   |    |     |   |     |
             v   v  v   v    v     v   v     v
 dev  +--+---------------------+------------------->
         |           ^    ^    |           ^    ^
         |           |    |    |           |    |
 v1      +----+------+----+    |           |    |
           prod  patches       |           |    |
                               |           |    |
                               |           |    |
 v2                            +-----+-----+----+
                                  prod  patches

このモデルでは、開発者は常に開発にコミットします。パッチを作成している場合は、そのリリースのブランチにパッチをチェックインします（または、さらに良いことに、パッチのリリースブランチをブランチし、それをリリースブランチにマージします）。

読むべき記事の1つは（おそらく「控えめ」に控えめに言っても）、Stephen VanceによるAdvanced SCM Branching Strategiesです。

^{このペーパーでは、まず一般的な意味で分岐を定義します。次に、明確なものから始めて、大規模な開発作業に適したいくつかの分岐に移動するための、分岐のさまざまな戦略について説明します。途中で、各戦略の長所と短所について説明し、それらを使用して、より複雑な戦略を構成する変更を動機付けます...}

この記事では、ブランチが持つ可能性のある5つの役割を特定します。ブランチが2つのロールを満たし、ロールポリシーがブランチの途中で変更されない限り、ロールは必ずしも新しいブランチを必要としない場合があります（「非互換ポリシーのブランチ」という記述が表示される場合があります）。

これらの役割は次のとおりです。

1. メインライン。ここから分岐が作成されます。常にメインラインから分岐すると、2つの分岐は分岐ごとに分岐しない共通の祖先を持つため、マージが容易になります。
2. 開発。開発者がコードをチェックインする場所です。高リスクの変更を日常的でありふれたものから分離するために、複数の開発ブランチを持つことができます。
3. メンテナンス。既存の実稼働環境のバグ修正。
4. 累積。2つのブランチをマージする場合、メインラインが不安定になるリスクを避けたい場合があります。したがって、メインラインを分岐し、ブランチをアキュムレータにマージし、物事が決まったらメインラインにマージします。
5. パッケージング。リリースのパッケージ化は、パッケージ化ブランチで行われます。多くの場合、これがリリースとなり、リリース作業を開発から分離するのに役立ちます。実行時間の長いリリースビルドを中断する望ましくないコミットを処理する方法を参照してください。パッケージが開発と競合する場所の例。

あなたの例では、カスケードメインライン（これは問題です-それはマージをより困難にします-v1の修正をv2とv3にマージしたい場合はどうなりますか？）、メンテナンスブランチになるdevブランチ（ポリシーの変更、これは問題です）。

わかりました、それは素晴らしいことですが、これは集中型VCSであるperforceのために書かれました-DVCSを使用しています。

git-flowモデルを見て、それがどのように適用されるかを見てみましょう。

マスターブランチ（青）はリリースブランチです-タグ付け用です。メインラインではありません。メインラインは実際には開発ブランチ（黄色）です。リリースブランチ（緑）はパッケージングの役割です。メインラインで低リスク開発が行われ、機能ブランチで高リスク開発が行われます（ピンク）。このモデルでは、蓄積は開発ブランチで行われます。メンテナンスは赤の「ホットフィックス」と見なされます。

役割ポリシーは完全には一致しませんが（各製品のライフサイクルはわずかに異なります）、一致しています。

これを行うと、分岐ポリシーが簡素化され、関係者全員が簡単になります。

ゲートキーパーで別の-prodブランチを使用してみましたが、実際に本番ビルドを行うために1つのリポジトリが使用されているように聞こえます。本番ビルドが本番リポジトリからのみ行われ、ゲートキーパーのみが書き込み可能な場合、開発者はそこにプッシュできません。これにより、ゲートキーパーに負荷がかかります。ゲートキーパーは、レビュー後にのみ本番リポジトリにプッシュします。もちろん、人々は必要に応じて生産レポからプルすることができます。

人々が経験を積むとき、彼らはゲートキーパーの役割を介してローテーションし、より深い理解を得るか、欠けているように見えるケアをするべきです。

そして、一般的なルールとして、OccamのRazorを適用します。レポジトリ構造全体をできるだけシンプルにして、仕事をする必要があります。

ショーンのコメントも参照してください。

開発者が単純にDVCSを十分に取得できない可能性がありますが、単純にあまりにも多くのことを行っている可能性がはるかに高く、開発者は彼らが行っていることを時々追跡できません。彼らは、自分が働いているはずのブランチを忘れてしまい、その変更は間違った場所で終わることになります。

皆さんがこれらすべてのブランチで定期的に作業しているという事実に問題があることをお勧めします。

@ andy256がprodの個別のリポジトリを提案することは確かに役立ちますが、作業を異なる方法で分割することを検討するか、特定の週に1人の開発者が複数のブランチで作業しないように物事を調整する必要があります。

これは、あなたが私の主要なバグの1つを特定したようです。ソース管理ツールの大部分は、まさにソース管理ツールです。これにより、多くの開発者が同じソースディレクトリで作業し、変更を加えて競合を処理できます。途中でいくつかのラフなエッジがありましたが、cvs、subversion、git、mercuralなどがすべてこれを実現します。

次に、リリースのためにコードを安定させる必要があるときに次のステップがあり、分岐を導入します。これは、ツールが開発者を失敗させ始めるところです。これらのツールは、ブランチを作成し、ブランチ後にブランチで発生した一連の変更を特定することもできますが、現在直面している問題ではありません。

ツールは、どの変更を他のブランチにコピーする必要があるか、およびそれをいつ発生させる必要があるかを選択するのが本当に苦手です。Git-flowは、ブランチがマージされると、そのすべての変更がマージされるブランチ戦略を作成することでこれを解決しようとします。その後、プログラマは、ブランチをマージするタイミングとブランチについて賢明な選択を行う必要があります。

すべての開発者が単一のリリーススレッドを持つ1つのプロジェクトで作業している単一のリポジトリで、git flowは問題を解決しますが、多くの企業にとって人生はそれほど単純ではありません。

複雑な環境では、ソリューション全体のさまざまな側面を担当する複数のチームが存在し、他のチームに内部リリースを実行します。git-flowでは、この種の問題を解決することはできません。

私がこの作品を見てきた唯一の方法は、各チームがリリースを定義し、依存関係が変更されるタイミングを制御する責任がある場合です。チームAがリリース1.3をリリースしたからといって、チームBは、チームBが選択した場合にのみチームAの1.3リリースの使用を開始します。

実際には、開発者のチームが移動する必要がある変更のグループを定義し、変更を受け取る開発者が変更のグループを受け取るタイミングを定義します。

これを本当に提供する唯一のソース管理ツールはaccurevです。それでも、ほとんどの開発者は、GUIが混乱を招き、subversionのように動作しないため、それについて不平を言うでしょう...