5

developmentブランチですべての新機能を実行することを目的としたワークフローを開始しましたmaster。ブランチは本番用の準備ができたコード専用です。

次の操作を行った後:

git checkout master
git merge staging

次のような一連の競合を受け取りました。

CONFLICT (rename/add): Rename app/assets/stylesheets/mobile.css->app/assets/stylesheets/application.css in HEAD. app/...
CONFLICT (modify/delete): app/views/organizers/mobile.html.erb deleted in HEAD and modified in staging. Version stagi...
CONFLICT (modify/delete): app/views/events/mobile.html.erb deleted in HEAD and modified in staging. Version staging of app/v...

これをグーグルで調べたとき、私が読んだのは、すべてのファイルを確認し、競合を解決し、変更をコミットすることだけです。しかし、私はコードを知っており、それは同じコードセットの進歩に過ぎないので、これをすべて行うことに何の意味もありません。

stagingで行われた変更masterを、すべての変更を確認して解決することなく、単純な方法でマージするにはどうすればよいですか?

4

4 に答える 4

4

git merge「戦略」-s ours（または彼らの）と呼ばれるオプションを使用してください。つまり、git は開発ブランチ (またはマスター) からの変更を優先します。つまり、マスターとステージングで 1 つのコード文字列の変更が異なる場合、ステージングの変更が必要になります。また、 --no-commit オプションを使用することをお勧めします。これにより、マージをコミットする前に一度コードをチェックできます (変更ごとではありません)。

于 2014-12-23T16:26:58.877 に答える
1

これは非常に一般的な問題であり、簡単な解決策があります。マージの競合が発生したら、ファイルごとにこれを行うことができます。

Keep master's file
git checkout --ours myfile.html

Keep development's file
git checkout --theirs myfile.html

これをフォルダー全体に簡単に適用できます

git checkout --ours ./
git checkout --theirs ./

git merge競合するファイルも表示されるため、これは よりも優れています。詳細はこちらhttps://www.kernel.org/pub/software/scm/git/docs/git-checkout.html

于 2014-12-30T14:09:29.157 に答える