問題タブ [git-merge]

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.

0 投票する
15 に答える
2247468 参照

git - マージの競合が発生しました。マージを中止するにはどうすればよいですか?

私は使用git pullし、マージの競合がありました:

ファイルの別のバージョンが適切で、私のファイルが不適切であることはわかっているので、すべての変更を破棄する必要があります。これどうやってするの?

0 投票する
36 に答える
3153416 参照

git - Git リポジトリでマージの競合を解決するには?

Gitリポジトリでのマージの競合を解決したいと考えています。

どうやってやるの?

0 投票する
18 に答える
576156 参照

git - 「git merge -s ours」の「彼らの」バージョンはありますか?

を使用してトピック ブランチ「B」を「A」にマージするとgit merge、競合が発生します。「B」のバージョンを使用して、すべての競合を解決できることを私は知っています。

を認識していgit merge -s oursます。しかし、私が欲しいのはのようなものですgit merge -s theirs

なぜ存在しないのですか?git既存のコマンドと競合するマージ後に同じ結果を得るにはどうすればよいですか? ( git checkoutB からのマージされていないすべてのファイル)

ブランチ A (ツリーの B バージョンへのマージ コミット ポイント) から何かを破棄するだけの「解決策」は、私が探しているものではありません。

0 投票する
4 に答える
140547 参照

git - さまざまな git マージ戦略をいつ使用しますか?

git-merge の man ページには、使用できるマージ戦略がいくつかあります。

  • 解決- これは、3 ウェイ マージ アルゴリズムを使用して 2 つのヘッド (つまり、現在のブランチとプルした別のブランチ) のみを解決できます。交差するマージのあいまいさを慎重に検出しようとし、一般的に安全で高速であると考えられています。

  • recursive - これは、3 方向マージ アルゴリズムを使用して 2 つのヘッドのみを解決できます。3 方向マージに使用できる共通の祖先が複数ある場合、共通の祖先のマージ ツリーを作成し、それを 3 方向マージの参照ツリーとして使用します。これにより、Linux 2.6 カーネルの開発履歴から得られた実際のマージ コミットで行われたテストによって、ミスマージを引き起こすことなく、マージの競合が少なくなることが報告されています。さらに、名前の変更を含むマージを検出して処理できます。これは、1 つのブランチをプルまたはマージするときのデフォルトのマージ戦略です。

  • タコ- これは 2 頭以上のケースを解決しますが、手動での解決が必要な複雑なマージを拒否します。これは主に、トピックのブランチ ヘッドをまとめるために使用することを目的としています。これは、複数のブランチをプルまたはマージする場合のデフォルトのマージ戦略です。

  • ours - これは任意の数のヘッドを解決しますが、マージの結果は常に現在のブランチ ヘッドになります。これは、サイドブランチの古い開発履歴に取って代わるために使用されることを意図しています。

  • サブツリー- これは修正された再帰戦略です。ツリー A と B をマージするとき、B が A のサブツリーに対応する場合、同じレベルでツリーを読み取るのではなく、最初に B が A のツリー構造に一致するように調整されます。この調整は、共通の祖先ツリーに対しても行われます。

デフォルト以外のものをいつ指定する必要がありますか? それぞれどのようなシナリオに最適ですか?

0 投票する
28 に答える
909906 参照

git - Gitの別のブランチから変更を選択的にマージまたは選択するにはどうすればよいですか?

私はGitを、2つの並行する(ただし現在は実験的な)開発ブランチを持つ新しいプロジェクトで使用しています。

  • master:既存のコードベースのインポートに加えて、私が一般的に確信しているいくつかの変更
  • exp1:実験ブランチ#1
  • exp2:実験ブランチ#2

exp1そして、exp22つの非常に異なるアーキテクチャアプローチを表しています。さらに進むまで、どちらが機能するか(どちらかがあれば)を知る方法はありません。一方のブランチで進歩を遂げていると、もう一方のブランチで役立つ編集があり、それらだけをマージしたい場合があります。

他のすべてを残したまま、ある開発ブランチから別の開発ブランチへの選択的な変更をマージするための最良の方法は何ですか?

私が検討したアプローチ:

  1. git merge --no-commit続いて、ブランチ間で共通にしたくない多数の編集を手動でアンステージします。

  2. 共通ファイルを一時ディレクトリにgit checkout手動でコピーした後、他のブランチに移動し、さらに手動で一時ディレクトリから作業ツリーにコピーします。

  3. 上記のバリエーション。今のところブランチを放棄し、exp実験のために2つの追加のローカルリポジトリを使用します。これにより、ファイルの手動コピーがはるかに簡単になります。

これらの3つのアプローチはすべて、面倒でエラーが発生しやすいようです。より良いアプローチがあることを願っています。git-mergeより選択的になるフィルターパスパラメーターに似たもの。

0 投票する
11 に答える
217160 参照

git - Git ワークフローとリベースとマージの質問

私は、他の開発者とのプロジェクトで数か月間 Git を使用しています。私はSVNで数年の経験があるので、関係に多くの荷物を持ってきたと思います。

Git は分岐とマージに優れていると聞いたことがありますが、これまでのところ、そのようには見えません。確かに、分岐は非常に単純ですが、マージしようとすると、すべてがうまくいきません。今、私はSVNからそれに慣れていますが、ある標準以下のバージョン管理システムを別のシステムと交換しただけのようです。

私のパートナーは、私の問題は意地悪にマージしたいという私の欲求から生じていること、そして多くの状況でマージの代わりにリベースを使用する必要があることを教えてくれました。たとえば、彼が作成したワークフローは次のとおりです。

基本的に、機能ブランチを作成し、常にマスターからブランチにリベースし、ブランチからマスターにマージします。注意すべき重要なことは、ブランチは常にローカルのままであるということです。

これが私が始めたワークフローです

本質的な違いが 2 つあります (私が思うに): 私はリベースの代わりに常にマージを使用し、フィーチャー ブランチ (およびフィーチャー ブランチのコミット) をリモート リポジトリにプッシュします。

リモート ブランチを使用する理由は、作業中に作業をバックアップしたいからです。リポジトリは自動的にバックアップされ、問題が発生した場合に復元できます。私のラップトップはそうではないか、それほど完全ではありません。したがって、他の場所にミラーリングされていないコードをラップトップに置くのは嫌いです。

リベースの代わりにマージする理由は、マージが標準のように見え、リベースが高度な機能のように見えるからです。私の直感では、私がやろうとしていることは高度なセットアップではないので、リベースは不要なはずです。私は Git に関する新しいプラグマティック プログラミングの本も熟読しましたが、それらはマージを広範囲にカバーし、リベースについてはほとんど言及していません。

とにかく、私は最近のブランチで自分のワークフローに従っていましたが、それを master にマージしようとすると、すべてがうまくいきませんでした。重要ではないはずのものとの衝突がたくさんありました。対立は私には意味がありませんでした。すべてを整理するのに 1 日を要し、最終的にリモート マスターへの強制的なプッシュが行われました。

このようなものの「正しい」ワークフローは何ですか? Git は分岐とマージを非常に簡単にするはずですが、私はそれを見ていません。

2011 年 4 月 15 日更新

これは非常によくある質問のようです。最初に質問してから 2 年間の経験を更新したいと思います。

少なくとも私たちの場合、元のワークフローは正しいことがわかりました。言い換えれば、これが私たちがしていることであり、機能します。

実際、生のマージではなくスカッシュ マージを行う傾向があるため、ワークフローは少し異なります。(注: これは議論の余地があります。以下を参照してください。 ) これにより、機能ブランチ全体を master 上の単一のコミットに変えることができます。次に、機能ブランチを削除します。これにより、ブランチ上でコミットが少し乱雑であっても、マスター上でコミットを論理的に構造化することができます。だから、これは私たちがすることです:

スカッシュ マージの論争- 何人かのコメンターが指摘しているように、スカッシュ マージはフィーチャー ブランチのすべての履歴を破棄します。名前が示すように、すべてのコミットを 1 つにまとめます。小さな機能の場合、これは 1 つのパッケージに凝縮されるので理にかなっています。より大きな機能の場合、特に個々のコミットがすでにアトミックである場合は、おそらく良い考えではありません。それは本当に個人的な好みに帰着します。

Github と Bitbucket (その他?) のプル リクエスト- マージ/リベースがプル リクエストにどのように関連するのか疑問に思っている場合は、マスターにマージする準備が整うまで、上記のすべての手順に従うことをお勧めします。手動で git とマージする代わりに、PR を受け入れるだけです。これはスカッシュ マージを行わないことに注意してください (少なくともデフォルトではそうではありません) が、非スカッシュ、非早送りがプル リクエスト コミュニティで受け入れられているマージ規則です (私の知る限り)。具体的には、次のように機能します。

私は Git が大好きになり、SVN には戻りたくありません。苦労している場合は、そのまま続けてください。最終的には、トンネルの終わりに光が見えます.

0 投票する
20 に答える
244565 参照

git - git-merge --dry-run オプションはありますか?

多くの競合が発生する可能性があるリモート ブランチにマージしています。競合があるかどうかはどうすればわかりますか?

--dry-runonのようなものは見当たりませんgit-merge

0 投票する
3 に答える
41690 参照

git - Gitマージフラット化

1つの機能で複数のブランチで作業している場合は、git pull branch1 branch2 branch3すべての変更をマスターブランチにプルするために使用します。ただし、各ブランチのすべてのコミットログもコピーされます。コミットログを単一のメッセージにフラット化するにはどうすればよいですか?

0 投票する
4 に答える
39412 参照

git - 作業ツリーへのコミットされていない変更を git merge で処理するにはどうすればよいですか?

現在、同僚と私は両方とも master ブランチに取り組んでいます。作業ツリーに、コミットしたくないコードがいくつかあります (デバッグ ステートメントなど)。彼がそれらの同じファイルのいくつかに変更をコミットした場合、それらをマージできません。

Subversion のバックグラウンドを持っているので、リポジトリから変更をプルすると作業ツリーが自動的にマージされ、競合がある場合は手動で解決することに慣れています。

gitでこれを行うために私が見つけた最も簡単な方法は次のとおりです。

基本的に、コミットされていない変更を削除し、マージしてから変更を再適用します。取り込もうとしている変更を作業ツリーに自動的にマージするようにマージに指示するにはどうすればよいですか?