複数のブランチマージとのマージの競合を避けるにはどうすればよいですか？

Question

私は中規模のチームでWebアプリケーションを開発しています。私たちは、Gitを使ってこのプロジェクトをバージョン管理/集合的にコーディングしています。私の同僚と自分の間で、私たちは困難な合併に直面していると思います。問題が発生する前にもっとうまくいくことができるかどうかを見たいと思います。

私たちは、主に開発ブランチでのGitで作業している：

D-E-F-G 

同僚は大きな変化で動作するようにブランチを作成しました：

 A 
    /
D-E-F-G 

は、その後、私がダウンしてその枝を引っ張って、その中にいくつかのバグが修正され、それを再びマージしようとしています。その間、私の同僚は別の機能の新しいブランチを開始しました：

今、私の同僚の新しいブランチのスタイルを使用する新しい機能を作成する必要がありますが、彼の新しいブランチは開発に併合する前にもっと多くの作業を必要とするので、ブランチからブランチに分岐します彼のスタイルを利用し、彼のものは後ろにマージされます一貫した外観があります。しかし、私たちは本当にまた、彼は彼の他のブランチで開発されたスタイルのいくつかを必要とする

 A-B-C-D 
    /
D-E-F-G-H-I-J 
     \ 
     A-B-C.. 
      \ 
      A 

を、私は開発リベースと思っています

 branch 1: A-B-C-D 
      /  \ 
develop: D-E-F-G-H-I-J.. 
       \  \ 
     branch 2: A-B-C..\ 
         \ \ 
       branch 3: A-B.. 

このようにして、私が作業する必要がある私の枝は、次のようになります。私は彼の枝の両方から必要としていますが、紛争を減らすために開発からリベースされています。私にとって心配しているのは、支店2を統合して開発するときに、多くの問題に遭遇するかもしれないということです。彼には多くの葛藤がありますか？私たちはもっと良いことがありますか？この回答のために

Answer 1

私はあなたの説明から二つのことを仮定します：

• developはコミットバグフィックスを受信し、展開（または解放）することができ、すぐに配備ブランチでいつでも（あなたドン場合これをしないで、そうすることを強くお勧めします：P）。
• 機能を開発する開発者は2人だけです。したがって、developブランチに重要な機能はありません。だから、

、私はあなたが日常的にdevelopでリベースされfeature-integrationと呼ばれるブランチを作成することを示唆している（またはあなたがdevelopブランチの変更を持っている場合）。そして、同僚が仕事の大部分を占めるときには、自分のコードをfeature-integrationブランチにマージして、開発ブランチfeature-integrationを作業ブランチに使用することができます。あなたと（あなたの同僚も）あなたのコードを更新して、開発中にいくつかの最終的な矛盾を解決するために、普通の（私は毎日または少なくとも週に1回提案します）feature-integrationで作業ブランチコードを再構築する必要があります。あなたがdevelopにそれをマージすることを決定したときに痛いマージがあります。

Answer 2

あなたは、マージすることで、あなたが望む変更を加え、あなたが望まない変更を導入するという問題にぶつかりつつあります。

あなたの機能を小さくします。

共通の点から機能を開始してください。最初はどれが不快であっても機能します。

rerereを使用すると、簡単に再確認できます。

これは私の枝あたりの機能ポストに要約される：

http://dymitruk.com/blog/2012/02/05/branch-per-feature/