0

ここで説明したものに近い git ワークフローがあります成功した Git 分岐モデル

リリース ブランチとホットフィックス ブランチは無視しましょう。これらはこの問題に関連していないためです。現在、3 つのブランチがあります。

  • 主人
  • 発展させる
  • 特徴

現在、私はチーム X に所属しており、 という機能ブランチの作業を開始していますfeature/A。一方、チーム Y は他の機能ブランチに取り組んでいますfeature/B。チーム Y も終了feature/Cし、feature/D

ここで、私は奇妙な立場にいます。developチーム Y がそこに合併したので、私はブランチについていく必要があります。また、他のチーム メンバーが変更を行っているため、'feature/A' ブランチについていく必要があります。

変更に対応するための私の好みの方法 - rebase2 つの異なるブランチで常にリベースする必要があるため、多くの問題が発生します。

merge何とか機能していますが、もっと良い方法があるに違いないと思います。

そのような設定でどのように作業しますか? 人々がそれをどのように扱っているかを調べてみましたが、手がかりが見つかりません.

リンクの上記のワークフローも、そのような設定について明示的に何も述べていません。

ホスティングは github にあります。

4

2 に答える 2

2

通常、機能ブランチを開始するとすぐに、他の開発ラインから隔離されます。そのため、機能 A に取り組んでいるとき、デフォルトでは、developまたは他のブランチから変更を取り込まないでください (特に、他の機能ブランチからではありません)。開発developを続行する前に統合するためにいくつかの変更が必要な場合 (たとえば、依存するものが追加された場合)、developブランチから一度マージすることができます。しかし、一般的には、開発を分離したままにするために、それを回避しようとします。次に、完了したら、機能ブランチを にマージするdevelopと、機能ブランチを移動できます。

チームで作業する場合、リベースは決して良い考えではありません。何かを公開したら、二度とリベースしないでください。そうすることで、新しいハッシュを持つ新しいコミット オブジェクトが作成されるため、ブランチは他のすべての人の履歴を壊すさまざまなオブジェクトを指すことになります。たとえば、自分のコミットをクリーンアップするために、プッシュする前にローカルでリベースできます。でもそれ以上はやらないほうがいい。

それ以外はgit fetch、リモート リポジトリからすべての変更を取得するために使用できます。取得すると、リモート ブランチ ( 、 など) が更新されますorigin/master。origin/developしたがってorigin/feature/A、リモート リポジトリの現在の状態を参照したい場合はいつでも、リモート ブランチを使用できます。ただし、ローカル ブランチ ( master、develop) は自動的に更新されません。また、それらを使用している場合を除き、必ずしも更新する必要はありません。もしそうなら、それらをチェックアウトして、リモートブランチと早送りマージしてください。

于 2013-10-16T10:55:56.213 に答える
1

についていく必要はありませんdevelop- だけでfeature/A。チーム X のリーダー (別の帽子をかぶったあなたかもしれません) は、feature/Aが で最新であることを確認する必要がありdevelopます。このようにして、各ブランチは単一のブランチに対してリベースされます。

于 2013-10-16T10:41:17.813 に答える