git merge--ff/--no-ff/--ff-onlyの3つのオプションパラメータの違い解析
前言
専門の開発者にとっては、合併のたびに合併モードを指定する必要はないかもしれませんが、gitが背後でデフォルトで何をしているかを知る必要があります。
まず何がFast-forwardですか？
正常な開発プロセスから見てみます。
開発者の王さんは要求を受けました。マスターの支店から機能分岐を作成します。
機能が完成したらもちろんオンラインします。コードを統合してオンライン動作を完成します。コードは下記の通りです。
通常の機能分岐（feature 556）はmasterを統合して削除されますが、
それに何を言っていますか？non-Fast-forwardです。
まず下の図の模型を見ます。
マスターブランチはfeature 001よりも2つのバージョンが早くなりました。マスターはもうヘッドポインタを移動してマスターとfeature 001の共通の祖先、ノードc 1、c 6、c 3の3つのノードのバージョン（衝突があれば処理が必要） を探し出します。は、新しいノードc 7を作成し、3つのバージョンの違いをc 7に統合し、comit を作成する。 masterとHEADポインタをc 7 に移動します。
以上の動作を実行した後、最終分岐フローチャートは以下の通りです。
どうやって合併モードを手動で設定しますか？
まず、−ff自動結合モード：合併の分岐が現在の分岐の後裔である場合、 が実行される。--no-ff非Fast-forwardモード：どんな状況でも新しいcomitを作成してマルチ合算を行います。 --ff-onlu Fast-forwardモード： を起動します。
以下は--ff，--no-ff，――ff-onlyの3つのモードに関する公式説明（
Specifes how a merge is handed when the mergd-in history already a descendant of the current history.--ff is the default unless merging annotated
With--ff，when possible resove the merge as a fast-forward(only udate the branch pointer to match the merged branch)do not create a merge comit).When not possible(when the mergd-in history is not a descendant of the current history)、create a merge comit.
With--no-ff、create a merge comit in all cases、even when the merge could instead be reved as a fast-forward.
With--ff-only，refuse to merge and exit with a non-zerstatus.
まとめ:
三種類のmergeモードは善し悪しと優劣の区別がありません。あなたのチームのニーズと実際の状況に合わせて最適な統合モードを選ぶべきです。どうやって選択すればいいですか？以下の紹介をします。もしあなたが小型チームであり、清潔なリニアgitの歴史記録を追求するなら、 もしあなたのチームが大きくないならば、しかも線形のgit歴史記録を求めないで、比較的に真実なmerge記録を体現しています。それなら、デフォルトの に似合います。大型チームであり、各機能分岐の結合状況を厳格に監視するためには、
ここでgit merge--ff/--no-ff/--ff-onlyの3つのオプションパラメータの区別解析に関する記事を紹介します。もっと関連するgit merge--ff/--no-ff/--ff-onlyの内容は以前の文章を検索したり、次の関連記事を見たりしてください。これからもよろしくお願いします。
git mergeは開発者の最も一般的なgitコマンドの一つであるべきです。デフォルトではgit mergeコマンドを直接使用して、オプションコマンドが付加されていない場合、どのmergeモードを使用するかをgitに任せるべきです。実際にgitデフォルトで実行されるコマンドはgit merge -ffコマンドです。専門の開発者にとっては、合併のたびに合併モードを指定する必要はないかもしれませんが、gitが背後でデフォルトで何をしているかを知る必要があります。
まず何がFast-forwardですか？
正常な開発プロセスから見てみます。
開発者の王さんは要求を受けました。マスターの支店から機能分岐を作成します。
git checkout -b feature556
Switched to a new branch 'feature556'
git commit -m 'Create pop up effects'
[feature556 6104106] create pop up effects
3 files changed, 75 insertions(+)
git commit -m `updated md`git log --online -allは、全分岐の履歴線を見ることができます。
f2c9c7f (HEAD -> feature556) updated md
6104106 create pop up effects
a1ec682 (origin/main, origin/HEAD, main) import dio
c5848ff update this readme
8abff90 update this readme機能が完成したらもちろんオンラインします。コードを統合してオンライン動作を完成します。コードは下記の通りです。
git checkout master
git merge feautre556
Updating a1ec682..38348cc
Fast-forward
....... | 2+++
1 file changed, 2 insertions(+)Fast-forward操作を実行しているgitが発見されます。Fast-forwardとは何ですか？Fast-forwardとは、マスターがFeatureをマージする際に、マスターの現在のノードはFeatureのルートノードと同じであり、変更されていないことを発見したということで、マスターが素早くヘッドポインタをFeatureの位置に移動させるので、Fast-forwardは真のマージが発生しません。統合後の分岐ポインタは以下の通りです。通常の機能分岐（feature 556）はmasterを統合して削除されますが、
Fast-forwardモードで生成された統合によって綺麗で直線的な履歴が生成されます。それに何を言っていますか？non-Fast-forwardです。
Fast-forwardが発生すると言ったばかりの場合、今さら何を言ったらnon-Fast-forwardが発生しますか？通常、統合された分岐とmasterが共通の祖先ノードが存在しない場合、mergeの時点でgitはデフォルトでFast-forwardモードを使用できません。まず下の図の模型を見ます。
マスターブランチはfeature 001よりも2つのバージョンが早くなりました。マスターはもうヘッドポインタを移動して
Fast-forwardを完成することができませんでした。だからマスターがfeature 001を合併する時に本当の合併をしなければなりません。本当の合併はgitに多くの仕事をさせます。具体的な統合の動作は以下の通りです。git logのcomitはnon-Fast-forwardから生まれたものです。以上の動作を実行した後、最終分岐フローチャートは以下の通りです。
どうやって合併モードを手動で設定しますか？
まず、
Merge branch 'feature001' into masterの3つの統合パラメータパターンを簡単に紹介します。git mergeモードが自動的に実行され、一致しない場合は--ff (Fast-forward)結合モード--no-ff（non-Fast-forward）モードでのみマージされます。条件に合わない場合（現在の分岐の直接の後裔ではない）は、マージ要求を拒否し、以下は--ff，--no-ff，――ff-onlyの3つのモードに関する公式説明（
Fast-forwardを使用）である。Specifes how a merge is handed when the mergd-in history already a descendant of the current history.--ff is the default unless merging annotated
With--ff，when possible resove the merge as a fast-forward(only udate the branch pointer to match the merged branch)do not create a merge comit).When not possible(when the mergd-in history is not a descendant of the current history)、create a merge comit.
With--no-ff、create a merge comit in all cases、even when the merge could instead be reved as a fast-forward.
With--ff-only，refuse to merge and exit with a non-zerstatus.
まとめ:
三種類のmergeモードは善し悪しと優劣の区別がありません。あなたのチームのニーズと実際の状況に合わせて最適な統合モードを選ぶべきです。どうやって選択すればいいですか？以下の紹介をします。
git merge --helo 方式を使ってメインラインのモード開発を維持することをおすすめします。git merge --ff-onlyはgit --ffを使用して--no-ffを無効にするのはいい選択です。ここでgit merge--ff/--no-ff/--ff-onlyの3つのオプションパラメータの区別解析に関する記事を紹介します。もっと関連するgit merge--ff/--no-ff/--ff-onlyの内容は以前の文章を検索したり、次の関連記事を見たりしてください。これからもよろしくお願いします。