3

それで、私はマスターのブランチを持っています。これを foo と呼びましょう。これをしばらく使用しており、約 50 回のコミットの後、foo には独自のサブブランチがいくつかあったため、かなり複雑なマージ履歴を取得していました。ここでは履歴は重要ではなかったので、各ブランチをリベースし、すべてのコミットを 1 つにまとめてクリーンアップすることにしました。これにより、master とそのブランチの違いを表すコミットが 1 つだけになります。

最初は、次のことができると思いました。

git checkout foo
git rebase master

しかし、これはうまくいきませんでした。ブランチには 50 を超えるコミットがあり、それぞれが多くのファイルにアクセスしており、各コミットで多数の競合が発生していました。

代わりに、私がやったことはこれでした：

git checkout foo
<copy all files to another folder>
git checkout master
git branch -D foo
git checkout -b foo
<overwrite all files with the copy I made earlier, and create a new commit>

これは、途中ですべての競合に対処することなく、マージの長い歴史を単一の押しつぶされたリベースに変えるという私のニーズに応えましたが、これを行うためのより「gitフレンドリーな」方法があったかどうか疑問に思っています?

4

3 に答える 3

3

git でこれを行うより使いやすい方法は、3 つ目の統合ブランチを作成することです。foo を開発したら、その上で master と foo をマージします。これにより、同時に変化するコードベースをどのように扱っているかが git に表示されます。構成で rerere (記録された解像度の再利用) を有効にすることが重要です。

最終的に foo を master にマージする準備ができたら、git は競合を解決する方法を知っているでしょう。

または、準備ができたら、その統合ブランチを master にマージします。競合があってはなりません。履歴にあるすべてのテスト マージを許容できるかどうかによって異なります。

これは、Branch per Feature に関する私の投稿に多少関連しています: http://dymitruk.com/blog/2012/02/05/branch-per-feature/

ファイルがどのようにして現在の状態になったかに関する情報が失われるため、コミットを破棄することはお勧めしません。

于 2012-11-28T17:44:38.160 に答える
0

やってみました：

git merge --squash

これが行うことは、すべての変更を取得し、それらをインデックスに入れ、コミットする準備ができていることです。マージの競合は引き続き発生しますが、それらは 1 か所にあり、1 つの大きなチャンクに記載されている内容をコミットする前に修正できます。

より詳細な説明と図については、これを見てください

于 2012-11-28T17:44:53.300 に答える
0

Git の磁器は、すべてのマージ ステップを 1 つのオクトパス マージ コミットに真に押しつぶすために必要なゆがみを実際に処理することはできません。幸いなことに、Git は必要な配管を公開しているため、1 つのコマンドでこれを実行できます。タコのマージについて私が持っていた質問に対するこの回答を参照してください。

于 2015-03-23T17:58:21.223 に答える