Git 병합 병합 작업은 브랜치 끝(브랜치 끝)을 병합해야 하나요? 두 개의 커밋을 병합할 수 있나요?
예를 들어 브랜치 핫픽스와 브랜치 마스터가 있으며 구조는 다음과 같습니다.
init---->D +--->E +--->F+---->G 마스터
질문 1:
B와 같은 thotfix 브랜치 중간에 있는 커밋을 현재 브랜치 마스터에 병합하고 싶습니다.
괜찮나요?
명령어의 매개변수 설명으로 판단하면 브랜치 이름인 BranchName을 사용하지 않고 커밋을 사용하면 됩니다.
질문 2:
아직 브랜치 주제(그림에는 표시되지 않음)가 있고 현재 브랜치가 마스터인 경우 핫픽스와 주제 브랜치를 병합하고 싶지만 현재 브랜치 마스터에는 병합하지 않고 병합하지 않습니다. 브랜치를 전환합니다. 현재 브랜치를 그대로 유지하고 싶습니다. 마스터인 경우에도 가능합니까?
명령어의 매개변수로 판단하면 여러 커밋이 허용될 수 있기 때문에 매뉴얼에는 여러 커밋의 병합이 문어 병합을 구성한다고 되어 있기 때문에 현재 브랜치에 병합해야 하는지 궁금합니다. 그래서 이런 문제가 있습니다.
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
체리픽을 사용하여 원하는 제출물을 선택하세요
우선 사진에 뭔가 문제가 있는 것 같습니다. 두 가지가 어디에서 분리되어 있는지 알 수 없습니다.
으아악git cherry-pick命令，而不是merge를 사용해야 합니다. 추측만 할 수 있는데, 그렇습니까?다음 답변은 모두 이 추측을 바탕으로 한 것입니다. 본인과 다른 경우 댓글을 달아주세요.
질문 1: 간단히 말해서
으아악cherry-pick。首先你要知道，
git merge和git cherry-pick是不同的。。如果你要在这里用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-patchhttps://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라고 하셨는데, 기본 전략은 재귀적입니다.언급하신 여러 커밋을 병합하는 데 필요한 사항을 자세히 설명해 주세요. 아니면 그림을 그려 보완해보세요