1

リベース中にマージの競合が発生するという、本当に奇妙な問題だと思います。

機能ブランチを開発ブランチでリベースしようとしています:

git checkout myFeatureBranch
git rebase developBranch

git rebase が競合を報告するようになりました。競合を解決するには git mergetool を使用する必要があります。

git mergetool

Git mergetool が競合するファイルmyFile1.hを宣言し、マージ インターフェイスが開きます (同じリポジトリの Linux または Windows/tortoisegit で問題が発生します)。myOtherFile.c「私の」ファイルは正しく表示されていますが、「彼らの」ファイルは完全に間違ったファイルですmyFile1.h

私は試してみましgit gc --aggressivegit fsck --full。git gc はまったく問題を報告せず、git fsck には多くの未解決の問題がありますが、エラーや欠落した情報はありません。

これは git データベースの何らかの破損ですか? もしそうなら、修復できますか?

何が間違っているかについて他の可能性はありますか?

おそらく、「私の」ファイルをそれ自体にマージして戻すことができると思いました (すべての誤った「彼らの」変更を完全に無視します)。

問題が何であれ、新しいクローンが同じリベースの問題を示すため、マスター リモート リポジトリにあるように見えます。

ご協力いただきありがとうございます。

git config -lいくつかのリダクションを含む出力:

core.symlinks=false
core.autocrlf=input
color.diff=auto
color.status=auto
color.branch=auto
color.interactive=true
pack.packsizelimit=2g
help.format=html
http.sslcainfo=/bin/curl-ca-bundle.crt
sendemail.smtpserver=/bin/msmtp.exe
diff.astextplain.textconv=astextplain
rebase.autosquash=true
core.autocrlf=true
core.excludesfile=<global exclude file>
user.name=Russell
user.email=<email address>
push.default=simple
core.repositoryformatversion=0
core.filemode=false
core.bare=false
core.logallrefupdates=true
core.symlinks=false
core.ignorecase=true
core.hidedotfiles=dotGitOnly
remote.origin.url=<gituser@gitserver>
remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*
remote.origin.puttykeyfile=<key.ppk>
branch.master.remote=origin
branch.master.merge=refs/heads/master
branch.develop.remote=origin
branch.develop.merge=refs/heads/develop
branch.myFeatureBranch.remote=origin
branch.myFeatureBranch.merge=refs/heads/myFeatureBranch
4

3 に答える 3

5

git の名前変更検出に遭遇しています。

まず、リベースに関するいくつかの重要な注意事項。

  1. Rebase はマージ機構を使用します。

  2. マージ (例: へのマージfeature)では、「私がいるブランチ は '私たちの' コードであり、私がマージしているブランチは '彼らの' コードです」masterと言うでしょう。masterfeature

コードをリベースする場合、"ours" 側はリベース先のコードであり、"theirs" コードはリベース先のコード、つまり独自のコードです。実際には、「側面」が交換されます。( -m-s、およびの-X引数git rebaseと、サイドがスワップされることについての注意を参照してください。)

マージ機構の内部では、デフォルトの ( recursive) 戦略を使用して、git は「私たちの」myFile1.h(つまり、 からのもの) が「彼らの」 (つまり、あなたの) よりも「そのファイルのあなた自身のバージョンdevelop」に似ていると考えますmyOtherFile.cmyFile1.h。そのため、間違ったファイルをマージしようとしています。

ドキュメントに移り、 にgit merge渡すことができるオプションに注意してくださいrecursive。最も重要なのはおそらくrename-threshold=<n>. したがって、合格することができます-X rename-threshold=100(または 50 よりも十分に大きい任意の数)。私は実際にこの問題に遭遇したことはありませんが、うまくいくはずです。

于 2013-10-29T21:07:54.733 に答える
2

git rebase -p developトリックを行うように見えました。jthillに感謝します。

torekの回答はまだ試していませんが、好奇心からそれも調査する予定です。

于 2013-10-30T14:12:04.220 に答える
0

履歴のマージが違いを生むのはなぜですか?

Rebase は、時間の浪費となる冗長性を公開履歴から除外するためのノイズ削減ツールです。書かれるに値することをしたらrebase、「読むに値するものを書く」ヘルパーです。一撃一撃の場合はマージするだけですが、それが読者の仕事を不必要に複雑にする場合は、ほとんどの場合、線形化された1対1で十分で簡単なので、リベースはデフォルトでそれを試みます。それほど簡単ではないことが判明した場合は、 と 、 、 があり、-iより複雑な編集に役立ちます。-p--interactive--preserve-merges

于 2013-10-30T18:41:36.480 に答える