問題タブ [git-rebase]

を使用してマージの競合が発生した場合、ファイルの違いだけでなく、コミットの観点からgit rebase競合の原因を特定するにはどうすればよいですか？

私はすでに（基本的な）使用方法git mergetoolまたはgit addそれ以前の方法を知っていgit rebase --continueますが、ファイル間の違いだけでは不十分な場合があります。作業ツリーに適用できなかったコミットのログと差分を確認したいのです。

git log --mergeを使用している場合に親がコミットすることを示す他の質問を読みましたgit merge。とにかく衝突に遭遇して言われたときに試してみましたfatal: --merge without MERGE_HEAD?。

問題のあるコミットを特定するにはどうすればよいですか？

後のコミットからメッセージを変更する方法があります。

最初のコミット（親がない）のコミットメッセージをどのように変更できますか？

ねえ、私はgitを初めて使用し、プルを元に戻す必要があります。誰か助けてもらえますか？！？だから私がやったことは...

1. git commit
2. git stash
3. git pull --rebase
4. git stash pop

これはたくさんの衝突を引き起こし、少し間違っていました。「gitstashlist」を実行すると、私のstashがまだそこにあることがわかります。gitcommitを実行した直後のポイントにリポジトリを戻すことは可能ですか？事実上、私のリポジトリには、私が行った変更のみが含まれ、サーバーからの新しいものは何も含まれていませんか？

マスターブランチの機能をきれいにマージするために使用したいと思いますgit rebase（コミット数を減らすか、少なくとも変更ログの先頭で）。リポジトリで作業しているのは私だけであることに注意してください。

Gitワークフローとリベースとマージの質問を読んだ後、私はかなりいいと思いました。ミカのように、さまざまな場所（ノートブック、自宅、別のPCなど）から変更をリベースgit rebaseしたいのです。 ..）git push

したがって、ここに2つの解決策があります（双方向の醜いマージに対する）：

1. を使用git push -fしてプッシュしてから他のマシンをプルしますが、他のマシンで最新バージョンをクリーンに取得するにはどうすればよいですか？
2. マージを使用してマスターの変更を機能ブランチにマージし、git push / pullし、成熟したら、単一のリベースを実行します（1つ以上のコミットでクリーンに）

（2）以下のようになります：

どの解決策がうまくいくと思いますか？私はこれまでどちらも試していません（主にログが乱雑になることを恐れて）。

これは現在、私たちのプロジェクトの 1 つで gitk がどのように見えるかです:

https://dl.dropbox.com/u/2582508/gitk.png

これは、リモート ブランチで単一の「git マージ」が実行された後に発生したようです。理由や何が起こっているのかはわかりません。ここで何が起こったのか分かりますか？

さらに重要なことは、それを修正するための最良の方法は何ですか? これらのマージ コミットは空ですが、「git rebase -i」を実行すると、通常、マージ コミットは表示されないようです。

最も重要なことは、履歴を他のクローンと互換性がないようにしないことです。つまり、履歴をプル/プッシュ/マージできるようにする必要があります。それは可能ですか？

私はマスターにたくさんのコミットを行い、後でそれらがブランチにあるべきだったことに気付きました。

マスターのリベース、マージ、リセットについてさまざまなことを見てきました。しかし、操作の試みは、私がやろうとしていることのように見える歴史を生み出しませんでした.

私の試みは、マスターを時間内に戻すにはrebase --ontoとの組み合わせが必要であると私に信じさせます。reset --hardしかし、Git の分岐についての私の理解には、まだ不十分な点があります。これを行うことの一部は、それをどのように使用できるかを学ぶことです。

私が移動しようとしている変更はどれもプッシュされていないことに注意してください。

現時点の

望ましい結果

私はgitを初めて使用し、スカッシュとリベースの違いを理解しようとしています。私が理解しているように、リベースを行うときはスカッシュを実行します。

マスターの最新のコミットにリベースしたいブランチがあります。問題は、マスターに介在するコミットの1つが、特定のファイルのセットを削除して無視することでした（この質問を参照）。

ストレートリベースを実行すると、それらのファイルは再び削除されます。すべてのファイルを手動でコピーしてから、後で再度コピーするのではなく、git内でこれを行う方法はありますか？

または、マスターから新しいブランチを作成してから、古いブランチからのコミットだけをマージするようなことをする必要がありますか？

アスキーアートの試み：

（アートをやっていると、Aからブランチをリベースし、終了したらマージできることに気付きましたが、これを「適切に」行う方法があるかどうかを知りたいです）

これを試みている人への警告を更新します。ここで提案する解決策は問題ありませんが、マスターを再度チェックアウトすると、Bコミットが再適用され、すべてのファイルが再び失われます:(

バックグラウンド

Subversion を使用するプロジェクトにいくつかの機能を追加しています。git-svn を使用してローカル リポジトリにクローンし、git-svn rebase を使用して公式トランクの最近の変更を維持し、履歴を線形に保ちます。

最近、私は自分自身を忘れて、いくつかのマージを行い、リベースを台無しにしました。つまり、歴史を再び線形にするために、cherry-pick で時間を費やす必要がありました。その後、1 回のリベースはうまくいきましたが、現在 git-svn リベースを作成しようとすると、2008 年からの Subversion コミット (約 700 回前のコミット) の間で競合が発生しますが、履歴は直線的であるように見えます。

質問

1. 私のgitリポジトリをsvnトランクで再構築/再同期する方法はありますか?
2. 別のコンピューター (.git/svn フォルダーなし) で自分の git リポジトリのクローンを作成した場合、リポジトリの URL と最後にリベースされたリビジョンを知っていれば、svn でリベースできますか?

私はこの質問を認識していますが、それを私の現在の状況にマッピングする方法がわかりません. (リベースは怖い、リベースを元に戻すのは二重に怖い!)

マスターのいくつかの異なる機能ブランチから始めました。

それらをすべてマージして、マスターの上部にマージする前に機能することを確認したかったので、次のことを行いました。

それで

それは私を残します

次に、適切にコンパイルされなかったいくつかのビットを修正し、機能セット全体を許容可能な状態にしました。

問題は、FeatureA の準備ができていないと同僚が言うことです。

すべての作業を保持しながら、FeatureC を FeatureB にリベースできる状況に戻す方法はありますか?