問題タブ [git-rebase]

私は、開発の変更をマスターにコミットしてアップストリームにプッシュしました。これらの変更をリモートリポジトリからバックアウトし、後でマスターにマージするためにブランチをローカルに保持する最良の方法は何ですか?

次のケースを取り上げます。

トピックブランチでいくつかの作業があり、マスターにマージする準備ができました:

マスターからマージを実行し、競合を解決すると、次のようになります。

ここで、マージに時間がかかったので、別のフェッチを行って、リモート マスター ブランチに新しい変更があることに気付きました。

マスターから試すとgit rebase origin/master、すべての競合を再度解決する必要があり、マージ コミットも失われます。

以下に示すような履歴になるように、マージ コミットをリベースするクリーンな方法はありますか?

コマンドラインから git rebase を実行する方法は知っていますが、公式のgit-guiでどのように実行しますか?

私はしようとしています

私のリモートリポジトリから最新の21のコミットを追加します。

gitが私に言っているのは、競合があるということですが、それはどのようにして可能でしょうか？

私の理解では、21のコミットを取得し、それらをマスターの上に適用するだけです。どうすれば競合が発生する可能性がありますか？

手伝ってくれてありがとう！

どういうわけかgit-svnリポジトリ（リモート）を台無しにしたので、私はそれをやっています、そして私がSubversionにコミットすることができない21のコミットがあります。そこで、21個のコミットを追加する新しいgit-svnクローンを試してみました。

数週間触れていなかった機能ブランチをリベースする前は、マスターより25コミット進んでいました。リベース後、18コミットになりました。途中で解決しなければならなかったいくつかの対立がありました。おそらく正確に7。

この番号が変わる原因は何ですか？途中で発見され、NOOPコミットに変わったチェリーピック？上記の紛争解決？

これは、バグ修正ブランチをマスターブランチにマージして、アップストリームにプッシュする準備をしたときのトランスクリプトです。バグ修正ブランチが作成されてから、いくつかのアップストリームの変更がマスターにプルされ、リベースを拒否するようになりました。

エラーをスローするファイルは、開いたときに差分されません。追加、削除、または名前変更されたファイルはありません。無視されるものはなく、追跡されていないもの、ステージングされているもの、ステージングされていないものはありません。リベースが失敗する理由について私は完全に困惑しています。

私はOSX10.6.6とgit1.7.4を使用しています

マスターの上に適用したい小さなトピックブランチ（寄稿者のリモートリポジトリ上）があります。これを行うための標準的な方法は次のとおりです。

ただし、マージコミットを生成するのではなく、コミットを1つずつ適用したいと思います。

トピックブランチが私のアップストリームであるかのように、マスターをトピックブランチに適用するため、単純に実行してgit rebase contributor/topic-branchも明らかに機能しません。だから私はこれを試しました：

そして、これは私が望むことを行いますが、今は分離されたHEADがあり、マスターブランチを修正してHEADを指すようにする必要があります（を使用してbranch -f）。もちろん、これを自動的に行うBash関数を作成することもできますが、使用せずにトピックブランチをプルする「適切な」方法はありmergeますか？

ここ数日、Git を使ったリベースを検討してきました。リベースの議論のほとんどは、リベースによって履歴がクリーンアップされ、より直線的になると言われています。単純なマージを行うと (たとえば)、履歴がいつ分岐し、いつ元に戻されたかを示す履歴が得られます。私の知る限り、リベースするとその履歴がすべて削除されます。質問は次のとおりです。コードがどこでどのように分岐したかなど、コードが開発されたすべての方法をレポ履歴に反映させたくないのはなぜですか?

競合でリベースが失敗した後、GitGUIクライアントを使用してリベースを続行できませんでした。演奏するとき

コマンドライン（msysgit 1.7.4）で、テキストエディタを開きました。それを閉じた後、Gitは続行しました。エディターを開かないようにするにはどうすればよいですか？

私が使用しているビルド システムでは、通常、フル ビルドを実行する前に、プロジェクト データをローカル リポジトリにコミットする必要があります。これは、頻繁にコミットし、パブリック リポジトリにプッシュする前にリベースするという私の通常の習慣に加えて、通常、リモート ヘッドの上にコミットのスタックがあることを意味します。それらのほとんどは、「s」のようなコミット メッセージを持っています。

ここでの状況は、コミットのリストをリベースするステップの 1 つを自動化することです。特定のファイルに加えたすべての変更をパブリックリポジトリにプッシュするべきではないことを知っています。各コミットを編集して、そのファイルへの変更を個別のコミットに分割する方法を探していました。リベース。

たとえば、オリジンの HEAD の場合、私が一番上に持っているコミットは次のとおりです。

master..master-dave からのすべてのコミットを反復処理し、./file.txt への変更を抽出して、次のようにします。

そして最後に、git rebase -i origin/master を実行し、すべての「DD」コミットをまとめて押しつぶし、すべての「s」コミットを「master ブランチで更新された pkg」に入れ、並べ替え、master を更新します。 、原点にプッシュし、最終的には次のようになります。

答えは git filter-branch にあると確信していますが、その方法がわかりません。

編集：

• --autosquash は「s」コミットの煩わしさを修正しますが、それは主な問題ではありません。変更を特定のファイルに分割する方法はまだわかりません。これは、それらをつぶす前に行う必要があります。
• smudge/clean フィルターは気の利いたものですが、私はキーワードの置換を行っていません。また、個人のブランチで維持したい変更が、スクリプトを作成するのに十分なほど予測可能になるとは思いません。私は常に公開マスターよりも少なくとも 1 コミット先にいる必要があると思います。