오래 실행되지 않은 릴리스되지 않은 코드에 대한 Git 분기 전략

우리 팀에서는 개별 작업 단위 (스토리) 외에도 더 오래 실행되는 작업 테마 (Epics)를 가지고 있습니다. 여러 이야기가 서사시를 만듭니다.

전통적으로 우리는 각 스토리마다 기능 브랜치를 가지고 있었고 QA를 통과하면 마스터로 바로 통합했습니다. 그러나 Epic이 "기능 완료"로 간주 될 때까지 Epic에서 완성 된 스토리의 릴리스를 보류하고 싶습니다. 우리는 전체 Epic이 닫힐 때만 이러한 기능을 프로덕션에 릴리스합니다. 또한 야간 빌드 서버가 있습니다. 모든 비공개 스토리 (불완전한 Epics의 일부를 포함하여)가이 야간 서버에 자동으로 배포되기를 원합니다.

이를 위해 레포를 관리하는 방법에 대한 제안이 있습니까? 나는 "에픽 브랜치"를 도입하는 것을 고려했는데, 여기서 우리는 폐쇄 된 스토리를 마스터에 직접 전달하는 대신 관련 에픽 브랜치에 병합했습니다.

서사시 지점을 오랫동안 열어두면 발생할 수있는 병합 충돌에 대해 걱정합니다.
야간 빌드에는 모든 서사시 분기를 "야간 빌드"분기로 병합해야합니다. 다시 말하지만 병합 충돌이 발생할 수 있으며 이는 자동으로 수행됩니다.

— 시타 티
소스

답변:

간단한 제안 : 그렇게하지 마십시오.

git 브랜치는 여기 에서 설명 하고 https://blog.newrelic.com/2012/11/14/long-running-branches-considered-harmful/에 설명 된대로 장기 실행 코드를위한 것이 아닙니다 . 브랜치는 개별 개발자가 일상적으로 커밋을 구성하는 데 사용되는 일시적인 것으로 가장 잘 처리됩니다. 따라서 프로젝트 관리자 (최종 사용자는 물론)가 자신에게 문제가있는 무언가에 해당하는 이름을 가지고 있다면 뭔가 잘못하고있는 것입니다.

권장 토픽은 기능 토글 또는 분기 별 요약 과 지속적으로 통합하여 다음 을 보장하는 것입니다.

모든 코드는 항상 통합됩니다 (적어도 매일, 바람직하게는 더 자주)
무엇됩니다 배치하는 것은 명시 적으로 제어 받고있다.

— 소루
소스

나는 이것이 대중적인 대답이라고 생각했다! 이것에 대한 나의 주요 관심사는 항상 '실시간'과 '다음'구현을 유지 관리하는 오버 헤드이며, 또한 기능을 개발하는 개발자는 변경 사항을 업그레이드 (/ 바꾸기)하는 대신 새로운 병렬 기능으로 변경 사항을 빌드하는 것을 미리 알아야합니다. 기존 기능. 팀에서 더 큰 사고 방식을 요구한다고 생각합니다.

— Sitati

코드 를 개발 하기 위해 브랜치를 사용하는 것이 좋습니다. 코드 를 저장 하는 데 절대로 사용하지 마십시오 . 따라서 작업이 30 분 수정 또는 2 주 재 작업인지 확실하지 않은 경우 지점에서 시작하십시오. 아는 즉시 추상화 / 토글로 병합 또는 리팩토링 한 다음 병합하십시오.

— soru

@Sitati : 지난 4 개월 동안 기능 지점에있는 일부 코드를 병합했습니다. 그 동안 develAutotools에서 CMake로 전환하고 Travis CI를 도입하고 코드를 리팩터링했습니다. 결국 새로운 기능을 이해하고 devel병합하는 것보다 수동으로 적용하는 것이 더 쉬웠 습니다. 우리는 또한 새로운 석사 과정 학생들이 논문을 시작할 때 시작된 지점에서 새로운 기능을 개발하도록했습니다. 일년 후 그들은 그것을 밀고 다시 병합하려는 노력이 없었기 때문에 매일 병합하기가 더 어려워졌습니다.

— Martin Ueding

링크 된 블로그 게시물은 이제 5 살입니다. 나는 기능 토글이 싫어. 장기 브랜치, 메인에서 피처 브랜치로 정기적으로 병합 및 장기 피처 브랜치에 지속적 통합을 추가하는 데있어 무엇이 문제입니까?

— Jason Kelley

CI는 도구가 아닌 프로세스의 이름입니다. 기능 분기가 둘 이상있는 경우 일반적으로 서로 지속적으로 통합되지 않습니다. 즉, 문제를 빨리 발견하기보다는 나중에 찾는 것을 의미합니다.

— soru

나는 이것이 매우 일반적인 문제라고 생각하며 기능이 이전보다 코딩 된 후에 릴리스에 포함 할 기능을 선택하는 것으로 요약합니다.

예.

제품 v2의 기능 A, B 및 C가 있습니다. B와 C는 관련되어 있습니다 .C도 끝나지 않으면 B를 놓지 않습니다.

나는 기능에 대해 동시에 3 명의 개발자가 모두 일하고 있습니다.

석재 출시 날짜 D를 설정했습니다

B는 완성되고 합병되고, A는 완성되고 합병됩니다. C는 지연됩니다 ... 어떻게해야합니까?!

이 문제에 대한 기술적 해결책이 없다고 생각합니다. 기능 A 만 포함 된 테스트되지 않은 버전의 제품을 릴리스하려고합니다. 가능한 모든 기능 조합을 병합하고 테스트하지 않는 한 항상 가능합니다.

해결책은 더 인간적인 것입니다. 출시 날짜를 놓쳤으며 다시 푸시해야합니다.

— 이완
소스

이것은 까다로운 문제이지만 많은 사람들이 직면하는 문제입니다. Gitflow 설정을 시작점으로 사용하는 것이 좋습니다.

개발-> 새로운 작업중인
마스터-> 테스트가 필요한 완성 된 프로덕션 프로덕션-> 프로덕션에 게시 된 항목.

사소한 (더 짧은) 기능에서 나는 개발에서 브랜치를 만들고 거기서 작업을 수행 한 다음 브랜치를 다시 개발로 병합합니다.

주요 (장기) 기능에서 개발에서 분기를 만들고 해당 분기에서 더 작은 분기를 만든 다음 첫 번째 분기로 다시 병합합니다. 주요 기능이 완성되면 개발 지점으로 돌아갑니다.

정기적으로 (프로젝트에 따라) 개발을 다시 마스터로 병합하고 테스트주기를 시작합니다. 테스트에서 수정 프로그램이 나오면 마스터 브랜치 (하위 브랜치)에서 수행됩니다. 그리고 테스트하는 동안 마스터 지점에서 개발을 계속할 수 있습니다.

마스터는 언제든지 개발에 병합되어야하며 개발은 장기 하위 지점 중 하나로 병합되어야합니다.

마스터는 항상 이론적으로 생산 준비가되어 있어야합니다. 개발은 항상 이론적으로 생산 준비가되어 있어야합니다. 테스터가 테스트 할 견고한 기능 세트를 제공하는 데 차이가있는 유일한 이유입니다.

준비가되면 테스트 된 마스터 커밋이 프로덕션으로 병합되고 프로덕션의 배포는 해당 지점에서 발생합니다. 그런 다음 비상 상황에서 수행해야하는 HOTFIX는 마스터로 병합하지 않고도 생산 지점에서 수행 할 수 있습니다 (테스트되지 않은 많은 변경 사항이있을 수 있음).

내 보통 나무는

 LongTerm -> Development -> Master -> Production    
 LongTerm <- Development      |            |  
     |       Development -> Master         |  
 LongTerm <- Development -> Master         |  
             Development <- Master         |  
                            Master -> Production

단일 변경이 몇 시간 이상 걸리지 않아야한다는 것이 나의 일반적인 규칙입니다. 그렇다면 더 작은 변경이 필요합니다. UI 재 작성과 같은 거대한 기능인 경우 정상적인 개발을 동시에 계속할 수 있도록 장기적으로 진행됩니다. 장기 분기는 일반적으로 로컬 분기이며 개발, 마스터 및 프로덕션은 원격 분기입니다. 하위 지점도 로컬입니다. 이것은 장기적인 기능 세트에서 git의 유용성을 잃지 않고 다른 저장소를 깨끗하게 유지합니다.

그러나 장기 브랜치의 존재는 드물다는 점에 주목하고 싶습니다. 일반적으로 모든 작업은 개발 중입니다. 정상적인 개발 작업을 수행 할 수 있어야하는 기능 (세트)이 오래 걸릴 때만 LongTerm 분기를 사용합니까? 함께해야 할 일련의 변경 사항 인 경우 모든 작업이 완료 될 때까지 마스터로 병합하지 않습니다.

— 코트
소스

"주요 (장기) 기능에서 개발에서 분기를 작성"-프로덕션 지점에서 새 기능 (개발) 분기를 작성하지 않아야합니까? 프로덕션 브랜치는 릴리스 준비 코드입니다.

— robotron

아니요, 생산은 이미 릴리스되었으며 마스터는 생산보다 앞서고 개발은 마스터보다 앞서 있습니다. 이미 주문한 코드를 작성하지 않는 경우 총 주문에 세금 추가와 같은 새로운 기능은 의미가 없습니다.

— coteyr

그러나 dev에서 나중에 분기하여 다시 병합하면 해당 분기 (및 결과적으로 마스터 및 프로덕션)가 분기되지 않을 때 다른 사람이 작성한 모든 dev 변경 사항을 통합하지 않습니까? 이러한 변경 중 일부는 품질 관리 승인을받지 못할 수 있습니다. 아마도 릴리스 관리를위한 다양한 접근 방식에 대해 이야기했을 것입니다.

— robotron

예, 그게 요점입니다. QA는 마스터의 특정 SHA에 대해 테스트하지만 개발자는이를 유지할 수 없습니다.

— coteyr

"마스터의 특정 SHA에 대한 QA 테스트"-> QA는 각각의 새로운 기능을 독립형으로 테스트합니까? 팀이 직면 한 일반적인 시나리오를 살펴 보겠습니다. 동일한 코드베이스에 두 개의 장기 실행 프로젝트가 있다고 가정 해 보겠습니다. 프로젝트 A는 지난 달 QA에 있고 다른 달에는 QA가됩니다. 프로젝트 B는 지난 6 개월 동안 개발 중이 었으며 현재 QA를 준비 중입니다. 프로젝트 A는 마스터로 병합되며 수많은 미묘한 비즈니스 규칙 오류로 인해 생산 준비가되지 않았습니다. 프로젝트 B를 어떻게 처리합니까? 상호 작용을 확인하려면 A와 B를 함께 테스트해야합니다 (B는 병합 중에 충돌을 일으키지 않습니다).

— robotron