web-dev-qa-db-ja.com

gitマージ後のgit rebase

次の状況があります。

  • メインリポジトリ（X）からclone（Y）を作成しました。Yで作業している人が多かったため、rebaseを実行せず、mergesのみを実行しました。 YからXに（Push）を配信する場合は、rebaseを実行して、すてきできれいなものにする必要があります。

問題は、rebaseを実行するときに、前のmergeステップで既に実行したすべてのマージを実行するように求められることです。実際にマージを再実行することを意味するもののほかに、これに対する解決策はありますか？

競合するマージをすでに解決しているため、かなり簡単になると予想していました。

gitmergerebasegit-rebase
71
INS

「クリーン」な履歴を取得するためのリベースは過大評価されています。履歴を保持する場合の最適な方法は、リベースではなくマージを実行することです。そうすれば、リビジョンに戻る必要がある場合、exactlyは開発中にテストしたものと同じです。これにより、以前に解決されたマージの競合に関する問題も解決されます。

履歴を保存する必要がない場合は、マスターから新しいブランチを作成し、チェックアウトしてからgit read-tree -u -m dev作業ツリーをdevブランチに一致するように更新します。その後、すべてを1つの大きなコミットにコミットし、通常どおりマスターにマージできます。

79
Karl Bielefeldt

git merge --squashは、現在、大量の作業と多くのマージの後のリベースの好ましい方法です（ この回答を参照 ）。作業中のブランチがmy-branchとmasterからリベースしたい場合は、次のようにします。

git checkout my-branch
git branch -m my-branch-old
git checkout master
git checkout -b my-branch
git merge --squash my-branch-old
git commit
102
Jon Lemmon

2つの発言：

  • 新しくフェッチされたコミットに加えて、自分の（まだプッシュされていない）作業を何度でもリベースできます。
  • アクティブ化されたgit rerere 、これはこの種の状況に対して行われます。
    http://git-scm.com/images/rerere2.png 詳細は git rerere 。
10
VonC

ブランチのすべての変更を取得し、次のようにmasterの新しいコミットに入れることができます。

git diff master > my_branch.patch
git checkout master
patch -p1 < my_branch.patch

次に、ファイルをステージングしてコミットします。

4
dbaston

マージの競合のリプレイに関しては、git rerereを使用して、マージの競合が既に解決された方法のデータベースを維持することができます。これにより、同じ競合が発生するリベースを実行すると、面倒な部分が自動的に行われます。

https://hackernoon.com/fix-conflicts-only-once-with-git-rerere-7d116b2cec67

git config --global rerere.enabled true

気を付けなければならないのは、何かを間違って解決した場合、次回も自動的に中断されるため、実際には気付かない可能性があることです。 。

より正式なドキュメントはこちら： https://git-scm.com/docs/git-rerere

1
Ajax