1

Adam Dymitruk(http://dymitruk.com/blog/2012/02/05/branch-per-feature/)で説明されているワークフローを実装しようとしています。

このアプローチで私が気に入っているのは、機能ブランチの独立性です。このブランチには、機能に関連するコードのみが存在します。スプリント中に、さまざまな機能ブランチに基づいてリリースブランチを自由に作成することができます。アダムはすでにいくつかの質問に答えていますが、私はいくつかのことに苦労しています。

私が見つけたところによると、release and Integration(dev)ブランチは長時間実行されており、必要に応じてリセットできますか?Devは、機能ブランチから統合ブランチに継続的にマージします。完成した機能はリリースブランチにマージされます。

  • リリースブランチと統合ブランチは共有(プッシュアップ)されているので、リセットされるとどうなりますか?他の開発者はこれにどのように対処する必要がありますか?機能を削除したい場合は、リリースブランチを再構成する必要があります。最初にリモートの古いリリースブランチを削除する必要があり、他の開発者も最初にリリースブランチを削除する必要がありますか?これは面倒なようです。

  • 長時間実行されるリリースブランチを持たずに、さまざまなブランチを作成する方がよいでしょうか。

では、基本的に、ブランチを自由に再構成する(したがって履歴を書き換える)ことで、このブランチを開発者間で共有するにはどうすればよいでしょうか?

ありがとう。

4

1 に答える 1

0

このワークフローを使用する場合は、Gerritをお勧めしますか?

このようなゲートキーパーを使用する場合、特定の機能を統合ブランチとマージした結果は、マージされる前にテストされます。したがって、コードのレビューと検証を通過した機能の場合にのみ、統合ブランチを「巻き戻す」必要があります。後で破棄されます。この場合、の使用git revertが適切です。したがって、統合ブランチは実際には逆方向に移動せず、機能を削除するための「逆」コミットを取得するだけです。

リリースブランチは同じ方法で処理できます。

もう1つのオプションは、リリース/機能ブランチごとに異なる名前を付けることです。何かを削除する必要がある場合は、新しいintegration-201301ブランチを作成し、古いブランチでの作業を停止します。他の開発者は、自由に過去のブランチのコピーを削除できます。古いものから特徴を除いたものと同じブランチは、まったく新しい名前の異なる構成であるため、履歴を書き換える必要はありません。

于 2013-01-25T21:47:07.690 に答える