7
내 상위 - 업 (ups)에 git를 판매하기위한 첨단에 맞다. 어쨌든 그들은 우리의 말을 듣고 있습니다. 내가 확신 할 수없는 한 가지가 있습니다. 사람들이이 문제를 어떻게 다루는 지보고 싶습니다. 기본적으로 내 질문은 근본적인 이해에서 나온다. 한 쌍의 브랜치가 더 멀리 떨어져있게 될수록 합병이 어려워진다.토픽 브랜치와의 병합 충돌을 완화하기위한 워크 플로우 전략
이 간단한 워크 플로를 제안하는 것이 좋습니다. 마스터 (릴리스) 분기, 개발 분기 및 토픽 분기가 있다고 가정 해보십시오. 각기 다른 개발자가 별도의 주제 분기를 수행하고 있으며, 해당 주제 분기를 작업 코드가 있다고 느낄 때마다 중앙 저장소로 끌어 당깁니다. 주기적으로 개발자가 요청할 때 관리자 (해당 조직에서 "기술 주역"이라는 제목이 있음)는 기능 지사에서 개발 지사로 병합합니다. 즉, 준비 서버에 설치되어 테스트를 마친 후 기능 테스트가 완료되면 마스터와 통합되어 프로덕션으로 푸시됩니다.
여기 내 질문이 있습니다. 개발자는 주제 분기를 정기적으로 병합해야합니까? 이렇게하면 모든 개발자가 공정하게 깔끔하게 다시 병합 될 것입니다 (또는 적어도 손을 뗄 수 없기 전에 충돌을 최소한 catch합니다). 관리자가 그 점에 대해 싫어하는 유일한 점은 프로젝트에 코드를 제공하기보다는 툴을 사용하기 위해해야 할 일입니다. 생각?
감사합니다, @Magnus.나는 rerere를 들었다. 그러나 나의 머리는 일반적으로 git에 관해 회전하고 있었다. 그래서 나는 그것에 파묻지 않았다. 나는 다시 한번 살펴 보겠다. –
@ Dan : 흥미로운 질문에 감사드립니다. 건배. – ralphtheninja