1

私は、(私たちにとって) 最も効率的な方法で git を使用する方法を理解しようとしているプロジェクトに取り組んでおり、master ブランチと並んで、2 つのサブチームが作業する 2 つのブランチを作成することにしました。

両方のブランチに入る必要がある一般的なものであり、他のブランチの両方でそれらの変更が必要な場合は、master にコミットすることがあります。

  1. それは他の 2 つのブランチへのマージまたはリベースである必要がありますか?

  2. これは常軌を逸したワークフローでしょうか? もしそうなら、提案をお願いします！

4

3 に答える 3

4

2 つのチームに 2 つのブランチを作成する意味がわかりません。作業は、誰が作業するかではなく、その性質に応じて分離する必要があります。

これは私が提案するものです：

  • フィーチャーブランチを使用する: 小さなコミット (タイプミスなど) を除いて、ほとんどの作業はこれらのトピック ブランチで行う必要があります。
    処理する必要がある機能、バグ修正、またはチケットがある場合: ブランチfeat-somethingを作成し、そこで作業します。
  • devまたはrelease-X ( Xはリリース番号) ブランチを使用する:機能のブランチ作業が完了し、テストされ、機能したら、それをdevにリベースします。
  • masterでコミットしないでください。このブランチは、主任開発者、CTO などによってのみリベースされるべきです。必要に応じて、 devの作業をmasterにリベースします。

これは（基本的に）非常に大きなプロジェクトに取り組む方法です。プロジェクトが大きくない場合は、 devブランチが なくても作業できます。

非常によくできたワークフローを示すこの有名な記事をチェックしてください: A success Git branching model .

于 2012-05-15T12:13:17.323 に答える
1

これらが共通のものを共有する 2 つの別々のプロジェクトであるかどうかによって異なります。もしそうなら、別のライブラリを作成し、サブモジュールを使用してください - すべてを1つのレポに詰め込むのではありません。

それ以外の場合は、説明されているアプローチに反対することをお勧めします。これらの 2 つのブランチが分岐しすぎて、それらをマージすることがほとんど不可能になる可能性があります。分散システムであるためgit、すべての主要な開発をマスターで行い、実装された機能ごとに必要に応じてブランチを作成し、頻繁にマージします。タグ付けを使用して、重要な開発マイルストーンをマークします。

于 2012-05-15T10:06:47.213 に答える
1

反転:

2) いいえ、非常識なワークフローではありません。サブチームのメンバーは、おそらく独自のリポジトリとブランチを持っています。サブチームが安定した製品を手に入れると、それをメイン リポジトリのブランチにプッシュします。インテグレーション リードは、メイン リポジトリのサブ チームのブランチにあるものを取得し、必要に応じてマスターにマージ/リベースします (共有するものがあるとします)。

1) したがって、サブチーム A と B の両方が Tag-M1 でマスターから分岐し、サブチーム A の作業が Tag-M2 でマスターに戻ったとします。一方、サブチーム B は Tag-B2 に移行しました。ブランチ B にリベースまたはマージする必要があります。Tag-M2 から branch-B をリベースするのは避けたいと思います。サブチーム B のメンバーはブランチ B からプルしています。リベースすると、ブランチ B の履歴が変更され、サブチーム B のプルが複雑になります。

メイン リポジトリから更新する場合、サブチームは「git pull --rebase」を好む場合があることに注意してください。

于 2012-05-16T02:35:05.870 に答える