問題タブ [rebase]

トピックブランチをマスターにリベースする必要がある状況があります。それは問題ありません、それは通常のリベースの場合であり、うまく機能します。

厄介なのは、このプロセスをベアリモートリポジトリで同期させようとしているときです。

例えば

今、私はクローン/マスターにコミットし、これをオリジン/マスターにプッシュします。

これが私が終わらせたいところです：

そこに行けないようです。助けてください。

ワークフローは次のとおりです。

1. ベアリモートオリジンのクローンを作成します
2. クローン/マスターに変更を加える
3. 変更をオリジン/マスターにプッシュ
4. クローン/トピックをオリジンまたはクローンマスターのいずれかにリベースします-あまり違いはないようです
5. ここで、オリジン/トピックにリベースを反映させたいので、プッシュしたいのですが、最初にプルしてクローン/トピックを早送りし、次にクローン/トピックからのすべての元のコミットとからのすべてのコミットを含むマージを終了します一番上の起源/トピック。

私たちはブランチを使用して作業を行い、ほとんどの部分でトランクを元の状態に保ちます。ブランチからトランクに変更をマージする前に、svn/trunkからローカルブランチに最新の変更が加えられていることを確認したいと思います。それを理解するのに少し時間がかかりましたが、これが私が思いついたワークフローです。それを行うためのより良い方法があるかどうか知りたいです。（この例では、このブランチにいるのは私だけなので、このブランチを変更するためにsvn rebaseをgitする必要はありません）

私がこのようにしている理由：

• スカッシュなしのgitマージはトランクを指すgit-svn-idを追加するので、dcommitはそこにプッシュします
• svn / trunkにリベースすると、このブランチは完全に軌道から外れます

現時点では Subversion 1.4 のマージに対処する必要があり、質問に対するこの回答を見つけました。これは私の問題を正確に説明しています。実際の質問は、gitツリーの競合を引き起こす SVN のスタイルのリベースとマージの問題を扱います。これには、次の推奨事項が含まれます。

[...] ブランチをトランクを指す作業コピーに範囲マージする代わりに、「FROM Trunk@HEAD TO branch@HEAD」をトランクを指す作業コピーとマージします。本質的に：

「トランクをブランチと同一にするために必要なすべての変更をお願いします」。

svn merge作業ディレクトリにのみマージするため、実際にSVNとマージする方法を知りたいです。元の回答にタイプミスがありますか、それとも何か不足していますか?

プロジェクトの途中で Git の使用を開始しました。最初の 2 つのコミットは初期設定 (.gitignore と .gitattributes) にすぎず、3 番目のコミットM2は SVN トランクのコンテンツを追加します。

SVN 履歴をsvnという名前のブランチにインポートしました。ここで、M1は SVN トランクです ( .gitignore と.gitattributesを除いて M ​​2 と同じ内容です)。

Q:両方のブランチを統合する最善の方法は何ですか?

M1とM2をM3にマージしてからリベースできますが、 I1とI2コミットを削除する方法がわかりません。また、 M3コミットを安全に削除できるかどうかもわかりません(マージ コミットを保持するためのアドバイスをいくつか見つけましたが、この場合、M3はもう必要ありません)。

別の方法は、手動でN .. Zコミットをsvnブランチにチェリーピックすることですが、このアプローチは避けたいと思います。

最も洗練された解決策は、N .. Zコミットによって導入された変更をsvnブランチの上にリベースすることですが、共通の祖先のない 2 つのブランチに必要な構文はまだ見つかりませんでした。

免責事項：最初に知っていれば、物事はもっと簡単だったでしょうgit-svn.

私は SVN に大きなコードベースを持っていましたが、大雑把に git に配置しました。高速で効率的な分岐がなければ、ワークライフは非常に苦痛だったので、これはすべて急いで完了しました。私のプロセスは次のとおりです。

これで、小さなブランチ プロジェクトが完了しました。私はクリーンなブランチで「火を消す」ことができ、他の開発を行うことができました。よかった。私のブランチはすべて 1 つにマージされ、このコードを SVN に戻す準備ができました。

私はgit-svn今、svn repo のセットアップとフェッチを取得して、少し作業しました。しかし、それは私が得ることができる限りです。

私の git ブランチが「マスター」で、私の git-svn リポジトリが「svnrepo」であると仮定します。

失敗し、大量のマージ競合と「インデックスに既に存在します」エラーがスローされます。

まったく同じように失敗します。

git の履歴を保存し、このコードを SVN に戻すにはどうすればよいですか?

現在、2 つの支店があります。

current_versionは、すべての開発者が現在働いているブランチです。

次のバージョンを開始し、current_version のある時点からnext_versionブランチを作成しましたが、current_version の作業はまだ継続しています。next_version ではいくつかの開発を行い、翌月にはブランチがメインのブランチになり、そこですべての開発が行われます。

current_branch で開発が行われているため、定期的に (たとえば 2 週間に 1 回)、next_version をリベースすることを考えました。これは、両方のブランチの同期を維持するためです。したがって、すべての開発者が最終的に current_branch を削除して next_release に移行する場合、next_release には current_branch の統合およびテスト済みの機能がすべて含まれます。

問題はリベースです。実際のリベースとは、current_branch の最新のコミットを next_version にマージすることです。したがって、next_release でコミットされたファイルの履歴を調べると、マージ コミットだけが表示され、current_version の履歴 (コミット/作成者/注釈) は表示されません。

私は何かが恋しいですか？

私はgitで多くのローカルトピックブランチを使用しており、トピックブランチ間の依存関係が原因でリベースの問題が発生することがあります。たとえば、次のような構造になります。

master変更してリベース時に競合が発生した（そして解決した）場合featureA、その後リベースfeatureBすると、ブランチからパッチを再適用しようとするため、同じ競合がトリガーされます（場合featureAによっては新しい競合も発生します） 。との間の実際のパッチがチェリーピックされた場合にきれいに適用されるとfeatureA仮定すると、この状況でリベースを実行して、との間のすべてのコミットをチェリーピックするのとほぼ同じ効果がありますか？featureAfeatureBfeatureAfeatureB

私は使用しています

そして、単一のコミットを時間を遡って SHA1 の直後に移動します。コミットは WAV ファイルで構成されているため、これが私のコードを壊すことはありません。

一見関係のないファイルが、履歴の後半で競合として発生します。このシナリオでリベース中にこれらの競合が発生するのはなぜですか? -p は履歴の他の部分との関係をそのまま維持するのに十分ではありませんか? リベースについては、ここで完全に把握していないことがあります...

リポジトリ全体を最初のコミットまでどのように押しつぶしますか？

最初のコミットにリベースできますが、2つのコミットが残ります。最初のコミットの前にコミットを参照する方法はありますか？