git - ライブブランチ数の最適な範囲は?

Question

プロジェクトが次のようなものであるとしましょう:

• 1製品
• Y何年にもわたって構築された
• Mモジュールで構成される
• L[1..3]言語で書かれた
• 総開発者数でD開発

プロジェクトに含まれるライブ ブランチが多すぎる、または少なすぎるのはどの時点ですか?

難しい質問であることは承知しています。数値で回答するのはさらに難しいですが、定量化された回答を探しています。可能であれば、式を作成してください。

バックグラウンド

ブランチが少なすぎると、コードの準備ができなくなり、次の締め切りに間に合わない可能性があるため、開発者は大きな変更を加えません。同様に、プロダクト マネージャーは何かをリリースと名付けることに自信を持ちません。多くの場合、機能の凍結が確立され、新しいアイデアが遅れ、開発が遅くなります。

ブランチが多すぎると、開発者は、変更をどこに行けばよいのか、どこに伝播すべきなのか、どのブランチがどのトランクにマージされるのかがわからない。リファクタリングされたコードのマージは非常に難しく、品質が低下します。さらに、各開発者はいくつかの設定で変更をテストする必要があり、かなりの労力が無駄になり、開発が遅くなります。

ライブブランチ数の最適な範囲は?

Answer 1

RCS (svn または git) に含まれるブランチが多すぎると判断する経験則は何ですか?

どうですかrule of 3:

• 安定したコード用の 1 つのブランチ — メイン トランク。
• 不安定版用の 1 つのブランチ — 今後のリリース開発。
• メンテナンス用にもう 1 つ — 以前のリリースのバグ修正。

master多くの git ホスト プロジェクトは、メイン トランクvNext用と将来のリリース用の2 つのブランチのみを使用します。

機能を使用tagsして、開発のマイルストーンにラベルを付けます。

開発者がローカルで開発ブランチを作成し、実行しているタスクに応じてこれらのリモート ブランチにマージできるようにしてください。

意味のある名前と説明をローカル ブランチに追加するように開発者に依頼してください。それに応じてコミットにラベルを付けます。

Answer 2

この質問に対する答えは 1 つではありません。それは「組織とワークフローに適したもの」でしかありません。

IMHO、ブランチがその有用性を失ったら（たとえば、すべての変更がトランクにマージされます。または、放棄または終了した失敗した実験/研究プロジェクト）、削除する必要があります。必要に応じていつでも元に戻すことができ、物事を少し整理するのに役立ちます。

あなたの編集に基づいて:廃止された、または「死んでいる」ブランチがある場合、なぜそれらはまだ残っているのですか? 定義上、それらはもう使用されないため、削除してください。

Answer 3

複数のブランチを持つ git を使用している場合は、それらが死んでいても便利です。どの製品バージョンでバグが導入されたかを追跡でき (バージョンごとに二分)、多くの小さなチームの作業を整理できます。枯れた枝を見るだけで、一部のアイデアがうまくいかなかった理由がわかります。

重要なのは一貫性です。ワークフローに合わせてブランチをグループ化してみてください。たとえば、

• stable- CI は、これから本番環境および/またはステージングを構築します
• staging- これから CI ビルド ステージング
• feature/*- 機能のブランチ
• hotfix/*- ステージング/安定ブランチから開始、ホットフィックスに使用
• experimental/*- クリーンで保守可能なコードにならない可能性がある、または途中で放棄される可能性がある R&D 機能に使用される

ここでいくつかの基本的なヒント: http://nvie.com/posts/a-successful-git-branching-model/

また、チームが適切なブランチ構造をすぐに使い始められるようにしたい場合は、git フローを試してください: http://jeffkreftmeijer.com/2010/why-arent-you-using-git-flow/

他の同僚の悪いコードのリファクタリングについて。いくつかのrefactor/*ブランチを使用できるので、別のブランチでアトミックなマージ/リベースを行うことで何が壊れているかを簡単に確認できます。もちろん、テストを行うことは非常に便利ですが、シンプルgit bisectにしないと、誰がいつバグを導入したかがわかります (そして、バイセクトが使用するこのバグをチェックするテストを作成すると、追加する意味のあるテストが得られます)。あなたのテストスイート）。

肝心なのは、多くのブランチを持つことを恐れずに、それらを整理しておくことです。ほとんどの場合、マージは人々が言うほど複雑ではなく、いつでも元に戻すことができます (または、継続的デリバリー モデルを使用していない場合は、次のリリースまで延期します)。

編集:つまりsomething/*、共通のプレフィックスを持つ複数のブランチがあるsomething/ため、ディレクトリ構造を模倣しています。

EDIT2: 分岐とマージがそれほど安くない SVN ライクでは状況が異なります。注意して進んでください;）

EDIT3: モジュールごとに異なる (サブ) リポジトリを使用することを検討してください。開発を簡素化する可能性があります。モジュール開発者は、メイン アプリケーションの最新の安定バージョンのみに関心があり、ブランチ モデルは 1 つのモジュールのみを対象としています。

EDIT4: Q: 「ごちゃごちゃした分岐が許容されるしきい値と、それを超えると分岐を編成するほうがよいしきい値に、いくつかの数値または数式を配置することを検討できますか?」

もちろん！

式 (私の謙虚な意見では) は単純です。

• 必要な数の「ダーティ」ブランチをローカルに持つ (他の人や共有リポジトリにプッシュしないでください)
• 他の開発者にとって何らかの価値がない限り、ダーティ ブランチをプッシュしないようにしてください。それらがすでに共有リポジトリにある場合は、それらを保持して名前を変更します（legacy/*またはプレーンdirty/*が思い浮かびます）。

それらをファイル構造と考えてください。多くのレガシー ファイルが不要になる可能性がありますが、それらを整理して保管しておくと、アーカイブを作業セットから簡単に分離できます。

数字が好きなので、それらのブランチの実際のユースケースが必要になるでしょう

私が取り組んできた小規模から中規模の Symfony2 PHP プロジェクトの例を挙げましょう。

2 週間ごとにクライアント デモを行い、アジャイル (スクラム) 方式で 5 人の開発者によって積極的に開発されたプロジェクトが 6 ～ 9 か月進行している場合、ブランチが必要になる場合があります。

• ユーザー ストーリーごとに (緊密に統合されたユーザー ストーリーでは、これは悪い考えかもしれません)、合計約 50 のブランチ。それらを機能ブランチと考えてください。
• 開発者ごとに (開発者がしばらく何かに取り組む必要がある場合はオンデマンドで)、彼らは行き来しますが、通常、この種のプロジェクトでは開発者は 3 人未満です。それらの一部は、公開開発者ブランチをまったく使用せず、ダーティ ブランチを独自に保持しています。
• 実験的（モジュールで使用されるさまざまなアルゴリズムやライブラリなど、研究目的の無制限の数のブランチ）、覚えている限り約7つのブランチ
• スプリントごと (ユーザー ストーリーからマージされ、デモに役立ちます)、約 10 で、初期開発中のステージング/安定版です。なぜタグ付けしないのですか？タグも同様ですが、修正プログラムを適用しやすいため分岐します。
• 修正プログラム (通常は短命で、チェリー ピッキングを簡単にするために分離されています)、3 つのトップ ;)
• その他 (通常、進行中のシステム全体の機能および/または 2 ～ 3 人のチーム ブランチ)、約 10

ご覧のとおり、ここにも正確な数はありません。私はこの規模のプロジェクトをいくつか行ってきましたが、それらのほとんどには約 70 ～ 80 のブランチがありました (ユーザー ストーリーのブランチがない場合は 20 ～ 30)。それらが論理的でクリーンな方法で編成されている場合、コード リポジトリは簡単に参照できます。

git では、マージの代わりにリベースも検討して、マージ バブルが発生しないようにします (この記事http://stevenharman.net/git-pull-with-automatic-rebaseを参照してください)。

Answer 4

RCS (svn または git) に含まれるブランチが多すぎると判断する経験則は何ですか?

なし。そのような一般的なルールは存在せず、(まだローカルを定義できる場合) 最終的にはチームとワークフローに大きく依存します。

「タスクごとのブランチ」を使用すると、小規模および中規模のコードベース (チームの規模や使用言語の量に関係なく) に対しても、多くの短期間のブランチを作成できます。

コメントから移動:

開発者ごとに1 ～ N 個のクローズされていないタスクブランチ(N は多くの要因に依存します)

Answer 5

Git と SVN では、これを表示するさまざまな方法があります。しかし、最も重要なことは、何かが多すぎるとはどういう意味かということです。それは、パフォーマンス上の理由によるものなのか、整理上の理由によるものなのかということです。

だからgitパフォーマンス：

git では、ブランチは git リポジトリの一部であるオブジェクトへの参照にすぎません。したがって、この分岐オブジェクトには大きなオーバーヘッドはありません。(詳細については、http: //git-scm.com/book/en/Git-Branching-What-a-Branch-Isを参照してください) ブランチを破棄しても、リポジトリにはすべての git 履歴が残ります。それに到達する問題。一般に、ブランチ用の追加のストレージはありません。使い捨てブランチを使用している場合は削除しますが、コミットはまだ存在します。git の全体的なパフォーマンスはリポジトリのサイズによって遅くなりますが、ブランチは大きくするために作成されるのではなく、コミットは作成されます。オブジェクトを再パックまたは削除して、git リポジトリをクリーンアップおよび高速化できます。

だからSVNのパフォーマンス：

SVN では、ブランチは作業ツリーのコピーですが、これらのコピーは複製されたデータではありません。繰り返しますが、svn-copy が使用されている限り、それらは既存のツリーへの参照です。(詳細については、 http://svnbook.red-bean.com/en/1.1/ch04s02.html#svn-ch-4-sect-2.1を参照してください) SVN は大きなファイルとリポジトリを適切に処理しますが、やはり、レポはブランチの影響を大きく受けず、代わりに効率的で安価です。実際のところ、svnbook を引用します。

SVN と git の両方の構成:

上で述べたように、分岐は安価なので、頻繁に発生する可能性があります。使い捨ての分岐は削除する必要がありますが、歴史的な分岐は維持するのに安価です。基本的に、慣例としてブランチに名前を付ける簡単な方法が必要です: release_1、bugfix_200、temp_branch_for_fun - 英数字でリストするときに名前が自己組織化されるもの。SVN と git の両方でタグを使用するのも良いことです。人々はブランチの方が快適に感じる傾向がありますが、git ではそれらは実際には同じであり、SVN では特定の時点の参照に役立ちます。

ブランチが多すぎます。これはビジネス ロジックの決定です。私は、Work In Progress 用に多くの使い捨てブランチを用意し、リリース用には履歴ブランチのみを用意することを好みます。しかし、それは反復ワークフローでのみ有効です。最近、私は開発を継続的デリバリー ワークフローと分散型 git フォーク ネットワークに移行しています。その場合、開発者の git フォークにブランチがいくつあるかはまったく気にしません。代わりに、私のオリジンまたはメインライン リポジトリには、マスターとマスターの 1 つの永続的なブランチしかありません。優先度の高い重要な修正プログラムの使い捨てブランチ。

上で述べた方法論はうまく機能しています。今では、各開発者は、他の開発者に迷惑をかけずに、好きなだけ分岐して忘れることができるからです。同様に、私のマスターは枝が散らからないように保たれています。(これは反復アプローチでも機能し、リリース専用のブランチがあり、一時的または使い捨てのブランチはぶら下がっていません)。

誰もが満足しています。

Answer 6

git のブランチは使い捨てと見なされます。必要がなく、二度と使用しない場合は、ドロップします。ただし、私の場合、多くのブランチを管理していますが、そのうちの 1% しか使用されていません。残りをロックし、リリース バージョンに適切なタグが適用されていることを確認しました。

問題のすべてのブランチが一度にアクティブかどうかを定義する必要がある場合があります。100 個のブランチを持つことができますが、使用されているのは 1 つだけです。しかし、1 つのプロジェクトに 100 のアクティブなブランチがあるとしたら、それは多すぎると言えます。管理が悪いだけです。

この助けを願っています！

Answer 7

ブランチをアーカイブしたい場合、通常の解決策はそれらをアーカイブ リポジトリにプッシュしてから削除することだと思います。それらを取り戻したい場合は、どこを見ればよいかがわかります。