問題タブ [feature-branch]

featureA と featureB の 2 つの機能ブランチがあります。

FeatureA は完成していますが、まだテストされておらず、まだテストする準備が整っていないため、トランクにマージされていません。

私は機能 B に取り組んでおり、続行するには機能 A に実装された変更が必要であることに気付きました。

最善のアプローチは何ですか？いくつかのオプションがあると思います：

オプション1

featureA を featureB ブランチにマージし (または、必要なすべてのリビジョンを取得するように注意している場合は特定のリビジョンのみ)、必要な変更以外はすべて元に戻します。

オプション 2

featureB の変更を再実装し (今回はそれほど複雑ではありません)、featureA と featureB が同じ場所にマージされたときの競合を整理します。

どちらの方法でも、機能はテストと展開の準備が整ったリリース候補ブランチにマージされます。その RC ブランチがテスト済みであることが確認されると、一度にトランクにマージされます。

Subversion 機能ブランチから 持ち越されたものには、別の機能ブランチからの変更が必要です

「FeatureA」と「FeatureB」の 2 つの機能ブランチがあります。FeatureA は完成していますが、次のリリースに入れるかどうかが確認されていないため、trunk にはマージされません。

FeatureB は進行中であり、実際に FeatureA に適用されたdbmlにいくつかの変更が必要であることが判明しました。

いくつかのオプションがあります。そのうちの 1 つは、dbml と関連ファイルのみをマージすることです。作業コピーのルートからマージ/更新/コミットなどを行うのがベスト プラクティスであることは承知していますが、先に進むとどのような問題が発生する可能性がありますか?

機能ブランチとリリース ブランチの 2 つのソース管理シナリオについて質問があります。

• シナリオ 1 では、フィーチャー ブランチがトランクにマージされます。
• シナリオ 2 では、機能ブランチが最新のリリース ブランチにマージされます。

シナリオ 1 と比較して、シナリオ 2 の結果はどうなりますか?

両方のシナリオの考えられる長所と短所は何ですか?

2 つのシナリオの詳細:

• すべての開発は機能ブランチで行われます
• 分岐は常にトランクから行われます

シナリオ 1 (この SO-answerで説明されている内容と同様):

• 機能ブランチは常にトランクにマージされます
• 新しいリリースの準備が始まると、トランクから新しいリリース ブランチが作成されます。
• QA とリリース ブランチからの展開の後、リリース ブランチの変更/バグ修正はトランクと新しいリリース ブランチにマージされます
• トランクへの変更はすべての機能ブランチにマージされます

シナリオ 2:

• 機能ブランチは常に最新のリリース ブランチにマージされます
• 現在のリリース ブランチが新しい機能を受け入れなくなり、最終リリースの準備が始まると、トランクから新しいリリース ブランチが作成されます。
• QA とリリース ブランチからの展開の後、リリース ブランチの変更/バグ修正がトランクにマージされます
• トランクへの変更は、すべての機能ブランチと最新のリリース ブランチにマージされます

gitでマージを「元に戻す」のは簡単ではないという話がたくさんあります。短いバージョン：マージコミットを元に戻すと、将来これらの変更をマージしないようにgitに指示します。

この問題を軽減するためにマージを行うときにできることはありますか？ソフトウェア開発の通常の過程で、さらに重要なことに、変更をロールバックする必要があるときにリリースブランチの状態を制御する際に、マージを元に戻すことが本当に本当に役立つ状況はたくさんあります。

編集

私はこの記事で解決策を見てきましたが、実際には解決策とは考えていません。問題の説明の詳細です。必要です

1. 常に--no-ffを使用してください
2. それらに依存するコードを戻したい場合は、元に戻されたすべてのマージを覚えておいてください（これは、数時間、数日、数週間、または数か月先になる可能性があります…）

私が欲しいもの

Subversionでの動作は次のとおりです。「release-candidate」というブランチがあるとしましょう。これは、ステージングサーバーで実行し、機能を試す場所です。機能Aのブランチにマージするとします。Subversionでは、これはすべて1つのチェンジセットであり、すべてのファイルのすべての履歴がマージされます。気に入らないので取り出したいとしましょう。その単一のチェンジセットを元に戻すだけで、他のことを考える必要はありません。機能ブランチAは、ある時点でマージして取り出したことを覚えていなくても、将来いつでもマージできます。

その流れにできるだけ近づきたいです。どういうわけか、物事がより多くのステップを踏むようになったとしても、「将来的に物事を覚える必要がない」ように最適化したいと思います。（これは不可能かもしれません...）

開発の戦略として、機能の分岐を幅広く使用しています。簡単に言えば、やや単純化した言葉で言えば、複雑な機能を実装する開発者が、機能が適切にテストされるまで、壊れている可能性のあるブランチで作業している間、常に安定したトランクを維持することができます。その時点で、ブランチはトランクにマージされ、トランクなどで完全な統合/回帰テストサイクルが続きます。

私が抱えている問題は次のとおりです。ブランチに上記の機能を実装する過程で、ブランチに対して行われたコミットのホストが明らかにあります。各コミットには、非常に役立つ可能性のある潜在的な教育的および文書的（？）値を保持するコメントがあります。ブランチをトランクに大規模にマージすると、これらのコメントはすべて失われ、役に立たない「何とかをトランクにマージする」タイプのコメントに置き換えられます。

そのメタデータを保持するのに役立つソリューションはありますか？これはあなたの意見でも問題ですか？

PS私はSVNを使用しています。

多くの Git ブランチがあります。すでにマージされているブランチを削除するにはどうすればよいですか? それらを1つずつ削除する代わりに、それらをすべて削除する簡単な方法はありますか?

私は中間のGitリポジトリを使用して、リモートのSVNリポジトリをミラーリングしています。このリポジトリから、クローンを作成して作業することができます。中間リポジトリには、アップストリームSVNから毎晩リベースされるマスターブランチがあり、機能ブランチに取り組んでいます。例えば：

機能ブランチをリモートに正常にプッシュして、期待どおりの結果を得ることができます。

次に、リモートを追跡するためにブランチを再セットアップします。

そして、すべてが順調です。ここからやりたいのは、機能ブランチをリモートのマスターブランチにリベースすることですが、これはローカルマシンから行いたいと思います。私はできるようになりたいです：

リモート機能ブランチをリモートマスターで最新の状態に保つため。ただし、このメソッドにより、Gitは次のように文句を言います。

git pullトリックを行いますが、回避したいマージコミットを引き起こします。feature -> featureメッセージがではなく述べているのではないかと心配していますfeature -> origin/featureが、これは単なるプレゼンテーションのことかもしれません。

私は何かが足りないのですか、それとも完全に間違った方法でこれを行っていますか？リモートサーバーでリベースを実行しないようにすることは重要ではありませんが、リベースからのマージの競合を修正することは非常に困難になります。

分岐モデルには、Vincent Driessen による成功した Git 分岐モデルを使用しています。すべて問題ありませんが、特定の問題が持ち上がったことは実際には見られませんでした。

私が理解したことから、新しい機能が必要な場合は、 のブランチをdevelopment作成して、新しいfeatureブランチを作成します。これに取り組み、完了したら、このブランチをブランチにマージしますdevelopment。

開発者が機能を作成し、その機能を にマージしてdevelopment、機能コードにいくつかのバグがあることが判明した場合はどうなるでしょうか。これはどこで修正する必要がありますか? 開発から新しいfix/bugfixブランチを開始し、そこでコードを修正する必要がありますか? 別の方法が見えません。

これについてどうすればいいですか？

ありがとう

少し前に Hg リポジトリのクローンを作成し、重要なローカル コミット (メジャー バージョンの変更) を行っています。

その間に、体幹はわずかに前進しました。いくつかのコミットですが、些細な変更です。

このブランチをトランクにマージする最も簡単な方法は何ですか?

私の「ブランチ」に大きな変更があることを考えると、最新のトランクと「ブランチ」したトランクのバージョンを「比較」してから、v2 に同じ機能の変更を加えるのが最善でしょうか? - もしそうなら、どうすればこのバージョンが何であるかを知ることができますか?

ありがとう