問題タブ [merge-conflict-resolution]

Git を使用して Django プロジェクトに取り組んでいる 3 人がいます。

私は他の 2 人よりも経験が豊富なので、すべての変更は「マスター」に入る前に私が行います。

私たちは皆 Windows を実行しており、ディスクベースの共有が機能する場所ではないため、Linux ボックスの個々のアカウントに個別の「オリジン」リポジトリがあります。これらは、変更を互いに共有する方法として、またリポジトリの「オフサイト」バックアップとして機能します。

他の 2 人のうちの 1 人がブランチを作成し、それを BugA と呼び、修正を行います。次に、彼らはそれを自分の作業マシンから私たち全員がアクセスできる Linux マシンにプッシュして、変更を確認し、それらを私のアカウントの「マスター」にマージできるようにします (これは、本番環境に移行するコードのコピーと見なされます)。

BugA を終了すると、新しいブランチで BugB を開始します。彼らの作業をレビューしていると、いくつかの問題 (余分なコード、コメントの欠落など) が見つかりました。そのため、コードに変更を加えてテストし、master にコミットします。

その後、彼らは BugB の修正を私に送ってくれました。これらの競合は、コミットで変更したコードの行にあります。

彼らが私と合併しようとするとき、彼らは彼らの側でも衝突を報告します。

これを書いているうちに、何が間違っているのか理解し始めていると思います。私は彼らのコードをマスターにマージし、編集とコミットを行っています。私は本当に私のレポで彼らのブランチに変更を加え、それらをマージするためにそれを押し戻し、それからそれらを私のマスターにマージする必要があります。

よくわからないのは、それについて何をすべきかということです。彼らが私のレポからのブランチとマージしたら、マスターとマージする必要がありますか? 1つではなく2つのマージ？

Linux ボックスに外部ホストのレポがあるため、2 回のプッシュ、2 回のマージなどを意味します。

それは本当にそれがどのように機能するべきですか？

2 つのローカル ブランチmasterとdev. どちらのブランチにも 3 つのフォルダーが含まれていました。

projectBeta保持して削除projectしproject_v1、名前projectBetaを として変更したかっただけprojectです。それが私が両方のブランチで別々に行ったことであり、進行中にコミットしました。ブランチを master にマージしようとするまではすべて問題ないように見えましたがdev、これらの種類のエラーが山積みになりました。

そのため、Git はさまざまなブランチでさまざまな方法で名前変更を追跡しているようです。

もし私がするならgit status、私は得る

最初に理解できないのは、マージ レポートで名前が変更され、私たちと彼らの両方によって削除されたと表示されているのに、なぜステータスが「私たちによって追加された」と表示されるのかということです。

次に、test.c の dev ブランチ バージョン (それら) を使用したいのですが、試してみると

私は得る

...マージで dev ブランチのコンテンツが確実に使用されるようにする方法がわかりません。

最後に、将来このような混乱を避けるためのベストプラクティスの方法はありますか? 基本的に、コンテンツが最初にマージする準備ができていないブランチでフォルダー構造を個別に変更します...

ファイルの末尾にある改行の違いをめぐって git でプル (マージ) しているときに、競合が発生することがよくあります。

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

悪い; ファイルを手動で解決して競合するファイルを追加した後、(ファイルの最後に関連して) コミットするものは何もないように見えるため、再度プルを実行すると、まったく同じ競合が発生します。解決策はありますか？

私の混乱は、ここから取られた次のステートメントから生じます：

互いに競合するパッチをプルする場合（たとえば、ファイルの同じ部分を変更する場合）、Darcsは競合を検出し、リポジトリコンテンツにマークを付けます。次に、ユーザーが問題を解決できるようにします。

これは私が見ているものと矛盾しているように見えたので、darcs2.5.2を使用して次のワークフローを作成しました。

1. repofooを作成します。
2. fooに空でないファイルを作成し、それを記録します。
3. fooをbarにクローンします。
4. fooのファイルを削除し、記録します。
5. バーのファイルに別の行を追加して記録します。
6. fooからbarにプルし、競合通知を取得します。

これらの手順を実行darcs whatsnewした後、私はバーで実行し、2つの「パッチプリミティブ」が表示されました。

1. 「fooの空でないファイル」をすべて削除するハンクですが、追加されてバーに記録された行については言及されていません。
2. ファイルを削除するrmfile。

私の質問は次のとおりです。バーに追加および記録された行についての言及がないのはなぜですか？

バーで実行するdarcs revertと、すべてが理にかなっています。ここから抜粋したこのステートメントのように、競合するパッチの影響を受けていない「空でないファイル」が表示されます。

コマンドdarcsrevertは、競合マークを削除し、競合するパッチの前の状態に戻ります。

しかし、実行するdarcs mark-conflictsと、プル後と同じ状態に戻ります。上記の2つの「パッチプリミティブ」があり、追加されてバーに記録された行についての言及はありません。

参考/複製のために、ここにコマンドラインからの私の完全なワークフローがあります：

これを再現する確認済みの方法はまだありませんが、これがよく知られている問題である場合は、とにかく尋ねます. 何が起こるかというと、git はしばしば次のような衝突を引き起こします:

そのため、新しいコードを追加しただけではなく、行全体を変更したと git が認識します。これはファイルの途中で発生することもありますが、ほとんどの場合、ファイルの最後で発生します。私の推測では、行末文字と関係があるかもしれませんが、それを確認するためにまだテストを実行する必要があります. 誰かが同じ問題を抱えていましたか? はいの場合、どのように修正しますか?

競合するファイルがある場合、ファイルのベースバージョンとファイルの「それらの」バージョンの間の変更を表示するfoo.txt方法を教えてください。git diff

git show :1:foo.txtまたはを介して各バージョンを確認できますgit show:3:foo.txt-2つのバージョンを比較する簡単な方法はありますか？

私はごく最近、Bzr共有リポジトリを使用してプロジェクトを管理し始めました。これは、これまでインクリメンタルコミットを行っていたスタンドアロンリポジトリから分岐することで導き出しました。この新しい共有リポジトリには、「/ trunk、/branchs」レイアウトがあります。

そこで、このリポジトリのトランクからのいくつかの変更をメインラインにマージしましたが、後でトランクからさらにいくつかの変更をプッシュしようとすると、2つのブランチが分岐したというエラーが発生しました。私はメインラインへのマージをコミットしていたので、相違がありました。しかし、マージをコミットする必要がある場合、これをどのように回避するのでしょうか。それとも私は物事を真剣に誤解していますか？

この競合を解決するために、メインラインのBACKから共有トランクブランチにマージしました。/ xxxx_shared / trunkのリビジョン履歴が次のようになっているので、これは間違いだったと思います。

したがって、上記の71.1.1はメインラインからマージされており、FROM / projects / xxxx_shared / trunk（共有リポジトリ）からメインラインへのマージを指します。

これがすべて明確であることを願っています。しかし、直線的な開発ラインを回復するために、この問題をどのように解決できますか？そして、将来この種のことを避けるために、Bzrでの保守的な「ベストプラクティス」は何でしょうか？元のスタンドアロンリポジトリの変更されていないコピーがまだあるので、必要に応じていつでもそこに戻って最初からやり直すことができます。

Sync Frameworkのマージ競合解決ポリシーがどのように機能するか知っていますか？ここのドキュメント：http：//msdn.microsoft.com/en-us/magazine/dd569762.aspxは、Mergeがフレームワークによってデフォルトでサポートされていると述べています。ただし、フレームワークは列レベルではなく行レベルの変更を追跡するので、マージはどのように正確に機能するのでしょうか。

Mercurial と Python は簡単なことを難しくしてしまうので、イライラしています。些細な競合がありますが、Mercurial は何をすべきかを提案しないため、この些細なファイルの競合を解決する方法さえわかりません。

競合は些細なことですが、これを解決できなければ、複雑なことも解決できません。ファイルを好きなように編集して、どこからでも再度コミットできますか? 私は実行する必要がありますhg mergeか？Mercurial では、保持するバージョンを選択することさえできないのはなぜですか? よく書かれていない 1000 のマンページを掘り下げなければ、些細なことをほぼ不可能にできるのはなぜですか?

私たちは何か悪いことをしました。

git stash saveマージの競合中に実行したため、作業を復元できません。

私たちが試したこと：

と：

助けてください！