'git cherry'는 머리와 상류의 커밋 수를 고려합니까?

Question

다음과 같은 시나리오를 생각해

$ git branch –a 
* dev 
    master 

$ git branch --contains 53fdfaf89fca499c36c71d29f25eb1a13b32d4d6 
dev 

$ git branch --contains f7dfb3689edcaf5f819fa5e691ce13abf858bca8 
    dev 
    master 

$ git cherry master dev 
+ 53fdfaf89fca499c36c71d29f25eb1a13b32d4d6 
+ a4e66dbde954f73185d61bfb78b40ac5e61fe56c 
+ 6fcffbd9b57e8a74726ea2cd3713f14baaaa06f5 
+ 5031ad3cdf2e81c880e9cbf049abed6f1edde3bc 
+ dcca33c373df6953ff164e8d70531abd71841278 

을하지만 트위스트는 f7dfb3689edcaf5f819fa5e691ce13abf858bca8 벚꽃이 53fdfaf89fca499c36c71d29f25eb1a13b32d4d6에서 선택 실제로 커밋, 그리고 모두 어떤 이유로 우리가이 동일한 커밋을했다 이후 실례 (정확히 동일 다른 커밋 ID로) 커밋 메시지와 커밋 ID 이외에 두 커밋간에 차이는 없습니다.

git cherry 설명서대로, 위의 커밋은 git patch-id 프로그램에서 가져온 패치 ID와 비교됩니다.

그래서 나는 실제로 나서서 위의 결과는 git patch-id 실제로 동일하게 두 커밋을 인식하지 여전히 git cherry 명령은 그렇게하지 못하는 것을 알 수

$ git show 53fdfaf89fca499c36c71d29f25eb1a13b32d4d6 | git patch-id 
bd6c061bd6c380d53832510cbaf68bebb4fb182d 53fdfaf89fca499c36c71d29f25eb1a13b32d4d6 

$ git show f7dfb3689edcaf5f819fa5e691ce13abf858bca8 | git patch-id 
bd6c061bd6c380d53832510cbaf68bebb4fb182d f7dfb3689edcaf5f819fa5e691ce13abf858bca8 

아래로 git patch-id 프로그램을 실행.

git cherry이 git patch-id이 아닌 다른 요인을 고려한 경우에만 표시됩니다.

헤드 (즉, 내 경우에는 dev 브랜치)에서 수행 된 커밋 수를 고려합니까? dev 브랜치에는 2 가지 커밋 버전이 있고 마스터에는 1 가지 버전 만 있기 때문에

Answer 1

위에서 출력 한 내용에 따라 cherry-picked 리비전을 dev에 병합했습니다 (어떤 시점에서 마스터를 병합). 힘내는 일련의 수정을 거치고 있으며, 이제 정확히 일치하는 것을 발견하여 검사 할 개정 세트에서 제거하고 패치 ID를 생성하지 않습니다. 좋은 소식은 git merge가 이미 dev에 원래 변경 사항이 있음을 인식하고 이미 해당 변경 사항을 다시 적용하려고 시도하지 않는다는 것입니다.

체리 피킹과 관련된 대부분의 워크 플로에서 체리 피크를 포함하는 분기를 분기로 병합하지 않습니다. 일반적으로 수정 사항을 마스터에 적용한 다음 체리를 선택하여 안정된 지점으로 이동합니다. 또는, 귀하의 경우에는 버그 수정을 마스터에 적용한 다음 마스터를 dev에 병합하십시오.

git cherryhere 뒤에 코드가 있습니다. 패치 ID 생성 here을 기록해 두십시오. 특히 comment on line 719에 유의하십시오. dev에없는 것보다 master에 대한 수정을 요청할 것입니다. master가 dev에 병합되기 때문에 아무 것도 없을 것입니다. 따라서 패치 ID는 생성되지 않습니다. 결과적으로 원래 체리가 아닌 리비전을 마스터로 가져 오지 않은 것으로 보입니다.

당신은 그 행동이 버그라고 주장 할 수 있습니다. 그러나 그것을 고정시키는 것은 상당한 성과를 낼 수 있다고 생각합니다.