단순화 된 Git 흐름을위한 브랜치 개발을 없애는 방법

지속적으로 개발 된 웹 프로젝트 (제품 아님)에는 대략 git flow를 기반으로하는 다음과 같은 분기 전략이 있습니다 .

• 브랜치 개발 : 최신 작업 버전
• 마스터 브랜치 : 릴리즈 / 릴리스 버전
• 기능 분기 : 개발 기능
• 핫픽스 분기 : 릴리스 된 버전의 긴급 버그 수정

마스터 는 읽기 전용이며 개발 또는 핫픽스 분기의 풀 요청을 통해 업데이트됩니다 . 각 업데이트로 릴리스 후보가 스테이징 시스템에 빌드되고 배치됩니다. 릴리스 후보는 수동 승인 후 프로덕션에 배포됩니다.

기능 브랜치 는 develop을 기반으로 하거나 마스터로 병합 된 마지막 커밋에서 작성 됩니다. 기능 지점에서 개발을위한 풀 요청이 작성되어 통합 테스트 및 승인 테스트 (자동 및 수동)가 실행되는 무료 테스트 시스템에 배포됩니다. 성공적으로 테스트 및 검토되면 PR은 병합되어 다음 릴리스의 일부가됩니다 (즉, 개발에서 마스터로 병합).

내 목표

이것을 단순화하고 개발 지점을 제거하고 싶습니다. 개발 브랜치는 주로 역사적인 이유가 있으며 항상 성공적으로 테스트 된 버전이므로 마스터와 분리 할 필요가 없다고 생각합니다. 제거하면 더 이상 추가 병합이 없으므로 릴리스 프로세스가 단순 해집니다.

다음과 같은 제약 조건이 있습니다.

• 릴리스가 예정되어 있으며 완전히 자동화되어서는 안됩니다
• 기능 분기는 일반적으로 수명이 짧지 만 일부는 몇 주 동안 병합되지 않은 상태로 유지되지만 (예 : 재 설계) 테스트해야합니다 (현재 개방형 풀 요청 개발)
• 때로는 단일 기능이 정식 릴리스 외부에서 릴리스되어 효과적으로 핫픽스로 전환되어야합니다. 현재 전략으로 피쳐 브랜치를 리베이스하고 마스터에 직접 병합 할 수 있습니다
• 또한 스테이징 실패시 외부 시스템을 사용한 승인 테스트 후 기능을 보류해야합니다.

전환에 대해 확신이없는 곳 :

• 현재 릴리스에 대한 테스트 및 병합 커밋에 대한 풀 요청을 작성 중입니다. 이것을 통일 할 수 있습니까?
• 마스터가 최신 릴리스보다 앞서있을 때 핫픽스를 처리하는 방법 핫픽스 분기에서 직접 릴리스를 빌드하고 배포해야합니까?
• 기능이 이미 병합 된 후 릴리스에서 제외되어야하는 기능을 처리하는 현명한 방법이 있습니까? 이 경우 별도의 개발 브랜치가 실제로 이점이 있습니까? 어쨌든 커밋을 되돌 리거나 다시 되 돌리면 대부분 수동으로 커밋됩니다.

이럴 당신이 직면하고있는 문제는 당신이 시작 가난한 지점 전략의 단지 부작용은 다음과 같습니다 효과적으로에 새로운 개발 없어야하고 develop(즉, 무엇을 향해 수렴 미래 생산 코드) 를 통해 현재 에 생산 코드 master. 일반적으로 미래 코드가 현재 코드와 다르기 때문에 요구 사항과 문제가 모순됩니다.

• 합병 후 본 회귀 - 새로운 개발 생산 불안정 develop에를master
• 미래의 개발 아래로 생산 감속 안정화 - 당신은 안정을 필요 develop로 병합을 위해 충분한을 만들기 위해master

삭제 develop는 많은 도움이되지 않습니다. 문제를 해결하는 것이 아니라 문제의 develop특정 부분을 로 옮기는 것 master입니다.

더 나은 접근 방식은 현재 / 미래 개발의 배후로 프로덕션을 이동하여 향후 릴리스의 개발에 대한 간섭을 방지하기 위해 분기 모델이란 무엇입니까?의 이미지에 설명되어 있습니다 . :

트렁크에서 일어나는 일이 아니라 위 이미지의 릴리스 브랜치만을 언급하고 있습니다.

어떻게 이것이 당신을 위해 작동합니까?

• develop당신이 바란대로 지점 사라져은 속으로 흡수master
• master분기 개발이 더 속도 제한 (그것의 함께 발생하는 곳이다, 트렁크입니다 결코 생산에 합병 없음).
• 생산은 생산 품질에 충분히 근접한 것으로 간주 release되는 master라벨 / 태그 에서 가져온 하나 이상의 지점입니다 (필요한 경우 나머지 할 일 항목의 짧은 목록을 해당 지점에서 처리 할 수 ​​있음). 이 지점은에서 직접 핫픽스 및 / 또는 체리 픽 수정을 master받을 수 있으며 다른 지점 과 병합 되지 않습니다.master
• 핫픽스는 release분기에 직접 커밋

핫픽스가 프로덕션 버전에만 적용되고 핫픽스 master에는 직접 적용되지 않는 경우 release지점에 직접 커밋됩니다 . 둘 다에 적용되는 경우 일반적으로 지점 master에 대한 첫 번째 및 체리 피킹 / 더블 커밋에 최선을 다합니다 release.

이제 master현재 release분기가 제거 된 지점을 지나는 내용을 살펴보면 두 가지 옵션이 있습니다.

• 그들이 기반으로 할 것을 제외하고, 여러분과 같은 기능을 가지 오늘 않습니다 계속 master하지 develop. 그것들을 핫픽스로 변환하는 것은 가능합니다- release대신에 해당 브랜치 로 리베이스해야합니다.master
• 지속적인 통합으로 전환하고 점진적으로 감소하는 기능 분기를 포함하여 점진적인 방식을 포함하여 향후 언제든지 수행 할 수있는 이점을 활용하십시오.

이 접근 방식이 마음에 들면 다음과 같이 현재 위치에서 얻는 방법입니다.

• 릴리스 이름 지정 전략을 설정하십시오.
  • 같은 이름의 출시 지점을 가질 수 없습니다
  • 프로덕션 릴리스 브랜치를 리베이스하거나 동기화 할 수는 없습니다 (실제로는 안 됨).
• 명명 전략에 따라 즉시 releaseX지점을 가져옵니다.master
• 커밋이 중단되는 것을 막 으면 develop곧바로 진행됩니다 master.
• 병합 develop에master
• 개발자에게 master대신 작업 공간을 리베이스하도록 지시하십시오 develop.
• master커밋을 위해 열린다
• develop원하는 경우 삭제 (또는 참조를 위해 영구적으로 잠 그거나 읽기 전용으로 두십시오)

마스터 브랜치를 꺼내고 (나중에 원하는 경우 팀을 혼동시키기 위해 개발의 이름을 마스터로 바꿀 수 있음) 개발 또는 핫픽스 브랜치의 릴리스에 태그를 사용한다고 가정 해 봅시다. 지점을 가져 왔지만 차이점은 구문의 변화 일뿐입니다. 변화를위한 변화.

이제 잠긴 마스터 브랜치를 유지하면서 실제로 개발을 시작한다고 가정 해 봅시다. 코드 통합이 느려질 수 있으며, 특히 출시 날짜에 가까운 기능 분기에서 더 오래 분리됩니다. 이렇게하면 매번 병합하기가 어려워지고 프로세스 속도가 느려집니다.

당신이 정한 제약 내에서 나는 그러한 변화를 일으키는 긍정적 인 영향을 보지 못합니다. 제약 조건, 특히 첫 번째 제약 조건을 완화해야합니다.

이미 각 pull-request 및 hot-fix 브랜치에서 코드를 빌드하고 테스트하고 있습니다. 즉, 전체 요청에서 보류 요청에 보류중인 모든 분기의 합계는 가상 develop분기입니다.

테스트 환경에서 시스템을 작성할 수 있으며 여러 풀 요청이 기본 저장소에 공개되지 않은 임시 분기로 선택됩니다. 이 분기는 master몇 가지 추가 풀 요청 이 포함 된 테스트 환경을 통합하는 데 사용 되지만 테스트가 완료되면 더 이상이 분기를 사용할 수 없습니다.

에서 릴리스를 만들 때 master일반적으로 해당 릴리스에 태그를 만듭니다. 이후 핫픽스는 해당 태그를 사용하여 에지 master가 이미 앞서 있어도 배포 할 새 핫픽스 분기를 만들 수 있습니다 . 이 핫픽스 분기에서는 부 릴리스에 태그를 지정하고 변경 사항이에 병합되었는지 확인하십시오 master.

릴리스에서 병합 된 기능을 제거하는 것은 git과 관련이 없습니다. 이를위한 가장 좋은 메커니즘 git revert은 병합 커밋에 사용 하는 것 입니다. 그러나 이로 인해 이러한 기능 / 변경 사항을 되돌릴 수 없으며 기록이 흐려집니다.

코드 배포 및 기능 릴리스를위한 분리를 처리하는 훨씬 더 좋은 방법은 기능 플래그 입니다. 개발자가 코드 자체에서 특정 조건 뒤에 기능을 숨길 수있는 경우 코드를 배포 할 수 있지만 기능을 끌 수 있습니다. 이것은 별도의 주제이지만 이에 관한 많은 정보가 있습니다 (devops.SE의 Q & A 포함).

@ dan-cornilescu는 귀하의 특정 문제에 대해서는 잘 설명하고 있지만, 트렁크 기반 개발 (Continuous Delivery, Lean Enterprise 및 The DevOps Handbook에서 언급)에 대한보다 일반적인 사례는 다음과 같습니다. https://trunkbaseddevelopment.com/