問題タブ [merge-conflict-resolution]

Gitまたは（バージョンにもっと興味がありますが、比較は間違いなく役立ちます）のいずれかを使用して次のワークフローを実現するための好ましい方法は何ですか？Subversion Git

• 最近製品のメジャーリリースがあり、と呼ばれる特定のポリシヒンブランチがあるとしましょうrelease-2.0.x。

  その後、開発が継続され、いくつかの機能ブランチがに統合されましたmaster/trunk（これらは後で今後の一部になりrelease-2.1.xます）。

• 現在、ある時点で別の機能（つまり、critical-feature）が開発され、にマージされましたmaster/trunk。この機能は非常に重要であるため、にバックポートする必要があることを認識していrelease-2.0.xます。

これは、説明されているケースの小さな疑似図です。一番上のすべてがrelease-2.0.x現在master/trunkとの間のツリーの違いをもたらし、マージの問題につながることに注意してください（そうでなければ、単純にマージしcritical-featureてこの質問を書かないようにすることができます:)

質問：

• VCS観点から機能のバックポートを実行するための最良の方法は何でしょうか？

• これは、競合を解決する競合を伴うmerge対応するブランチの単純なものとして実行する必要がありますか？critical-feature

• またはcherry-pick、これはコミットのとして実行する必要があります。コミットは、実行時ににマージcritical-featureさmaster/trunkれますか？または、ブランチcherry-picks内の各コミットのセットとしても使用できますか？critical-feature

• 紛争解決の手順について何かアドバイスをいただけますか？release-2.0.xとの現在の違いが非常に大きく、「ナイーブ」なバックポートがコードのリファクタリングや機能の欠落、またはの後に追加されたmaster/trunkために大量の競合を引き起こす場合は、どうすればよいですか？APIrelease-2.0.x

• 標準的なマージまたはチェリーピッキングのアプローチを除いて、このルーチンに提供する特定の何かがありますGitか？競合の量が膨大な場合、リベースSubversionは役に立たないと思いますが、明らかに、私は間違っている可能性があります。

リモートから更新を取得したいので、github からプロジェクトをフォークし、原点は自分の github リポジトリを指し、リモートは元のリポジトリを指します。

git pull remote branch_name を使用すると、ローカル リポジトリがコンフリクト モードになり、git pull の効果をキャンセルしたいので、git stash を使用しましたが、これを実行できなかったことに驚きました。どうしたの？

詳細情報は次のとおりです。

では、git pull の効果を無効にする方法は? レポを削除して、もう一度ダウンロードする必要がありますか?

pom.xmlマスターをブランチにマージするときに、バージョンタグでのマージの競合を回避する方法はありますか？私はかなりの数のpomファイル、80を持っています、そしてそれらのすべてはマスターのものとは異なる同じバージョンを持っています。git mergetoolバージョンタグのためだけに80個のpomファイルを実行するのは面倒で時間がかかります。

私はいくつかのライブラリを含む git リポジトリを持っています。ライブラリの 1 つに対する更新を含む別のブランチ (アップストリームではない) にマージしています。よりインテリジェントなマージ戦略を実装できる場合もあるかもしれませんが、単純なマージを使用しているとしましょう (あまり合理的ではありませんよね?)。

すでに実行したら、方法はありますか

sub-dir/some/lib/* を自動的かつ再帰的に解決して、着信ブランチからの「彼らの」変更を優先するようになりましたか?

これに対する明らかな、または効果的なマージ戦略がある場合は、それもお気軽に共有してください。ただし、この単純なマージ後の質問についても特に興味があります。ありがとう！

C:\project\.git\rr-cacheすべての開発者が自分のマシンに から共有フォルダーへのシンボリック リンクを設定することを推奨する人を見てきました\\server\rr-cache。

ただし、可能であれば、フォルダーを git リポジトリ自体に含めて共有する方が便利なようです。人々がこの解決策について言及しているのを見たことがありますが、実際にそれを行う方法はありません。

何か案は？

Git で簡単に (たとえば 1 つのコマンドで) マージし、競合するファイルの状態を現在のブランチのように維持し、各ファイルを自分のオプションのように個別に指定せずにするにはどうすればよいですか?

個人的なプロジェクトでgitを使用/学習しようとしています。私とリモートのgitリポジトリ、いくつかのコミットだけがあり、マージの失敗で立ち往生しています。私のファイルの多くには、Gitマージの競合マークアップも含まれています。

gitにすべてを捨てて、私のものを使用するように指示するにはどうすればよいですか？

私がどのようにして私がいる状態になったのかについての具体的な例：

3 つの主要なブランチを持つ単純なワークフローがあります。

stagingつまり、テスト環境

masterつまり、本番環境

dev/XXXXXX はチケット番号です。

• クライアントはチケットをログに記録します
• ブランチを作成します。dev/2332
• 作業 + コミット + プッシュ
• 準備ができたら作業をマージしますstaging
• クライアントが作業を承認するstaging
• 作業をマージしmaster、チケットを本番環境にデプロイします

問題：

複数の開発者がそれぞれdev/XXXのブランチで作業している場合。にマージするstagingと、競合が発生することがあります。ステージングとプッシュでこれらの競合を修正します。

問題は、クライアントがそれらの特定のチケットを承認し、作業を にマージするときにmaster、競合を再度修正する必要があることです。

重要：

• 未承認のチケットのため、ステージングをマスターにマージできません
• デフォルトではすべてのブランチが最新のマスターから作成されます
• 複数のチケットが同時に開発されていますが、承認されたときに展開されます
• 競合を回避するためのマスターからのリベースは、作業が承認されて既に展開されている場合にのみオプションです
• 未承認のチケットがあるため、ステージングからのリベースはオプションではありません

この問題を解決する方法についてのアイデアはありますか? 私たちのワークフローに欠陥はありますか? いくつかの git ハックがありませんか?

基本的に同じことは二度と繰り返したくない

ありがとうございました

I am experimenting with VirtualSVN Server, TortoiseSVN and AnkhSVN, and everything is still quite new to me.

I have added a Visual Studio 2010 (VB) solution to SVN. After this was done trunk contained version 1.0.0, I had a tag containing version 1.0.0, and a branch containing version 1.0.0-dev. I started to work on 1.0.0-dev (from the branch) and when version 1.1.0 was ready, I created a tag version 1.1.0, and a new branch 1.1.0-dev.

Then I wanted to merge this latest version (branch 1.1.0-dev) to the trunk, but run into a huge list of merge (tree?) conflicts. Most of them because of dll-files, executables and other binary files. It seemed a good idea to ignore these files, so I did from Windows explorer, right clicking each type of file, selecting from the context menu "TortoiseSVN - Unversion and add to ignore list - *.dll" (after that also *.exe and some other files).

Now I'm left with a solution directory tree with lots of yellow exclamation marks as well as deleted marks.

My questions are:

1. How do I update the trunk so it contains the latest version?
2. How do I ignore dll's that are being created by Visual Studio when building the solution anyway?
3. There is one third party dll that is not build and should be included in the repository, but the file is likely to stay the same, how should I handle that?

git rebase の競合に問題がありますが、2 つのリモート リポジトリを使用している場合のみです。ワークフローは次のとおりです。

1. 仕事する...
2. 専念
3. pull -r ステージング マスター

これはうまくいきます。競合があれば解決できます。

次に、本番リモートリポジトリで作業するときに問題が発生します。私は生産を推進しているのは私だけです。

1. git pull -r production (何らかの理由で本番環境にプッシュする前にこれを行う必要があります...早送りプッシュする必要があるため、理由はわかりません。)
2. git push プロダクション
3. git pull -r staging (リポジトリを更新するため)

ここでは、私が作業していないファイルであらゆる種類のマージ競合が発生します。

競合は次のようになります。

それで、ここに質問があります：

1. 私だけが本番環境にプッシュしているのに、なぜ本番環境からプルする必要があるのですか?
2. 既にコミットされていて、変更していないコードでマージの競合が発生するのはなぜですか?
3. どのコミットを選択しますか? HEAD または commit foo
4. それが起こらないようにするためのより良いプロセスは何ですか？