Git マージではブランチをマージする必要がありますか? 2 つのコミットをマージできますか?

Question

Git マージ マージ操作、ブランチの先端をマージする必要がありますか? 任意の 2 つのコミットをマージできますか?
たとえば、ブランチ ホットフィックスとブランチ マスターがあり、その構造は次のとおりです。

リーリー

init---->D --->E --->F ---->G マスター

質問 1:
thotfix ブランチ (B など) の途中にあるコミットを現在のブランチ マスターにマージしたいと考えています。 ＃＃＃いいですか？
コマンドのパラメータ説明から判断すると、ブランチ名branchNameの代わりにcommitが使用できるためです。

質問 2:

ブランチ トピック (図には表示されていません) がまだ存在し、現在のブランチがマスターである場合、ホットフィックスとトピック ブランチをマージしたいと考えていますが、現在のブランチ マスターにはマージしないでください。要件 現在のブランチをマスターのままにしておくことが可能ですか?
コマンドのパラメータから判断すると複数のコミットが受け付けられるため、マニュアルには複数のコミットのマージはタコマージと書かれているのですが、複数のコミットのマージはカレントブランチにマージしなければならないのか疑問に思っていました。そこでこの問題が発生します。

Answer 1

チェリーピックを使用して必要な提出物を選択してください

Answer 2

まず第一に、あなたの写真には何か問題があるようです。2つの枝がどこで区切られているかわかりません。 git cherry-pick 命令，而不是 mergeを使用する必要があります。推測することしかできませんが、そうですか？

リーリー

以下の回答はすべてこの推測に基づいています。違う場合はコメントください。

質問 1: 簡単に言うと、cherry-pick。
首先你要知道，git merge <hash> 和 git cherry-pick <hash> 是不同的。。如果你要在这里用 git merge B を使用するのが最善です。そうすると、次の結果が得られます:

リーリー

しかし、あなたが git cherry-pick B であれば、次の結果が得られます:

リーリー

merge 有它的优点，因为每一次 merge 其实都是创建一个新的 "merge commit"，而且会 "保留历史"，所以是一个 "non-destructive"（非破坏性）的过程。当然，cherry-pick 也有它的缺点，首先是创建一个新的 hash，这可能会导致多人协作的混乱。比如有人已经在 G 后面又加了 HJKL，那至少他还要 rebase 一下。另外，这个 B' 也不会像 merge 那样保留自己的历史记录。因此，确切的说，这个 B' 更像是一个 patch。（请参考 git format-patch https://git-scm.com/docs/git-...

個人的には好みです cherry-pick 和 rebase 这样的命令，不太喜欢 merge，最主要是因为历史线简洁很多。虽然这两个命令比 merge もう少し破壊的ですが、git に少し慣れて、各ステップが何をしているのか、それがどのような影響を与えるのかを知っておくと良いでしょう。

---

質問 2:
それは不可能だと感じます。 merge 不像 rebase 那样有类似于 --onto 这样的参数。还是切换过去再 merge やってみましょう。

後でタコのマージについて言及したときに、--strategy=octopus 么？不太确定这个 strategy 和你要问的有什么联系。。因为多个 branch 的 merge 默认 strategy 就是 octopus。。不用去专门设置。。。顺便，对于单个 HEAD 的 mergeと言いましたが、デフォルトの戦略は再帰的です。

あなたが言及した複数のコミットのマージについては、ニーズを詳しく説明してください。または補足するために絵を描いてください