62

ストーリー: プロジェクトの途中で、同僚がmasterから新しいブランチを作成し、重いリファクタリング作業を開始しました。マスターからブランチを作成し、ページで新しいことを始めました。私たちは定期的にコミットしていますが、コードをマスターにリベースできるのは私だけです(同僚の変更が重すぎて、まだマスターからデプロイできないため)。残念ながら、私たちの作業の一部は同じファイルに依存しています。そのため、最終的に変更をmasterにリベースしたいと思った数日間の作業の後、多くの git 競合が発生しました。

my_branch    #---#----#-#-------#----#--#-----#---#----#----#
            /     \              \   \   \              \    \
master     *-------*--------------*---*---*--------------*----*----*
            \                                                     /
her branch   #------#-------#-----------#-----------#------------#

質問 1 は、同じファイルで作業しているときに多くの git 競合を防ぐ方法は? (または、この状況でのベスト プラクティスは何ですか?)

しかし、これで私たちの質問は終わりではありません...正確に言うと、彼女は master から自分のブランチにリベースしようとしました (変更をコミットするため)。コミット マップは次のようになります。

my_branch    #---#----#-#-------#----#--#-----#---#----#----#
            /     \              \   \   \              \    \
master     *-------*--------------*---*---*--------------*----*----*
            \                   \            \                    /
her branch   #------#-------#----*------#-----*-----#------------#

そして、これが私たちを悩ませているものです。これらのリベース中に、彼女はそれらの競合を修正していました。しかし、git はコンフリクトの修正に関する彼女の決定を覚えていないため、別の git rebase をmasterからher-branchに行ったとき、以前のリベースで修正していたのと同じ git コンフリクトを再度修正する必要がありました。

質問 2 : masterブランチからの git rebase の後に git conflict fix を記憶するように git に指示する方法は?

4

4 に答える 4

77

幸い、gitには、この問題を正確に処理するためのメカニズムがありgit rerereます。基本的に、git rerere有効にしている場合は、競合を解決するたびに、特定の方法でその正確な競合を解決したという事実が記憶されます。同じ競合が再び発生した場合、同じ解決策が自動的に使用されます。以下にいくつかの役立つ記事があります。

...しかし、基本的には次のことができます。

git config --global rerere.enabled 1

...そしてそれを忘れて、より簡単なリベース/マージを楽しんでください:)

于 2011-08-30T10:20:56.350 に答える
4

--onto常にスイッチを使用してリベースしていることを確認してください。

競合を防ぐために、フローティング開発ブランチを使用してください。各開発者は、開発ブランチを継続的にリベースします。開発者は自分が実装したばかりのことを知っており、競合の解決に問題がないはずなので、これは簡単です。リベースする代わりに、最終バージョンをマージするだけです（すでにリベースされています）。

于 2011-08-30T10:21:54.533 に答える