분산 환경에서 분기하는 경우

Question

분산 된 SC 환경에서 "분기"가 사용되는 방식에 관심이 있습니다. 우리는 방금 팀 환경을 위해 수은을 사용하기 시작했습니다. 다른 경험을 통해 배울 수 있기를 바랍니다. 브랜치 프랙티스를 구성하는 좋은 방법은 무엇입니까? (잘하면 바보 같은 짓을하는 고통과 시간을 피할 수 있습니다. ..)

내가 읽은 바로는 주 트렁크에는 진행중인 개발 코드가 포함되어야하고 하나의 브랜치는 '안정적인'릴리스 일 수 있으며 다른 것들은 실험 또는 기능 일 수 있습니다 ... 트렁크에 병합됩니다. ...

그러나 버그 수정과 QA 같은 것들이 나에게 불분명 한 부분은 ... 내가 읽은 대부분의 내용은 QA (분기가 끝나면 트렁크를 병합) , 다음 트렁크에 지점을 밀어 - 이것은 성가신, 그리고 설명이없는 것 같습니다

안정 지점 (또는 분기 지점)에서 버그 수정을 수행 한 다음 트렁크와 병합하는 것도 읽었습니다 ... 직관적 인 것처럼 보입니다 - 가능한 한 안정적인 지점을 끊을 수 있으므로 버그 수정 ... 안정된 브랜치가 '안정적'이고 버전 #에서 건드리지 않을 것을 기대할 수 있습니다. ...

그 분기가 필요하다는 것을 알 수 있습니다. Google은 웹 앱, 인터프리터 언어 (준수하지 않음)로 작업하고 있으므로 실제로 변경하고 문제를 해결할 수 있습니다.

감사합니다.

=======================

알았다 알렉스 - 감사 - 그러나이 난

- 의미가 있습니다 분산 된 모델을 중앙 집중식으로 '융합'하는 '작은'고집 포인트가 있습니다. 중앙 저장소가있는 곳에서 많은 글쓰기가있는 곳 - 모두가가는 "물을주는 곳"(있는 경우) 최신 '공유'또는 '당겨'.

그래서 지금 내가 권장하는 분산 모델을 찾았습니다. (적어도 내 마음 속에서) ... 5 개 이상의 트렁크 (기본, 핫픽스, 배포/QA, 개발, 기능 -n) 그리고 사람들이 각각 끌어 당기거나 밀어 붙이도록하십시오 - 개발자가 지역적으로 Develop에서 끌어낼 것처럼 보이고 기능을 위해 지역적으로 분기 할 수 있습니다. 또는 핫 픽스 ... 그러면 일부 관리자가 중앙 개발자와 중앙 리셀러를 병합합니다 ... 개발자 팀은 QA 팀이 통과 한 수정을하기 위해 현지 발급 팀을 가질 수 있습니다. ADMIN을 DEV와 병합 하시겠습니까? 그런 다음 자신의 변경 사항을 중앙 DEV에서 로컬로 다시 가져 옵니까 ??? 아니면 로컬에서 병합해야하며 RELEASE를 중앙으로 다시 푸시해야합니까? 이과 유지에

- 나는 유지하는 것 같다 홈페이지의 로컬 복사본 ...

을 갖는 팀 dev에 대한 필요를 참조하거나 원하지 않는 (권장) 3 트렁크 중앙 저장소 (MAIN, QA, DEV)은 분산 모델의 작업 흐름을 혼란스럽게합니다. 하지만 제작 상자에 푸시되는 중앙 MAIN과 QA 상자에 푸시 된 중앙 품질 보증 (QA)은 분리 된 팀에 의해 품질 보증 (QA)됩니다. (따라서 논리적으로 모든 사용자의 dev에있을 수는 없습니다 상자 로컬)

와우 - 큰 워크 플로 관리가 엉망입니다 -이 자료를 관리하는 데있어 몇 가지 자료가 있어야합니다 - 다른 워크 플로 아이디어 등. 도구 자체는 "사용법"을 설명하는 훌륭한 작업을 수행하지 않습니다 ... 파워 드릴처럼 캐비닛을 만드는 방법에 대한 지침이 제공되지 않습니다 !!!) 롤

감사를 다시

Answer 1

Flow라는 인기 분기 모델이있다. 본질적으로 절차 적지도와 일부 도우미 스크립트입니다. 스크립트는 git 용으로 특별히 제작되었지만 절차 맵은 사용자의 경우에 적용 가능해야합니다. 본질적으로 :

• 라이브 코드 마스터 브랜치. 아무도이 지부에 대해 직접 저 지르지 않습니다.
• 가장 많이 개발되는 지점을 개발하십시오. 이것은 대부분의 작업이 이루어지는 곳입니다.
• 장기간 실행되는 피쳐는 결국 병합되어 개발됩니다.
• 릴리스하기 전에 기능 고정을 위해 개발 지점에서 분리 지점을 분리하십시오. 완료되면 코드가 마스터로 병합됩니다.
• 응급 작업을위한 핫픽스 분기입니다. 이것들은 마스터로부터 분리되어 다시 통합되어 개발되고 마스터됩니다.