성공적인 Git 브랜칭 모델을 기반으로 내 Git 리포지토리를 기반으로하고 있으며이 상황이 발생하면 어떻게 될지 궁금합니다.
두 가지 기능 분기 A와 B에서 개발 중이고 B에 A의 코드가 필요하다고 가정 해 봅시다. X 노드는 기능 A에 오류가 발생하여 분기 B에 영향을 주지만, 기능 A와 B가 병합 된 노드 Y에서는 감지되지 않습니다. 테스트는 다시 분기하고 다음 반복 작업을하기 전에 수행되었습니다.
결과적으로 기능 B를 작업하는 사람들이 노드 Z에서 버그를 발견했습니다.이 단계에서는 버그 수정이 필요하다고 결정됩니다. 기능 A를 작업하는 사람들은 기능의 일부이므로 버그 수정이 필요하므로이 수정은 두 기능 모두에 적용되어야합니다.
최신 기능 A 노드 (노드 Y에서 분기)에서 버그 수정 브랜치를 생성 한 다음 기능 A와 병합해야합니까? 그 후에 두 기능 모두 다시 개발에 통합되고 분기되기 전에 테스트됩니까?
이 문제는 문제를 해결하기 위해 두 지점을 병합해야한다는 것입니다. 기능 B는 기능 A의 코드를 건드리지 않으므로 수정을 구현하고 기능 B 분기를 병합 해제 된 상태로 유지하면서 기능 A의 고정 코드를 갖도록하여 노드 Y에서 히스토리를 변경하는 방법이 있습니까?
약간 관련됨 : Git 버그 분기 규칙
답변
고유 한 커밋을 사용하여 한 분기에서 버그를 수정 한 다음 다른 분기로 커밋 한 체리 픽을 선택합니다.
답변
아마도 A 나 X에는 버그가 없습니다. 발견 된 지점 B의 버그를 수정하십시오. 수정 프로그램은 정상적인 이벤트 과정에서 X 및 A로 전파됩니다.
답변
에서 인기있는 워크 플로는 아니지만 gitMercurial 에서 인기있는 워크 플로는 개정으로 업데이트 X하고 버그를 수정 한 다음 ( X2 ) 수정 한 다음 다시 실행 병합 Y(머큐리얼에서 한 쌍의 병합이되었을 것임)입니다.
사실,이 워크 플로우에 쉽게 git모두가로 전환 한 후 이후 Y에 Y2 다음 원래의 심판이 Y손실되고 그것이 결국 쓰레기가 수집됩니다. 에서 hg당신이 수동으로 저장소를 정돈하는 그 커밋을 제거했을 것이다.