Mercurial。放棄 - 代わりの実装ブランチプラクティス？

Question

私たちは閉じると一度完了した開発ブランチに統合する主な機能のためにという名前のという名前のソースコントロールとしてMercurialをソースコントロールとして使用します。

最近、特定の問題に対して2つの異なる解決策がありました。両方とも賛否両論があるのでどちらを選ぶか決められませんでしたので、との両方を実装しましたが、メインブランチにマージするものを選択しなければなりませんでした。

2番目の実装は、メインブランチにマージされることはありません。しかし、私はまだそれがいつか役に立つと思うようにそれを保つことを望んでいます。

明らかな解決策の1つは、それぞれの名前付きブランチを開くことです。両方を閉じ、1をメインにマージします。

しかし、これはソースツリーに何らかの「混乱」を残します。

他の選択肢やベストプラクティスはありますか？

Answer 1

RhodeCodeでは完全にブックマークベースのソリューションを使用し、リクエスト機能を引き出します。

リベースをマージ戦略として使用すると、コミットグラフはきれいで清潔です。変更を追跡する必要がある場合は、元のプルリクエストに戻り、CIテスト/コードコメントを含む開発プロセスが何であるかを確認することができます。

ブックマークは軽量のポインタなので、はるかに優れたオプションです。これにより簡単なリベース/コミット・スカッシュを行い、単純に新しいブックマーク・ポインタを押してプル・リクエストをこの情報で更新できます。これをMercurialのフェーズのサポートと組み合わせることで、新しいコード提出の作業のすばらしい方法が得られます。

これまでのところ、RhodeCode自体を内部的に開発しているプルリクエストは数千件あり、チーム全体で最も柔軟で簡単なプロセスであることに同意しました（これは、コミットが公開されているフォークの公開です）。