우선 우리가 개발하는 브랜치에는 master와 dev가 있습니다
master가 메인 브랜치입니다
dev는 개발 브랜치입니다
매번 제출하는 방식은 모두가 자신만의 로컬 브랜치(a, b, c)를 갖고 있으며, 모두 dev에 제출하고, 테스트를 통과한 사람들은 마스터 브랜치에 제출됩니다.
이상이 개발과정입니다
이제 마스터 프로덕션 환경이 대량의 프로덕션 정보로 구성되어 있고 이러한 수정 사항은 마스터에만 있으므로 이제 개발과 마스터 모두에 존재하는 이 버그를 수정해야 합니다(이론상 버그는 매우 시급합니다). , 개발팀에 제출해야 합니다. 그런 다음 마스터에 제출하기 전에 버그를 테스트하고 수정합니다. 하지만 이제 개발자 모두가 제출한 테스트되지 않은 기능이 있으므로 개발팀에서 수정하고 즉시 마스터에 제출할 수는 없습니다. , 마스터에 제출한 다음 마스터 병합할 수도 없습니다. 개발로 돌아가면 개발 환경에 많은 양의 구성 정보가 유입되므로 우리의 해결책은 개발에서 이를 수정하고 마스터에서 복구하는 것입니다.
마스터 브랜치에서 브랜치를 잘라내고 버그를 변경한 후 각각 마스터와 개발에 병합하는 방법이 있다는 것을 인터넷에서 봤습니다. 그래도 마스터의 구성 정보가 변경됩니다. 이것이 맞나요? 아니면 제가 이해한 내용에 약간의 차이가 있는 건가요?
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
마스터에서 브랜치를 포크하면 위에서 권장하는 핫픽스를 호출하고 나중에 수정한 후 커밋할 수 있습니다.
다음으로, 마스터에서 개발자로 직접 병합하는 대신(구성 정보가 다르기 때문에) cherrypick을 사용하여 개발자에게 커밋(차이점만 있음) ) "pick"을 수행합니다. .
귀하의 경우 cherrypick이 merge보다 더 적합하지만 나중에 cherrypick의 커밋에 포함되어야 한다는 점에 유의하세요. . 개발자가 원하지 않는 콘텐츠(예: 마스터의 특정 구성 정보)를 포함하지 마세요. 이러한 콘텐츠도 변경된 경우 cherrypick에서 커밋을 "skip"할 수 있으므로 별도로 제출할 수 있습니다. ).
마지막으로 왜 구성 정보 같은 것도 저장소에 있는지 궁금합니다. 이는 dev를 마스터에 병합할 때 구성 정보를 덮어쓸 위험이 있다는 뜻이 아닌가요? 구성 정보를 분리할 수 있는 경우 cherrypick이 필요하지 않고 직접 병합할 수 있습니다. 이것이 온라인에서 볼 수 있는 솔루션입니다.
실제로 이런 시나리오를 접한 적이 없습니다. 이런 일이 발생하면 아마 이렇게 할 것입니다
dev 브랜치의 마스터와 동일한 커밋에서 새 브랜치 핫픽스
를 생성하세요. 핫픽스에서 버그 수정
수리가 완료된 후 마스터와 다른 직원이 이 브랜치를 병합합니다
@Larvata 작전, 구성 파일 @nightire, 참조 자료를 추가하겠습니다
성공적인 Git 브랜칭 모델