1

gitコマンドの吐き出しを始める前に、私はGitを初めて使用するため、TortoiseGit（現在はv1.7.11.3）でWindows7-64ビットを使用しています。

私のDEVブランチは現在のリモートマスターよりも古く、DEVを更新して、競合を解決します。
DEVブランチはコミットをリモートDEVブランチにプッシュしているため、rebase不可能です-私が理解しているように。

なぜこの動作が発生し、どうすれば回避できますか？

  1. Checkout master（ローカルマスターに切り替えます）
  2. Pull origin master（競合なし）
  3. Checkout DEV（開発ブランチに切り替えます）
  4. Merge master（ローカルマスターの変更をローカルDEVブランチに適用します）
  5. 競合とcommit変更されたファイル（自動マージされたファイルと修正された競合ファイルの両方）を修正します

開くlogと、コミットウィンドウのように「親1」ファイルと表示されなかった「親2」ファイルが表示されます。これは奇妙な部分です。（ローカル/リモートが同じ）マスターが削除したファイルが追加され、新しいファイルが削除されます。さらに、「親2」ファイルは、いくつかの必要
があるにもかかわらず、競合を生成しませんでした！

新規/削除されたファイルは、私が期待したものとは逆に機能します。何故ですか ？
ファイルがマスターで新しく、DEVブランチにマージする場合、マージ後にそのファイルが存在することを期待しています。
私の推測では、DEVブランチはプライマリと見なされ、DEVにマージするブランチ（マスター）ではないと考えられます。

Revert削除されたファイル（実際にはマスターで新しいファイル）を再作成するために使用するオプションがありません。

4

1 に答える 1

2

私が見ているように、あなたのマージの方向は正しくありません：

やったほうがいい：

git checkout master
git pull origin master

ここには2つのバリエーションがあります。

1）リモートで開発ブランチの履歴を書き直したくない場合は、そのままにしておく必要があります。

git merge dev # will produce merge commit if not fast-forward

2）または開発ブランチの履歴をあまり気にしない場合

git checkout dev
git rebase master # now all commits that happened in dev will be "on top" of master, master will be behind
git checkout master
git merge dev # will result in fast-forward merge without merge commit

ここで、障害のあるマージの前の状態に戻るために、次のことを実行できます（マージがdevブランチで最後に行った場合）。

git checkout dev
git reset --hard HEAD~1

これで、適切にマージできます。2番目のケースでは、-fフラグを使用しない限り、ほとんどの場合、devブランチをリモートdevにプッシュすることは非早送りとして禁止されます。お役に立てば幸いです。

于 2012-07-17T20:13:59.863 に答える