2016-06-21 8 views
3

이 다이어그램에서 볼 수 있듯이 릴리스 브랜치에서 변경 한 버그 수정 사항을 완료하기 전에 개발 분기로 병합하는 것은 완벽합니다.변경 사항을 릴리스 분기에 통합해도됩니까?

내 질문에 개발에서 변경 한 내용을 완성되지 않은 기능으로 병합해도 괜찮습니까? (빨간색 화살표, 나에 의해 추가) 그렇다면 어떤 명령/옵션을 권하고 싶습니까?

Git Flow chart

편집이 : 아이디어가 필요하지 않은 커밋 벚꽃 선택하십시오. 기능 분기는 주요 버전 릴리스 (예 : 왼쪽에있는 다이어그램)와 같을 수 있기 때문에 병합의이면에있는 아이디어는 서비스 분기 또는 클래스 이름 변경과 같은 변경 사항을 기능 분기에서 고려하여 (또는 해결이 시작될 때까지) 릴리스가 끝나고 나올 미래의 병합 충돌은 해결 될 때까지는 매우 불안정하게 전개 될 수 있습니다.

답변

2

귀하의 질문에 "괜찮을까요?"라고 생각합니다. D가 알려지지 않은 동안 A는 안정적 일 수 있습니다. D를 기능에 병합하려면 부작용이나 버그가 발생할 수 있습니다. 버그로 인해 작업 기능이 느려지는 경우 병합하지 않는 것이 좋습니다. 가능한 한 빨리 잠재적 인 버그를 찾아내는 것이 중요하다고 생각한다면 병합하는 것이 좋습니다.

A--B--C-D-E-F->dev 
\ 
    M-N-O--P->feature 

D를 지형지 물과 병합한다고 가정합니다. B와 C를 제외한 D 만 원하면 git checkout feature;git cherry-pick D. B C D가 필요하면 git checkout feature;git merge D 또는 git rebase --onto D A feature. git-rebase는 좀더 정돈 된 히스토리를 생성하고, git-merge는 앞뒤로 복잡한 커밋 그래프를 만들 수 있습니다.

+0

답변 해 주셔서 감사합니다. 아이디어 *는 커밋을 선택하는 것이 아닙니다. 병합의 기본 개념은 기능 브랜치에서 변경 또는 이름 변경을 고려하여 릴리스가 완료 될 때 * 미래 병합 * 충돌을 방지하거나 해결하기까지는 실제로 불안정해질 수 있습니다. :) – xDaizu