2

ソース管理を使用する場合、私が慣れ親しんでいる方法は、トランクで開発し、QA に移行する直前にトランクを分岐することです。

私は部門の他の人々と話していましたが、開発サイクルの最初に新しいブランチを作成し、そのブランチで開発作業を行い、その後、別の作業方法について熱心な意見があるようです。最後にトランクにマージします。このアプローチのアイデアは、トランクを手付かずの状態に保つことです。

私は、後者のアプローチが「標準的な」アプローチであるという 1 人の支持者の主張に非常に懐疑的ですが (そうでないと言われてうれしいです)、それがかなり一般的であると聞いても驚かないでしょう。これにはいくつかの利点 (どの機能または一連の機能をデプロイするかを簡単に選択できる) も想像できますが、いくつかの欠点 (すべてのブランチをトランクにマージする必要があるため、マージの問題が発生する可能性があります) も想像できます。

その後の調査を行い、これを見つけました：http://www.lostechies.com/blogs/derickbailey/archive/2009/07/15/branch-per-feature-source-control-introduction.aspx

これらのアプローチの相対的な長所と短所、および人々が使用している可能性のある他のアプローチについて、人々の感覚を聞いてみたいと思います.

4

3 に答える 3

2

1つのチームが同じ作業を行っているので、トランクで作業し、リリース前にブランチを作成するのは非常に優れたアプローチです。マージ地獄を最小限に抑え、パッチを適用する必要がある場合、または何らかの理由で戻る必要がある場合は、リリースごとに個別のブランチがあります。

しかし、別々のことをしている複数のチームと一緒に作業する場合、それらはトランク内で最も確実に衝突するため、これは機能しません。私はこれについてあまり経験がないので、それに関するいくつかのアイデアを楽しみにしています。1つのアプローチは、おそらく各チームに1つずつ、複数のブランチを用意し、トランク内のリリースに入るブランチをマージすることです。（私は欲求不満を想像することしかできません）:)

于 2009-08-26T06:56:24.807 に答える
2

私はトランクをきれいに保つのが好きです。これにより、いつでも動作するバージョンをコンパイルし、修正、ベータ版をリリースし、デモバージョンを作成することができます...

変更は別々のブランチで行われます。これにより、トレーサビリティが向上し、ブランチのソース管理を利用して、暫定バージョンをチェックインできます。理想的な世界では、マージの問題は[自動]テストでカバーされます。変更をトランクに統合するのが早ければ早いほどよいでしょう。

テストされていないコードをトランクに配置しないでください。最終的に誰かの速度が低下します。

于 2009-08-26T06:57:34.210 に答える
2

これは、この前の SO 項目と非常によく似た質問です。

Subversion - 誰かがトランクから開発する必要がありますか?

まったく同じではありませんが、応答の多くの概念は同じです。

私の個人的な意見？トランクは積極的な開発用です。「初期状態」を維持したい古いバージョンの開発ラインは、バージョン ブランチ (およびリリースのタグ) に保持する必要があります。トランクでの開発が活発に行われている場合でも、「トランクは常にコンパイルする必要がある」という格言を維持しようとすることができます。

于 2009-08-26T06:45:13.190 に答える