기능 분기를 최신 릴리스 분기에 적용/병합하는 방법은 무엇입니까?

우리가이 상황을 생각해 보자 :기능 분기를 최신 릴리스 분기에 적용/병합하는 방법은 무엇입니까?

---A---B---C---D---E---F---G---H---I---J--- (master from upstream) 
     \     \ 
     D'--F'    J'    (releases from upstream) 
      \ 
       P---Q       (own branch)

우리는 합병 또는 J에 우리 자신의 지점을 모두 패치 갖고 싶어 '.

P --- Q가 master 브랜치의 직계 자손이었을 때, 나는 많은 문제를 겪지 않았습니다. 그러나이 유스 케이스에서는 필자 자신의 브랜치에서 다루지 않은 파일과 관련된 많은 병합 충돌을 얻는다. 이러한 충돌은이 예제에서 D '--- F'부분에서 시작됩니다. 그래서 F '--- Q에서 diff를 생성하고 이것을 g'에 적용하려고했습니다. 결과 : 많은 오류가 적용됩니다. 또 다른 접근법 인 git-format-patch F '--- Q와 git am -3 -k는 효율적인 해결책이 될 수 없습니다. 효과적으로 이것은 병합 솔루션과 매우 유사합니다. 나는 또한 rebase를 시도했다. 다시 : 내가 만지지 않은 많은 파일이 리베이스 프로세스에 나타납니다.

깨끗한 해결책이 있습니까?

출처

2012-10-08 Rob

릴리스 분기를 처리하기 전에 먼저 자신의 개발을 마스터로 리베이스해야하지 않습니까? 그리고 다른 SCM에 대한 나의 이전 경험에서, 우리는 master (유지 보수 릴리스 용)에서 changesets를 캡처하기 위해서만 release branch를 사용해야합니다. 기능 지점은 릴리스 지점 대신 개발 지점 (사용자의 경우 마스터)에서 분기해야합니다. 전체 내용을보다 쉽게 처리 할 수있게 해줍니다. –

정확하게 말하자면, 필자의 지형지 물은 실제로 드라이버 등의 커널 수정 세트로, 자체 목적으로 리눅스 커널을 구성하지만 원하는 릴리스 품질을 제공합니다. 이것이 내가 마스터가 아닌 릴리스 지점에서 내 지사를 기반으로 한 이유입니다. 나는 또한 git 경험이 증가했기 때문에 이것을했다. 나는 그 자식이 내가 터치하지 못한 파일에 대해 불평 할 것이라고 기대하지 않았다. – Rob

당신의 아이디어 (rebase back)에 대해서 : 나는 또한 이것을 고려했지만,이 질문을하기로 결정했다. 왜냐하면 이중 단계 과정이 복잡해 보일 수 있기 때문이다. 내 자신의 브랜치를 상당히 새로운 커널 버전으로 업데이트하기에는 이미 고통 스럽다. – Rob

나는 git format-patch에 의해 생성 된 커밋 수가 엄 격히 필요하다는 것을 깨닫기 시작했다. 이 패치와 포맷 패치를 다루는 것은 커밋 범위를 줄이면 결과를 훨씬 잘 처리 할 수있게되었습니다. 무슨 일이 일어나고 있는지 설명하기 위해 그래프를 확장합니다.

---A---B---C---D---E---F---G---H---I---J--- (master from upstream) 
    \ \     \ 
    \ D'--F'    J'    (releases from upstream) 
     \  \ 
     M---N---P---Q       (own branch)

M - N은 마스터를 기준으로 전의 커밋이었습니다. P는, 커밋 병합됩니다 그래서 역사에서 지금까지 깊은 패치 시리즈

git format-patch F'..Q

결과 : 자식 오전 반복 (내 경우 약 60.), 매우 이상한. 형식 패치 P --- Q가 사용될 때, 나는 대략 얻는다. 30 커밋 (사실, P --- Q는 단순화 임). 이제 이따금 반복되는 결과로 P 이후 커밋과 명확한 관계가 있고 관리가 가능했던 git mergetool 단계가 나온다.

출처

2012-10-09 08:06:09 Rob

기능 분기를 최신 릴리스 분기에 적용/병합하는 방법은 무엇입니까?

답변

관련 문제