우리는 Agile과 함께 작업하고 기능 단위로 기능을 릴리스 할 수 있도록 새로운 분기 정책을 채택하여 master 분기와 QA 분기를 영구 분기로 사용합니다. 야간 빌드는 QA을 기준으로하며 출시일은 master입니다. 개발자는 각 스토리에 대한 기능 분기를 만듭니다. 모든 피쳐 브랜치는 master에서 분기 된 다음 테스트를 위해 QA으로 병합 한 다음 후속 릴리스를 위해 master으로 피쳐 분기를 병합합니다. 이것은 다음과 같은 시나리오까지 괜찮 :Agile Branching 워크 플로우를위한 병합 전략
- 개발자 A ("로드"),
feature/RodsFeature를 만들어 몇 가지 작업을 수행하고QA로 통합했다 (그러나 아직master) - 개발자 B ("제인")
feature/JanesFeature만들었습니다, 몇 가지 작업을 수행하고 지금QA - 충돌 지금
feature/RodsFeature
QA에 소개 변화에 의한, 제인을 위해 발생하는 병합 병합을 시도
Jane이 품질 보증을 거치지 않고 에 feature/JanesFeature을 병합하면 feature/RodsFeature이 아직 master이 아니기 때문에 충돌이 발생하지 않습니다. 그러나 명백한 이유로 Jane은 QA으로 병합해야합니다. 충돌을 해결하기 위해 그녀는 Rod의 변경 사항을 자신의 지사로 가져 와서 충돌을 해결 한 다음 병합을 수행 할 수 있습니다. 일단 그녀가 자신의 지사를 master으로 병합하면 바람직하지 않은 결과를 초래할 수 있습니다. QA 테스트 대기 중입니다.
따라서 QA 브랜치에서 직접 충돌을 해결하고 나중에 Jane의 기능 브랜치를 그대로두고 master에 병합하는 것이 좋습니다. 그러나 이것은 병합이 피어에 의해 승인되어야하므로 코드 검토 정책을 중단합니다. 이렇게하면 로컬로 QA으로 병합되고 끌어 오기 요청이나 동료 검토없이 원격으로 푸시됩니다.
이 상황에서 '우수 사례'로 간주되는 사항은 무엇입니까?
QA 지점에 병합되고 있지만 1이 거부되는 및 기능 2 즉시 출시 될 예정중인 기능 :
도 참조하십시오. 이 문제는 워크 플로우를 변경하여 기능을 QA/개발 분기에 병합하지 않고 승인하기 전에 수정함으로써 해결되었습니다. – Warpzit