ブランチからブランチを作成する機能を拒否して、フックを作成することは可能ですか?
トランクからのみ許可しますか?
もしそうなら、それはどのようになりますか?
2 に答える
はい、pre-commit フックで可能ですが、後悔することになります。ブランチからブランチを作成する場合があります。そのブランチの長期的な修正があり、機能ブランチを作成したいとします。この場合、ブランチからブランチを作成する必要があります。
あなたの質問の核心に行きましょう: 開発はどのように行っていますか? 非常に多くのサイト (ゼロ以上) が初期のトランク方法論を使用しています。アイデアは、開発がトランクで行われないということです。代わりに、ブランチを作成し、そのブランチですべての作業を行い、そのブランチをトランクにマージしてから、次のリリース用に新しいブランチを作成します。最大の問題の 1 つは、開発者がトランクにマージするのを忘れて、トランクから新しいブランチを作成することです。現在のブランチから次のブランチを作成する方がはるかに簡単です。
手付かずのトランクは良い方法論ではありません。複雑で、リリースが近づいたときに発生する並行開発を行うのは困難です (特に、ブランチからブランチを作成したくないため)。そして、それはあなたに何も買いません。トランクは最後のリリースであると思われますが、タグから同じ情報を取得できます。
さらに悪いことに、トランクは最後のリリース (オンになっている) 以外は何も教えてくれませんHEAD
。トランクの以前のリリース? わかりません。前回のリリースで変更されたファイルと変更されていないファイルがあります。そのため、タグを使用します。また、トランクから履歴を取得することもできません。その変更を行ったのは誰ですか? 変更の作成者は表示されません。代わりに、ブランチをトランクにマージした人が表示されます。
元のトランク方法論を使用する場合は、停止してください。
手付かずのトランクの方法論を行っていない場合は、それを聞いてうれしいです. 上記の暴言は無視してください。
本当にやりたいことは、ブランチのブランチを禁止することではなく、ブランチを作成できるユーザーと、このブランチを作成できる場所を制限することです。たとえば、リリース ブランチは CM のみが行う必要があります。フィーチャー ブランチは、チーム リーダーによって作成される場合があります。命名規則を使用して、これらの異なるブランチ タイプを区別したり、特別なディレクトリに配置したりすることもできます。(branches/releases
対 'branches/other` のように)。
この取り組みに役立つpre-commit フックがあります。誰がブランチを作成できるか、どこで何をブランチと呼べるかを制限できます。