1

SubversionからGitに切り替えました。

今朝発生した問題は、ブランチからマスターへのコミットをチェリーピックしたため、メーザーがバグを修正することでした。次に、マスターをブランチにマージしました。

コンパイルしようとすると、厳選されたコミットからのすべての追加がコードに2回含まれていました。

厳選されたコミットは、数行のコードの追加で構成されていましたが、その後、コードに2回含まれることになりました。幸い、それらは関数全体であったため、コンパイラエラーが発生しました。

紛争は発生しませんでした。

どうすればこれを回避できますか。それは大きな問題です。

ありがとう。

4

1 に答える 1

6

チェリーピックは、Gitの観点からは別のコミットです。つまり、マージバックすると、最初に適用されたコミットの上に新しいコミットがマージバックされます。

つまり、ハッシュを使用してコミットを作成しますABC。あなたはそれをチェリーピックして、新しいコミットを作成しDEFます。マージバックは、DEFと一緒に適用されABCます。

上記では、おそらくマスター(たとえば)でコミットを実行し、それをブランチにチェリーピックすることを期待します。

このブログ投稿には詳細があります。

マスターブランチに新しいコミットが作成されることに注意してください。マスターで「gitlog」を実行すると、同じコミットメッセージに対して異なるハッシュが表示されます。なんで?

これは、Gitがコミットとは何かをモデル化する方法によるものです。コミットはリポジトリ全体の完全なスナップショットであり、特定のコミットのハッシュは、ディレクトリ全体のすべてのファイルの状態を反映します。これは、すべてのハッシュのハッシュです。

明らかに、マスターブランチには機能ブランチからのすべてのコミットがないため、バグ修正が適用されたときの完全なスナップショットは、バグ修正が適用されたときの機能ブランチの完全なスナップショットとは異なるハッシュを生成します。そこに適用されます。したがって、異なるハッシュ。

ただし、機能ブランチをマスターにマージする場合、それは問題ではありません。バグ修正を行った個々のファイルのハッシュは、内容が同じであるため同じになります。そのため、そのファイルのマスターで更新するものはありません。

このブログ投稿では、同様の状況と、そのgit rebaseような問題を回避するための使用方法について詳しく説明しています。

于 2013-01-09T14:58:26.407 に答える