개발자가 DVCS에서 잘못된 브랜치를 저 지르지 못하게 함

문제

나는 약 10 명의 개발자가있는 소프트웨어 프로젝트에 있으며 Mercurial을 통해 소스 코드를 공유합니다. 릴리스 당 개발 및 생산 지점이 있습니다. 프로젝트를 진행하는 동안 반복적으로 우리는 하나의 브랜치 (예 : v1)의 소스 코드를 이전 릴리스의 소프트웨어 즉 v2의 패치 및 유지 보수 브랜치로 가져 왔습니다.

이로 인해 코드가 잘못된 분기로 이동 한 것을 알 수없는 경우 잘못된 커밋을 백업하는 데 걸린 시간 또는 잘못된 (QAd 이외의) 코드에 도달하여 잘못된 분기에 배포되는 시간이 발생합니다.

지점 및 병합 디자인 / 방법

               v1-test   v1-patch1   v1-patch2
               ^---------^-----------^                v1-prod
              /         / \           \
-----------------------/   \           \              v1-dev
              \             \           \
               --------------------------\            v2-dev
                             \       \    \ 
                              ^-------^-------------  v2-prod
                              v2-test v2-patch1      

따라서 릴리스 개발 브랜치에서 작업 할 준비가 될 때까지 모든 릴리스 및 유지 관리가 수행되는 단일 테스트 / UAT / 생산 브랜치로 분기합니다. 태그는이 브랜치의 릴리스를 빌드하는 데 사용됩니다. v1이 테스트되는 동안 v2에 대한 브랜치가 작성되었으며 개발자는 새로운 기능에 대한 작업을 시작합니다.

발생하는 경향은 개발자가 v2-dev 분기로 인해 v1-dev 또는 v1-prod로 작업을 커밋하거나 더 나쁜 경우 v2-dev를 v1-prod (또는 이와 유사한 실수)로 병합하는 것입니다.

우리는 대부분의 개발자들에게 -prod 브랜치 에 액세스하지 말라고 지시 하지만, 코드는 여전히 몰래 들어온다.

v2가 개발을 시작한 동안 문제를 해결하기 위해 v1에 아직 상당히 많은 패치가있을 수 있습니다. 즉 v1은 홀수 작은 패치를 얻지 못할 수도 있습니다.

우리가 지금까지 시도한 것

• 게이트 키퍼와 함께 별도의 제품 분기가 있습니다. -prod 브랜치는 이름을 통해 경고를 발생시켜야하며 대부분의 개발자는 해당 브랜치에있을 필요가 없습니다. 이것은 실제로 문제를 감소시키지 않았습니다.
• 개발자들 사이에서이 문제에 대한 인식을 제고하여 더욱주의를 기울 이도록 노력하십시오. 다시 이것은 매우 성공적이지 않았습니다.

개발자가 잘못된 지점에 커밋하는 가능한 이유

• 분기 설계가 너무 복잡
• 여러 지점에서 병렬로 활발한 개발. (이 프로젝트는 눈사태 모델 사용의 증상을 나타냅니다 .)
• 개발자는 DVCS를 충분히 이해하지 못합니다

내가 읽은 질문은 다소 관련이 있습니다.

잘못된 지점에 커밋하지 않는 것에 대한 이 질문 을 읽었으며 시각적 단서에 대한 답변이 도움이 될 수 있다고 생각합니다. 그러나 우리가 겪고있는 문제가 더 근본적인 문제의 증상이 아니라고 확신합니다.

시각적 단서를 사용하면 명령 줄에 쉽게 넣을 수 있지만 팀의 절반 정도가 식을 사용하여 시각적 단서를 통합하는 방법을 잘 모르겠습니다.

질문

소프트웨어, 프로젝트 관리 또는 거버넌스 형태로 시간이 걸리거나 배포 된 코드를 더럽히는 잘못된 브랜치에 대한 커밋을 줄이기 위해 어떤 방법을 사용할 수 있습니까?

위에 설명 된대로 기여한 것으로 생각되는 이유에 대한 구체적인 의견을 주시면 회신을 제한하지 않습니다.

문제는 프로세스의 일부에서 분기 의 의미 가 바뀌는 것 입니다.

처음에는 v1 dev지점이 개발 용입니다. 모든 새로운 기능이 있습니다. 미래에는 지점의 유지 관리 지점이됩니다 v1 release. 이것이 문제의 핵심입니다.

개발자가 엉성한 것이 아니라 지사의 권한과 역할이 엉성하고 변경 될 수 있습니다.

해야 할 일은 각 지점의 역할을 설정하고 그 역할을 유지하는 것입니다. 역할이 변경되면 분기하십시오.

예를 들면 다음과 같습니다.

 developer
  commits    |   |  |   |    |     |   |     |
             v   v  v   v    v     v   v     v
 dev  +--+---------------------+------------------->
         |           ^    ^    |           ^    ^
         |           |    |    |           |    |
 v1      +----+------+----+    |           |    |
           prod  patches       |           |    |
                               |           |    |
                               |           |    |
 v2                            +-----+-----+----+
                                  prod  patches

이 모델에서 개발자는 항상 개발에 전념합니다. 패치를 빌드하는 경우 패치를 해당 릴리스의 분기로 체크인하십시오 (또는 패치의 릴리스 분기를 분기 한 다음 다시 릴리스 분기로 병합).

읽어야 할 한 가지 기사 ( '아마도'해야 할 것 '에 대한 과언 )는 Stephen Vance의 Advanced SCM Branching Strategies 입니다.

^{이 논문에서는 먼저 일반적인 의미에서 분기를 정의합니다. 그런 다음 명백한 것부터 시작하여 더 큰 개발 노력에 더 적합한 여러 가지로 분기하는 다양한 전략을 논의합니다. 그 과정에서 각 전략의 장단점에 대해 논의하고 더 복잡한 전략을 구성하는 변경에 동기를 부여하는 데 사용합니다 ...}

이 기사에서 그는 지점이 가질 수있는 5 가지 역할을 식별합니다. 경우에 따라 지점이 두 가지 역할을 수행 할 수 있으며 역할 정책이 지점 중반을 변경하지 않는 한 역할에 반드시 새로운 지점이 필요한 것은 아닙니다 (때때로 "호환되지 않는 정책에 대한 지점").

이러한 역할은 다음과 같습니다.

1. 메인 라인. 이것은 가지가 만들어지는 곳입니다. 메인 라인에서 항상 분기하면 두 분기에 분기시 분기되지 않는 공통 조상이 있으므로 병합이 쉬워집니다.
2. 개발. 개발자가 코드를 체크인하는 곳입니다. 일상적이고 평범한 것들로부터 높은 위험 변화를 분리하기 위해 여러 개발 지점이있을 수 있습니다.
3. 유지. 기존 프로덕션 환경의 버그 수정
4. 축적. 두 개의 브랜치를 병합 할 때 하나는 메인 라인을 불안정하게 할 위험이 없습니다. 따라서 메인 라인을 분기하고 분기를 누산기에 병합하고 일이 해결되면 메인 라인으로 다시 병합하십시오.
5. 포장. 릴리스 포장은 포장 분기에서 발생합니다. 이것은 종종 릴리스가되며 릴리스 노력을 개발에서 분리하는 역할을합니다. 장기 실행 릴리스 빌드를 중단시키는 원하지 않는 커밋을 처리하는 방법을 참조하십시오 . 패키징이 개발과 충돌하는 위치의 예입니다.

귀하의 예에는 계단식 메인 라인이 있습니다 (이것은 문제입니다-병합이 더 어려워집니다-v1의 수정 사항을 v2 및 v3에 병합하려는 경우 어떻게됩니까?), 유지 관리 분기가되는 dev 분기 ( 정책 변경, 이것은 문제입니다).

좋아, 그건 훌륭하지만, 이것은 중앙 집중식 VCS 인 perforce 용으로 작성되었습니다-DVCS를 사용하고 있습니다.

상기 살펴 봅시다 자식 흐름 모델을 하고 적용하는 방법을 참조하십시오.

마스터 브랜치 (파란색)는 태그 지정을위한 릴리스 브랜치입니다. 메인 라인이 아닙니다. 메인 라인은 실제로 개발 브랜치 (노란색)입니다. 릴리스 분기 (녹색)가 패키징 역할입니다. 메인 라인에서는 위험이 낮고 형상 지점 (분홍색)에서는 위험이 높습니다. 이 모델에서는 개발 브랜치에서 누적이 수행됩니다. 유지 관리는 빨간색 인 '핫픽스'로 간주됩니다.

역할 정책이 정확히 일치하지는 않지만 (각 제품마다 수명주기가 약간 다름) 일치합니다.

이렇게하면 브랜치 정책이 단순화되고 관련된 모든 사람이 더 쉽게 만들 수 있습니다.

게이트 키퍼와 함께 별도의 prod 브랜치를 사용하려고 시도했지만 실제로 하나의 저장소가 프로덕션 빌드를 수행하는 데 사용되는 것처럼 들립니다. 프로덕션 빌드가 프로덕션 리포지토리에서만 수행되고 게이트 키퍼 만 쓸 수있는 경우 에는 개발자가 푸시 할 수 없습니다. 이로 인해 게이트 키퍼에게 부담이되며, 검토 후에 만 ​​프로덕션 저장소로 푸시합니다. 물론 사람들은 필요할 때 여전히 프로덕션 리포지토리에서 끌어 올 수 있습니다.

사람들이 경험을 쌓으면 게이트 키퍼 역할을 통해 회전해야합니다.

그리고 일반적으로 Occam 's Razor를 적용하십시오 : 전체 repo 구조는 가능한 한 간단해야합니다.

Sean의 의견도 참조하십시오.

개발자는 단순히 DVCS를 충분히 얻지 못할 수도 있지만, 너무 많이 진행했을 가능성이 훨씬 높으며 개발자는 순간적으로 수행중인 작업을 추적 할 수 없습니다. 그들은 어떤 지점에서 일하고 있는지 잊어 버리고 변경 사항은 잘못된 곳에서 끝납니다.

모든 사람들이이 모든 지점에서 정기적으로 일하고 있다는 사실에 문제가 있다고 제안합니다.

@ andy256의 prod에 대한 별도의 저장소에 대한 제안은 확실히 도움이 될 것입니다.하지만 작업을 다르게 분류하거나 주어진 주에 두 개 이상의 지점에서 작업하는 개발자가 없도록 작업을 정렬해야 할 수도 있습니다.

내 주요 버그 곰 중 하나를 식별 한 것 같습니다. 소스 제어 도구의 대부분은 정확히 소스 제어 도구입니다. 이를 통해 많은 개발자가 동일한 소스 디렉토리에서 작업하여 변경 및 충돌을 처리 할 수 ​​있습니다. 길을 따라 약간의 거친 가장자리가 있었지만 cvs, subversion, git, mercural 등이 모두 이것을 제공합니다.

그런 다음 릴리스를 위해 코드를 안정화해야 할 때 다음 단계를 수행하고 분기를 도입합니다. 도구가 개발자를 실패하기 시작하는 곳입니다. 이 도구를 사용하면 분기를 만들 수 있고 분기 된 후에 분기에 발생한 변경 사항을 식별 할 수 있지만 현재 직면 한 문제는 아닙니다.

도구는 어떤 변경 사항을 다른 브랜치에 복사해야하는지 그리고 언제 발생해야하는지 선택하는 데 실제로 부족합니다. Git-flow는 브랜치 전략을 만들어 브랜치 전략을 만들어이 문제를 해결하려고합니다. 즉 브랜치가 병합되면 모든 변경 사항이 병합 된 다음 프로그래머가 언제, 어느 브랜치가 병합되는지에 대해 현명한 선택을해야합니다.

모든 개발자가 단일 릴리스 스레드가있는 하나의 프로젝트에서 작업하는 단일 저장소에서 git flow는 문제를 해결하지만 많은 회사에서 인생은 그렇게 간단하지 않습니다.

복잡한 환경에서는 전체 솔루션의 다양한 측면을 담당하는 여러 팀이 있으며 다른 팀에 내부 릴리스를 수행합니다. git-flow는 이러한 종류의 문제를 해결할 수 없습니다.

이 작업을 본 유일한 방법은 각 팀이 릴리스를 정의하고 종속성이 변경되는시기를 제어하는 ​​것입니다. 팀 A가 릴리스 1.3을 릴리스했기 때문에 팀 B는 팀 B가 선택한 경우에만 팀 A의 1.3 릴리스를 사용하기 시작합니다.

실제로 개발자 팀은 이동해야 할 변경 그룹을 정의하고 변경을 수신하는 개발자는 변경 그룹을 수신 할시기를 정의합니다.

필자가 실제로 이것을 제공하는 유일한 소스 제어 도구는 accurev입니다. 그러면 GUI가 너무 혼란 스럽기 때문에 대부분의 개발자가 그것에 대해 불평 할 것입니다. 서브 버전처럼 작동하지 않습니다 ...