7

私は自分の高官にgitを売ろうとしているところです。とにかく、彼らは私たちがそれについて話すのを聞いています。よくわからないことが1つあります。人々がこれにどのように対処しているかを確認したいと思います。基本的に、私の質問は、ブランチのペアが離れるほど、それらをマージするのが難しくなるという基本的な理解から来ています。

この非常に単純なワークフローを提案することを検討しています。マスター(リリース)ブランチ、開発ブランチ、およびその中のトピックブランチがあるとします。さまざまな開発者が別々のトピックブランチに取り組んでおり、コードが機能していると感じる頻度で、それらのトピックブランチを中央リポジトリにプルおよびプッシュします。定期的に、開発者からそうするように求められた場合、メンテナ(私たちの組織では「テクニカルリード」というタイトルを持っています)は、機能ブランチから開発ブランチにマージされ、ステージングサーバーに配置されてテストされます。テストが完了し、マスターとマージされて本番環境にプッシュされます。

これが私の質問です。開発者はトピックブランチを定期的にマージする必要がありますか?そうすることで、それらがすべてdevにかなりきれいにマージされます(または、少なくとも、手に負えなくなる前に競合を早期にキャッチします)。私のマネージャーがそれについて嫌いになることを私が知っている唯一のことは、それはプロジェクトにコードを提供するために働くのではなく、彼らが彼らのツールをなだめるために彼らがしなければならない仕事です。考え?

4

1 に答える 1

3

私たちは皆、対立が起こることを知っています。問題は本当にです:誰が紛争を解決すべきですか?

この競合を引き起こした変更に最も近い人がそれを修正する人である場合、それは有益です。メンテナにこれ(または他の開発者)を処理させると、その人はコードが何であるかを知らない可能性があります。そうです、開発者はおそらくマージの競合を解決する責任があるはずです。それはトレードオフです。

あなたの問題はワークフローに関連しており、上司は技術リーダーが自分の時間を使って対立を解決していることを好まないかもしれません。そうでなければ、このモデルはまったく悪いモデルではありません。テクニカルリードが持つこの役割は「インテグレーター」と呼ばれることが多く、競合の解決を伴うことが多く、インテグレーターはコードについて知る必要があり、開発者と多くのコミュニケーションをとる必要があります(gitには、このシナリオを簡素化できる他のツールもあります) )。

あなたができることは、開発者がサーバーからトピックブランチをプッシュおよびプルしないようにすることです。代わりに、トピックブランチをローカルに保持し、サーバー上でマスターと開発のみを行います。代わりに、開発からプルし、それらをマージし、ローカルで競合を解決し、開発をプッシュする前にローカルでテストする場合。そうすれば、開発者は代わりに開発を推進でき、技術リーダーは開発のテストに集中でき、パフォーマンステストなどの他のタイプのテストを実行できます。

ただし、それでもインテグレーターの役割が必要な場合は、gitrerereというツールがあります。これにより、インテグレーターは定期的にブランチをマージし、競合を解決し、リセットしてマージを元に戻すことができ、gitは競合がどのように解決されたかを自動的に記録します。これは、競合を解決する作業を最小限に抑えるための非常に優れた方法です。gitフックを使用してこれを自動化することもできます。たとえば、スクリプトを使用してマージを実行し、競合が発生した場合はインテグレーターに通知するだけです。

いくつかの読書:

http://www.kernel.org/pub/software/scm/git/docs/git-rerere.html

http://gitfu.wordpress.com/2008/04/20/git-rerere-rereremember-what-you-did-last-time/

乾杯

于 2011-05-11T07:39:35.873 に答える