Git 병합에는 병합 분기가 필요합니까? 두 개의 커밋을 병합할 수 있나요?

Question

Git 병합 병합 작업은 브랜치 끝(브랜치 끝)을 병합해야 하나요? 두 개의 커밋을 병합할 수 있나요?
예를 들어 브랜치 핫픽스와 브랜치 마스터가 있으며 구조는 다음과 같습니다.

으아악

init---->D +--->E +--->F+---->G 마스터

질문 1:
B와 같은 thotfix 브랜치 중간에 있는 커밋을 현재 브랜치 마스터에 병합하고 싶습니다.
괜찮나요?
명령어의 매개변수 설명으로 판단하면 브랜치 이름인 BranchName을 사용하지 않고 커밋을 사용하면 됩니다.

질문 2:
아직 브랜치 주제(그림에는 표시되지 않음)가 있고 현재 브랜치가 마스터인 경우 핫픽스와 주제 브랜치를 병합하고 싶지만 현재 브랜치 마스터에는 병합하지 않고 병합하지 않습니다. 브랜치를 전환합니다. 현재 브랜치를 그대로 유지하고 싶습니다. 마스터인 경우에도 가능합니까?
명령어의 매개변수로 판단하면 여러 커밋이 허용될 수 있기 때문에 매뉴얼에는 여러 커밋의 병합이 문어 병합을 구성한다고 되어 있기 때문에 현재 브랜치에 병합해야 하는지 궁금합니다. 그래서 이런 문제가 있습니다.

Answer 1

체리픽을 사용하여 원하는 제출물을 선택하세요

Answer 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라고 하셨는데, 기본 전략은 재귀적입니다.

언급하신 여러 커밋을 병합하는 데 필요한 사항을 자세히 설명해 주세요. 아니면 그림을 그려 보완해보세요