분기 모델에 Vincent Driessen이 A successful Git branching model을 사용하고 있습니다. 모두 괜찮아요.하지만 특별한 문제가 제기 된 것을 본적이 없습니다.기능 분기의 버그 수정
새로운 기능이 필요할 때 나는 development 브랜치를 만들고 새로운 feature 브랜치를 만듭니다. 이 작업을 끝내면이 지점을 development 지점으로 병합합니다.
개발자가 기능을 만든 다음 해당 기능을 development으로 다시 병합하면 기능 코드에 버그가 있음을 알 수 있습니다. 이 문제가 어디에서 수정되어야합니까? 새 fix/bugfix 분기가 개발에서 시작되어야하고 코드가 수정되어야합니까? 나는 다른 길을 볼 수 없다.
어떻게해야합니까?
감사
모델은 단지 모델 일 뿐이며 맹목적으로 일련의 규칙을 따르지 않고보다 효율적으로 만들 수있는 구조를 제공한다는 점을 기억하십시오. 즉, 모든 상황에서 작동하지 않을 수 있기 때문에 상황을 자유롭게 조정하고 상황을 파악할 수 있어야합니다. 다시
나는 당신이이 상황에서 선택의 여지가 생각합니다. 고객이 버그를 볼 수
같은 요인에 따라 달라집니다? 버그 수정 또는 핫픽스 분기를 만듭니다.
기능 분기와 bugfix 분기 간의 차이점은 힘내의 관점에서 중요하지 않습니다. 내부 문서 또는 기타 감사 목적으로 해당 라벨을 사용하는 경우 (예 : 외부 사용자에게 표시되는 내용을 추적하는 경우)에만 중요합니다.
버그 픽스가 매우 빠르다고 생각하는 경우에도 개발 분기에서 곧바로 작동하도록 유혹을 피하십시오. 아무것도 보이지 않는 것처럼 간단하고 나중에 문제가 발생하면 두통을 피할 수 있습니다. 당신의 선택의
거친 시각적 표현 :
그 기능 분기 (다른 사람에 의해 사용되는 복제하는 원격의 repo/푸시 즉) 공개 한 경우, 그것은 새로운 지점을하고있는 디버그를 분리 수정 분기 말했다 것이 가장 좋습니다.
(대신 'feature'브랜치를 'develop'브랜치에 리베이스하려고 함).
중간 디버그 커밋을 develop 브랜치에 직접 기록하지 말고 feature 분기 병합으로 처음 도입 된 버그를 수정하는 결과 커밋 만 기록합니다.
그냥 지점을 만들거나 오래된 병합 된 feature 분기를 사용하여 수정하십시오.
이전 분기/새 분기 만들기를 사용하는 것은 똑같습니다. 병합 후 어떤 것을 명명 할 수는 없습니다.
방법에 대한 finding the commit that introduced the bug, and creating a new branch rooted there? 이 방법 :
+1000. 나는 이것이 가장 적절한 방법이라고 생각한다. 그것은 매우 명확한 커밋 히스토리로 이어집니다. 반대쪽에서, 체리 피킹은 버그가 어디서 발생했는지 그리고 어디에 고정되었는지를 완전히 숨기 때문에 가장 불투명 한 접근법입니다. git bisect는 버그를 소개 한 커밋을 찾는 데 많은 도움이됩니다. 확실히 제안 된 접근법. –
나는 것 귀하의 질문의 중복을 만들었지 만, 내 질문에 나는 개념을 테스트하기위한 실험적인 repo를 만드는 명령을 제공하는 접근 방식을 취했습니다 : http://stackoverflow.com/questions/32244693/changes-on-feature- branch after-merge-to-master/32244878? noredirect = 1 # comment52371049_32244878 예를 들어 Repo로 질문을 확장하고 제안 된 답변이 실제로 해당 Repo에 적용될 수있는 방법과 결과 ? – TheMeaningfulEngineer