問題タブ [git-rerere]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
git - git rerere はファイルを解決済みとして自動的にマークしますか?
私は git rerere を使用しています。これは便利ですが、問題が 1 つあります。ファイルを自動的に解決するときに、解決済みとしてマークしません (例: git add を使用)。したがって、「git mergetool」を実行すると、ファイルにすべての競合が残っているかのようにファイルが開かれます。
これまでのところ、呼び出し可能な小さなシェル スクリプトを作成しました。これは、競合としてマークされたすべてのファイルをスキャンして競合マーカー (例: >>>>>>>) を探し、何もない場合は git-add を呼び出します。
これを行うより良い方法はありますか？見逃した git rerere へのいくつかのフラグ?
git - git-rerere に競合解決を記録させるには、マージをコミットする必要がありますか?
git-rerere不必要なマージ コミットを作成することなく、2 つのブランチ (マスター ブランチとトピック ブランチ) の間の競合の解決を、それらのブランチが発展するにつれて段階的に記録するという意図された目的で使用しています。ただし、git-rerere マンページを読んだ後でも、rerere が実際に競合解決をいつ記録するかについては少しわかりません。新しいマージの競合を検出して解決するための私の標準的なワークフローはgit merge master、トピック ブランチから実行し、競合を解決してから、すべてのファイルをステージングして でマージをコミットし、で保存された記録された解決のみを残してgit commit -m "Finished test merge"を使用してマージを元に戻すことです。git reset --hard HEAD^git-rerere
ただし、これは少しばかげているようです。コミットを作成してから、解決を記録するためだけにそれを元に戻しますか? のマンページを読んだ後でgit-rerereも、いつ私の解決策が記録されるかはよくわかりません。競合するファイルをステージングするだけで十分ですか、それとも、私が行ってきたように、競合を解決した後に実際にマージ コミットを作成する必要がありますか?
xml - git rerereは、2つの競合の類似点をどのように把握していますか？
さて、ここに私のQがあります。「gitrerere」は2つのファイルのハッシュを比較して、解像度を把握しますか？つまり、次のタグを含むXMLファイルがあるとします。
私が対立しているとき、その数は通常13、14などのようなものに変更されるので、私は立ち往生しています：
番号が前回と同じでなくても、rerereはこの競合を自動的に解決できますか？私は常にそれがより高い数（上記の例では13）を取るような方法でそれを解決したいと思っています。それで、それが番号12と13の解決を記録する場合、それは異なる番号との競合を解決しますか？私はそれがそうならないのではないかと疑っていますが、尋ねたほうがいいかもしれません。
git - rerere キャッシュの共有
C:\project\.git\rr-cacheすべての開発者が自分のマシンに から共有フォルダーへのシンボリック リンクを設定することを推奨する人を見てきました\\server\rr-cache。
ただし、可能であれば、フォルダーを git リポジトリ自体に含めて共有する方が便利なようです。人々がこの解決策について言及しているのを見たことがありますが、実際にそれを行う方法はありません。
何か案は？
git - ログ内の大量のマージ ノイズを回避するための Git ワークフロー
master現在、より長期的な機能リリース ブランチであるワークフロー3.0と、次の週かそこらでリリースが予定されているような番号付きのブランチがあります。
3.0上記の例では、 master にマージする必要がある直前の変更をいくつかプッシュしています。頻繁にマージしないと、master最新の変更がなければ時代遅れになってしまいます。途中でマージすると、 から3.0までのマージでいっぱいのログができmasterます。
魔法のように見えるコマンドgit-rerereがこの問題を解決しているように見えますが、更新が必要なローカル トピック ブランチに対してのみです。3.0つまり、公開されていない 1 人のマシン上にのみ存在する場合に機能します。
すべての醜いマージ ノイズなしでマスターを最新の状態に保つ方法はありますか? rerere の使い方は理解できましたか？
git - 何百ものマージと過去へのマージの競合であるGitコミットを編集するにはどうすればよいですか？
リポジトリの履歴の最初の方でコミットを変更する必要があります。そのコミット以来、おそらく何百ものブランチ、マージ、およびマージの競合が発生しています。
--preserve-mergesオプションを指定してインタラクティブリベースを使用しようとしましたが、「CONFLICT（コンテンツ）：Foobar.cppで競合をマージする」に似た何百もの競合エラーが発生します。それらを手動で再解決することは、不可能ではないにしても、非常に非現実的です。
'rerere'機能について聞いたことがありますが、たった今なので、有効にしていません。
git - git rerere が一部の競合の解決を拒否するのはなぜですか?
git-rerere を使用しようとしていますが、まったく同じマージを繰り返しても、一部の競合の解決を拒否するだけです。これらの競合の何が特別なのか、なぜそれらをスキップしているのかわかりません。Rerere には、冗長モードや、特定の競合を解決して他の競合を解決しない理由を説明する方法がないようです。
rerere が競合をスキップするのは、どのような条件の場合ですか?
注: 競合を記録していると表示されますが、マージするときに競合をスキップするだけです。