.... を代わりに使用してください
git merge --abortコマンド git merge --abort はマージ プロセスを放棄し、マージ前の状態を再構築しようとします。ただし、マージ開始時にコミットされていないファイルがある場合、git merge --abort はマージ前の状態を再現できない場合があります。 (特に、これらのコミットされていないファイルがマージ プロセス中に変更される場合)
警告: git-merge を実行すると、コミットされていないファイルが大量に含まれやすくなります。紛争で後退するのが困難な状況にある。したがって、git-merge を使用する場合は、コミットされていないファイルを使用することは強くお勧めできません。git-stash コマンドを使用して、これらのコミットされていないファイルを一時的に保存し、競合を解決した後に使用することをお勧めします。 git stash Popこれらのコミットされていないファイルを復元します。
2. パラメータ
このセクションでは、 git-merge コマンド
- で使用されるパラメータを紹介します。 -commit および --no-commit --commit パラメーターを使用すると、マージ後にマージ結果のコミット ノードが生成されます。このパラメータは --no-commit をオーバーライドできます。
--edit および -e および --no-edit --edit と -e は、マージと送信が成功する前に、エディターを呼び出して、自動的に生成されたマージ情報をさらに編集するために使用されます。したがって、ユーザーは合併の結果をさらに解釈し、判断することができます。 <blockquote><p>マージ時に <code>-m パラメータを指定した場合 (後述)、--edit (または -e) を使用すると便利です。 、これにより、エディタで -m に含まれるコンテンツがさらに編集されます。
ノードの古いバージョンでは、ユーザーがマージ ログ情報を編集できない場合があります。
2.3--ffコマンド
--ff は、早送りコマンドを指します。早送りモードを使用してマージする場合、新しいコミット ノードは作成されません。デフォルトでは、git-merge は早送りモードを採用します。
2.4--no-ffコマンド
早送りモードが使用できる場合でも、新しいマージ ノードを作成します。これは、git merge がタグをマージするときのデフォルトの動作です。
2.5--ff-onlyCommand
現在の HEAD ノードが最新 (更新が最新のノードを指す) または早送りモードでない場合マージを使用できます。そうでない場合、マージは拒否され、失敗ステータスが返されます。
2.5 --log[=<n>]</n> および --no-log
--log[=< ;n>] マージして送信すると、ブランチ名に加えて、最大 n 個のマージされたコミット ノードのログ情報も含まれます。 --no-log では、この情報はリストされません。
2.6 --stat、-n、--no-statコマンド
--stat このパラメーターは、マージ結果の最後にファイルの差分のステータスを表示します。ファイル差異のステータスは、git 設定ファイルの merge.stat で設定することもできます。 -n、--no-stat パラメーターでは、この情報は表示されません。
2.7--squash および --no-squash
--squash マージが発生すると、現在のブランチと他のブランチの共通祖先ノードの後に他のブランチ ノードを追加し、他のブランチの最上位ノードまで圧縮します。ユーザーはレビュー後に送信して新しいノードを生成できます。
注 1: このパラメータは --no-ff と競合します
##注 2: このパラメータを使用した後の結果は次のようになります。現在のブランチに新しいノードをコミットします。このパラメーターは、Git Flow を使用する場合など、場合によっては非常に役立ちます (Git Flow については、「成功した Git ブランチ モデル」を参照してください)。関数ブランチが機能要件を開発しているとき、開発者はローカルで多数の要件を送信することがあります。また、意味のないノードは、develop ブランチにマージする必要がある場合、この長いノード リストの変更内容を表すために新しいノードを使用するだけで済みます。 #コマンドが活躍します。さらに、機能ブランチの複数の送信が簡単ではないが意味がある場合は、--no-ff コマンドを使用する方が適切です。 --no-squash はまったく逆の効果があります。
-s および --strategy=##-s <strategy> および </strategy> --strategy= は、マージ戦略を指定するために使用されます。デフォルトでは、このパラメータが指定されていない場合、git は次の条件に従ってデフォルトのマージ戦略を使用します。 マージ ノードに 1 つの親ノードのみが含まれる場合 (早送りを使用する場合など)モード)、再帰的戦略が使用されます (以下で紹介します)。
マージされたノードに複数の親ノードが含まれる場合 (早送りなしモードを使用している場合など)、タコ戦略 (後述) が使用されます。
2.9 -X and --strategy-option=
- ■ <strategy></strategy>、戦略の特定のパラメータを指定します (後述)。
2.10 --verify-signatures、
--no-verify-signatures
(以下は転載記事からの引用です。原著者が見つからないため、原著者情報と原リンクを提供できません。侵害がある場合は、プライベートメッセージまたはコメントでお知らせください。 、次の引用は削除させていただきます。)GPG は暗号化ソフトウェアです。GPG によって生成された公開キーを使用して、ファイルやコードをインターネット上に安全に拡散できます。
2.11 —概要,--概要なし
および--統計および --no-stat も同様ですが、将来のバージョンでは削除される予定です。
2.12 -q および --quize
はサイレントに動作し、マージの進行状況情報は表示されません。
2.13 -v および --verbose
は、マージ結果の詳細情報を表示します。
2.14 --progress および --no-progress
は、マージされた進行状況情報を表示するかどうかを切り替えます。どちらも指定しない場合は、標準エラー発生時に接続端末にメッセージが表示されます。すべてのマージ戦略が進行状況レポートをサポートしているわけではないことに注意してください。
2.15-S[<keyid>]</keyid> および --gpg-sign[=<keyid>]</keyid>
GPG 署名。
2.16-m <msg></msg>
マージノード作成時に使用するコミット情報を設定します。 --log パラメーターが指定されている場合、コミット ノードの短いログがコミット情報に追加されます。
2.17--[no-]rerere-autoupdate
rerere は、記録された解像度を再利用する、記録されたソリューションを再利用することを意味します。これにより、ブロックの競合を解決する方法を Git に記憶させ、次回同じ競合が発生したときに Git が自動的に解決できるようにすることができます。
2.18--abort
現在のマージ競合処理プロセスを放棄し、マージ前の状態の再構築を試みます。
3. マージに関するその他の概念
3.1 マージ前の検出
外部ブランチをマージするときは、自分のブランチをクリーンな状態に保つ必要があります。そうしないと、マージ競合が発生します。多くの問題を引き起こします。
3.2早送りマージ
通常、ブランチ マージではマージ ノードが生成されますが、いくつかの特殊なケースでは例外があります。たとえば、git pull コマンドを呼び出してリモート コードを更新する場合、ローカル ブランチにコミットがない場合は、マージ ノードを生成する必要はありません。この場合、マージ ノードは生成されず、HEAD は更新されたトップ コードを直接ポイントします。このマージ戦略は早送りマージです。
3.3 マージの詳細
上記の早送りマージ モードに加えて、マージされたブランチはマージ ノードを介して現在のブランチに結び付けられます。マージ前の現在のブランチのノードと他のブランチの最上位ノード (両方とも親ノード)。
HEAD ポインタが指すノードは変更されません。
MERGE_HEADポインタは他のブランチの上に配置されます。
クリーン パスがマージされました。インデックス ファイル ノード ツリーと同時に更新されます。
競合パスの場合、インデックス ファイルには 3 つのバージョンが記録されます。バージョン 1 は両方の共通の祖先ノードを記録し、バージョン 2 は現在のブランチの先頭、つまり HEAD を記録します。 、バージョン 3 レコードは MERGE_HEAD です。ノード ツリー内のファイルには、マージ プログラムの結果が含まれています。たとえば、3 方向マージ アルゴリズムでは競合が発生する可能性があります。
その他の変更はありません。特に、以前に行ったローカルな変更はそのまま残ります。 git merge --abort
約 3- を使用できます。ウェイ マージ アルゴリズム:
3.4 タグのマージ
タグをマージすると、現時点で早送りモードが使用できる場合でも、Git は常にマージされたコミットを作成します。タグの情報には、投稿情報のテンプレートがあらかじめ設定されています。さらに、タグが署名されている場合、署名検出情報がコミット メッセージ テンプレートに追加されます。
3.5 競合の表現方法
マージ競合が発生すると、この部分は , # で終了します。 ##========<code> と >>>>>>> を表します。 ======= より前が自ブランチの状況、 ======== より後が相手ブランチの状況です。 。
3.6 競合を解決する方法
マージしないことを決定します。現時点では、インデックスを HEAD ノードにリセットするだけです。この場合は git merge --abort が使用されます。
競合を解決します。 Git は競合をマークします。競合を解決したら、git add を使用してインデックスに追加し、git commit を使用してマージ ノードを生成します。 次のツールを使用して競合を解決できます: マージ ツールを使用します。 git mergetool は、競合するマージを処理するためにビジュアル マージ ツールを呼び出します。
違いを確認してください。 git diff は、3 方向の差分 (3 方向マージで使用される 3 方向比較アルゴリズム) を表示します。
各ブランチの違いを確認してください。 git log --merge -p は、HEAD バージョンと MERGE_HEAD バージョンの違いを表示します。 マージ前のバージョンを表示します。 git show :1:ファイル名共通祖先のバージョンを表示します。git show :2:ファイル名現在のブランチの HEAD バージョンを表示します。git show :3 :ファイル名相手のブランチのMERGE_HEADバージョンを表示します。
4. マージ戦略-X を使用します。 (マージは git merge コマンドと git pull コマンドの両方で発生する可能性があるため、このマージ戦略は git pull にも適用されることを忘れないでください)。
4.1resolveもちろん、本当に気になるのはクロスマージ（十字併合）の状況です。いわゆるクロスマージとは、複数の共通の祖先ノードが存在する状況を指します。たとえば、2 つのブランチをマージする場合、2 つの共通の祖先ノードが存在する可能性が非常に高くなります。現時点では、それに応じてマージを実行できません。 3 方向マージ アルゴリズムに変換します (共通祖先ノードが一意ではないため)。これは、解決戦略がクロスマージ問題を処理する方法です。ここでは、「Git によるバージョン管理」を参照してください:
複数の可能なマージ ベースがある、交差マージの状況では、解決戦略は次のように機能します: 可能なマージ ベースの 1 つを選択し、最善の結果を期待します。これは実際にはそれほど悪くありません。そうですね。ユーザーがコードの別の部分で作業していることが判明することはよくあります。その場合、Git は、すでに存在している変更の一部を再マージしていることを検出し、重複する変更をスキップして競合を回避します。これらは競合を引き起こすわずかな変更であり、少なくとも開発者が競合を簡単に処理できるようにする必要があります。祖先ノード)、解決戦略は次のように機能します。考えられるマージ参照ポイントの 1 つを選択し、これが最良の結果であることを望みます。合併中。これは実際のところ、思っているほど悪くはありません。通常、ユーザーはコードのさまざまな部分を変更しますが、その場合、多くのマージ競合は実際には冗長で反復的になります。解決を使用してマージすると、生成された競合の処理が容易になり、実際にコードが失われるケースはほとんどありません。
2 つのブランチをマージする場合は、3 方向マージ アルゴリズムのみを使用してください。解決とは異なり、クロス マージの場合、このマージ メソッドは再帰的に呼び出されます。共通の祖先ノードの後の 2 つのブランチの異なるノードから開始して、3 方向マージ アルゴリズムが再帰的に呼び出されてマージされます。競合が発生した場合は、その後、ファイルのマージは続行されなくなり、競合が直接スローされます。競合のない他のファイルは最上位ノードまで実行されます。さらに、このアプローチでは、ファイル名の変更を伴う操作を検出して処理できます。これは、git のマージおよびコードのプルのデフォルトのマージ アクションです。 再帰的マージ戦略には次のパラメータがあります:
4.2.1 ours
このパラメータは、競合が発生したときに現在のブランチのバージョンが自動的に使用されるように強制します。このマージ方法では問題は発生せず、git でも他のブランチのバージョンに含まれる競合内容をチェックせず、他のブランチの競合内容を破棄します。
は私たちのものとはまったく逆です。 彼らのパラメータと私たちのパラメータはどちらも、バイナリ ファイルの競合をマージするのに適しています。
4.2.2 忍耐力
このパラメータを使用すると、git merge-recursive 重要でない行 (関数など) の括弧の欠落を避けるために、余分な時間を費やします)。現在のブランチと他のブランチの間のバージョン ブランチの分離が非常に大きい場合は、このマージ方法を使用することをお勧めします。 4.2.3diff-algorithm=[patience|minimal|histogram|myers]
情報git merge-recursive 別の比較アルゴリズムを使用する。 4.2.4 ignore-space-change
、ignore-all-space、ignore-space-at-eol 指定されたパラメータに従ってスペースの競合を処理します。
相手のバージョンがスペースの変更のみを追加する場合、競合がマージされるときに自分のバージョンが使用されます
自分のバージョンにスペースが含まれているが、相手のバージョンに多数の変更がある場合、競合がマージされるときに相手のバージョンが使用されます通常の処理プロセスを使用します
4.2.5 no-renames 名前変更の検出を閉じます。 subtree[=]
このオプションは、サブツリー マージ戦略の高度な形式であり、2 つのノード ツリーをマージするプロセスを推測します。 . 入居方法。違いは、指定されたパスがマージの開始時に削除されるため、サブツリーを検索するときに他のパスが照合できることです。 (サブツリー マージ戦略の詳細については、以下を参照してください)
このマージ方法は 3 つ以上のブランチに使用されますが、競合により手動マージが必要な場合はマージが拒否されます。このマージ方法は、複数のブランチをバンドルするのにより適しており、複数ブランチのマージのデフォルトのマージ戦略でもあります。
このメソッドは任意の数のブランチをマージできますが、ノード ツリーのマージ結果は常に現在のブランチの競合部分になります。この方法は、古いバージョンを置き換える場合に非常に効率的です。このメソッドは、再帰的戦略におけるパラメータとは異なることに注意してください。
サブツリーは、再帰戦略の修正バージョンです。ツリー A とツリー B をマージする場合、B が A のサブツリーである場合、B は同じノードを読み取るのではなく、まず A のツリー構造に一致するように調整します。
3 方向マージ戦略 (デフォルトの再帰戦略を参照) を使用する場合、現在のブランチと他のブランチの両方でファイル (またはコード行) が変更された場合、その後、ブランチの 1 つにロールバックします。その後、このロールバックの変更が結果に反映されます 。この点で混乱する人もいるかもしれません。これは、マージ プロセス中、git は 2 つのブランチのすべてのノードではなく、2 つのブランチの共通の祖先ノードと HEAD ノードのみに焦点を当てるためです。したがって、マージ アルゴリズムはロールバックされた部分を unchanged とみなし、マージされた結果が他のブランチの変更された部分になります。 推奨学習:「 Git チュートリアル
」
##1.3
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
