問題タブ [automerge]

別の開発者が作業したファイルをTFSにチェックインするときに自動マージ機能を無効にしたいので、常に手動でマージする必要があります。これを行う方法はありますか？

大規模なコードベースの再編成を実行したいのですが、再編成前に取られたブランチにトランクの修正を簡単に適用する方法を提供できない限り、先に進むことができません。

私が検討していたアプローチの 1 つは、すべてのサポート ブランチに再編成を適用することでしたが、これは不安定になる可能性があります。

推奨されるアプローチは、更新されたファイルの場所を考慮できるマージ ツールを提供することです。これを実装する方法について何か提案はありますか?

これは繰り返される質問かもしれませんが、正確な答えは見つかりませんでした。

それぞれ 3 つのコミットを持つ 2 つのブランチ br1 と br2 があるとします。

br1

• コミットする
• コミットb
• コミット c

br2

• コミットする
• コミット e
• コミット f

br2 から br1 にマージすると、git log on br1 show commits a、b、c、d、e、f.

それぞれ 3 つのコミットを持つ 2 つのブランチ br1 と br2 があるとします。

br2 とのマージ後の br1

• コミットする
• コミットb
• コミット c
• コミットする
• コミット e
• コミット f

br1 だけで作成されたコミットをフィルタリングする方法はありますか? (私は git log br1..br2 を試しましたが、他の方法はありますか?)

マージが Fast-forward または Automerge の場合、GIT はマージのコミットを記録しますか? (競合がある場合にコミットが表示されますが、自動マージでは表示されません)

gitがファイルを正しくマージできないために、同じ競合が頻繁に発生するプロジェクトに取り組んでいます。ただし、これらの競合は、外部スクリプトを使用して簡単に修正できます。外部スクリプトを使用して特定の拡張子を持つファイルのマージ競合を常に処理する必要があるため、git を許可することは何とか可能ですか? スクリプトは、ファイル内の変更された部分を見つけるために git の >>>> および <<<< マーカーを必要とするため、git は独自のマージが完了した後にスクリプトを呼び出す必要があります。

そのために使用できるフックがあるかどうか、または指定されたファイルの競合に対してこのスクリプトを実行するように git に指示できるかどうか、誰か知っていますか?

敬具、マイケル

奇妙な git マージの問題に遭遇しました。2 つのリポジトリがあります (以下の簡略化)。PublicRepo は、ほとんどの開発を行っている場所であり、時々変更を PrivateRepo にプル/マージします。

https://github.com/suwatch/PublicRepo

https://github.com/suwatch/PrivateRepo

PublicRepo のクローンを作成し、以下の行を削除してkudu.web/kudu.web.csprojに変更を加えてコミットした場合。

この変更を PublicRepo -> PrivateRepo からプル/マージしようとすると、自動マージは単にこの変更を無視し、何も削除しませんでした。別の行で試してみてください。うまくいきます（適切に削除されました）。何が問題なのだろうか？どこから調査を開始しますか? これを修正するには、プル/マージするたびにすべての自動マージされたファイルを確認する必要があることに加えて、何をしなければなりませんか?

ありがとう！

いくつか質問があります。まず第一に知りたいのgitはsubversion? 自動的にsubversionマージtrunkしたいのですがbranch、どうすればいいですか? 不可能な場合は使用する必要がありますgitか? 自動的にマージするのは良い方法ですか? そして最後の質問: これらの大企業 (グーグル、オラクルなど)のどれを使用していますか、それとも他のものを使用していmerge automaticallyますか?

すべてのユーザーに対して単一のブランチを使用します。ユーザーがプッシュしようとするたびに、最初に他の変更をプルする必要があります。これにより、ほとんどのシナリオで正常に機能する git automerge が生成されます。

昨日、ユーザーの 1 人が上記の操作を行った結果、競合が発生し、自動マージに失敗しました。ここで、その人は競合を解決し、このマージの一部としてすべてのファイルをコミットする代わりに、競合しているファイルのみをコミットしてプッシュしました (それらを解決した後)。

これにより、彼がコミットしていないすべてのファイルがリモートリポジトリで古いものとして表示されるという状況が発生しました。

変更はまだ彼のマシンに残っており、ファイル履歴に移動してもプルされていない場合は、git でも確認できます。

これから抜け出す方法はありますか？

ところで、 --rebase または --ff-only オプションは使用しません。

プロジェクトの新しいバージョンを古いバージョンとマージしようとすると、「ターゲット ブランチで項目が削除されました」というメッセージが表示され、次の 3 つのオプションが表示されます。

...ここに見られるように：

ファイルがターゲット領域に存在しない場合、どうすれば「ターゲットブランチバージョンを保持する」ことができますか?それは、「不足しているファイルをコピーしない」という意味ですか?

そして、どうすれば「ファイルを復元して自動マージ」できますか-復元すると、確かに追加されますが、自動マージですか? 単一のファイルをどのように自動マージしますか?

これらの 3 つの紛らわしいオプションを提示された場合、どのような行動を取るのが安全でしょうか?

次のシナリオを検討してください。

Hally と Sarry は両方とも、ファイル A の同じリビジョンをチェックアウトします。

どちらも A にいくつかの変更を加えます。

ハリーが最初にチェックインします。ドラマはありません。

次に、Sarry はチェックインを試みます。ファイル A が古くなっていると言われ、変更をチェックインする前に、リポジトリの最新バージョンをローカルで変更された A とマージする必要があります。

私の質問：

これは、Hally と Sarry の変更の間に競合がある場合にのみ必要です。競合がない場合、SVN はとにかく Sarry がチェックインできるようにし、Sarry の変更をリポジトリ バージョンと自動マージして、次のようなメッセージを出力する必要があります。

競合がなくても SVN が常に手動での更新とマージを強制することに少し不満があります。