"개발"지점이 사라지는 추세

최근 GitHub에서 인기있는 프로젝트를 살펴본 결과 develop분기 가 없다는 것을 알았습니다 . 실제로 GitHub Flow 가이드 에는 언급되어 있지 않습니다. 내 이해에서, master항상 완전히 안정되고 생산을 반영해야합니다. 개발자가 기능을 가지 작업을 한 다음에 그 병합하는 경우 master그들이 할 때를, 그 기능 / 수정에 병합되고 일정 기간이 뜻 master과 master지점이 실제로 생산보다 최신 버전이.

팀이에서 기능 / 수정 브랜치를 생성 develop하여 다시 병합 한 다음 다음 버전이 완전히 출시 될 준비가되면 develop병합되고 master태그가 생성 되도록하는 것이 더 합리적이지 않습니까? 사람들이에 합병 master하고 master분기 코드베이스가 크게 변경 되어 수정하기 어려운 버그가보고되는 경우를 상상해보십시오 . 그런 다음 개발자는 사용자에게 다음 릴리스까지 문제가 해결 될 때까지 기다리라고 지시하면됩니다.

편집 :이 질문은 "분기 또는 분기하지"와 다릅니다. 특히 개발 브랜치를 사용하지 않는 사람들과 그 주변 이유를 다루는 이유는 오랫동안 모범 사례로 선전되었습니다.

하루에 여러 번 통합이 이루어지는 CI 사고 방식에서 비롯됩니다 .

두 가지의 장단점이 있습니다.

우리 팀에서는 개발 지점을 포기했지만 추가 이점은 없지만 몇 가지 단점이 있다고 생각했기 때문에 개발 지점을 포기했습니다. 다음과 같은 단점을 보완하기 위해 CI 소프트웨어 (Teamcity)를 구성했습니다.

1. 특정 커밋 배포를 활성화합니다. 다시 말해 지점을 배포하지 않습니다. 커밋을 배포합니다.
2. 핫픽스 / 접두사로 시작하여 마스터 또는 분기를 배포 할 수 있습니다.

이것이 작동하는 이유는 모든 풀 요청에 잠재적으로 해제 가능한 코드가 포함되어 있기 때문에 모든 커밋을 마스터에 배포한다는 의미는 아닙니다.

우리가 개발 브랜치를 포기한 주된 이유는 그것이 실제로 포함되어있는 것을보기에는 너무 크고 시간이 많이 걸리는 경향이 있기 때문입니다. 만약 우리가 조금 이른 것을 배포했다면 핫픽스 브랜치를 분기하고 직접 배포하면됩니다.

릴리스 할 프로세스가 복잡하고 심각한 릴리스 후보가 필요한 경우 개발 브랜치가 더 중요합니다.

예를 들어, 자동차의 펌웨어 인 소프트웨어를 작성한다고 가정하십시오. 이것은 ... 수정하기 쉽지 않으며 모든 릴리스는 실제 하드웨어에서 실행되는 포괄적 인 비 CI / 통합 테스트 세트를 가질 것입니다.

이 경우 비 마스터 브랜치 (예 : "개발")에서 "릴리스 후보"를 분리하는 것이 더 합리적 일 수 있습니다. 이를 통해 해당 테스트를 실행하는 팀은 기능을 병합 할 지점을 가질 수 있습니다.

Webapp 또는 기타 쉽게 업데이트되는 소프트웨어에는이 제약 조건이 없습니다.

그러나 다음 사항에 유의하십시오.

• github의 많은 (대부분?) 프로젝트에는 이러한 종류의 제약이 없습니다.
• 주요 "마스터"는 같은 목적으로 사용됩니다
• "PR과 마스터 만들기"의 작업 흐름은 "이 리포지토리에서 즉시 알 수없는 지점에 대해 PR을 만드는 것"보다 훨씬 보편적입니다.

프로젝트에서 본 두 가지 철학이 있으며 선택은 맛의 문제라고 생각합니다.

1. 생산 마스터로 '마스터'를 지정하고 '개발'지점에서 개발하십시오.

2. '마스터'로 개발하고 안정적인 프로덕션 릴리스를 위해 다른 이름의 브랜치를 보유하십시오. 프로젝트에 한 번에 여러 개의 릴리스 분기가있는 경우 (예 : 현재 선호되는 릴리스는 릴리스 -1.8이지만 여전히 릴리스 -1.7도 유지 보수하는 경우) 더 의미가 있습니다.

둘 다 일반적인 접근 방식이며 장단점이 있습니다.

생산 릴리스에 태그를 지정할 수 있으므로 릴리스 된 상황을이 목적으로 전체 브랜치에 바치지 않고 항상 재현 할 수 있습니다.

마스터를 릴리스 할 수없는 시점에 프로덕션에서 중요한 버그가 발견되면 태그를 체크 아웃하고 새로운 "release-for-release-1.2.0"분기를 시작하기가 쉽습니다. 그러나 그것은 드문 일입니다.

대부분의 웹 응용 프로그램에서 마스터는 마지막 릴리스 이후로 변경되었지만 크게 크게 바뀌지 않았으므로 수정 사항이있는 마스터에서 새 릴리스를 간단하게 수행 할 수 있습니다. 어쨌든 매우 자주 릴리스하는 데 도움이됩니다.

개발자가 기능을 가지 작업, 그들은이 완료되면 다음 마스터로 사람들을 통합하는 경우, 그 기능 / 수정에 병합되고 일정 기간이 뜻 master과 master지점이 실제로 생산보다 최신 버전이.

...

사람들이 마스터로 직접 병합하고 마스터 브랜치 코드베이스가 크게 변경되어 수정하기 어려운 버그가보고되는 경우를 상상해보십시오.

그것은 Github Flow가 아닙니다.

링크에 따라 Github Flow 배포 / 병합 프로세스입니다.

배포

풀 요청이 검토되고 지점이 테스트를 통과하면 변경 사항을 배포하여 프로덕션 환경에서 확인할 수 있습니다. 지점에서 문제가 발생하면 기존 마스터를 프로덕션에 배포하여 지점을 롤백 할 수 있습니다.

병합

프로덕션 환경에서 변경 사항이 확인되었으므로 이제 코드를 마스터 브랜치로 병합해야합니다.

(엠파 시스 마인)

다시 말해, master생산보다 앞서서는 안됩니다. 마찬가지로 master모든 항목은 에 병합 되기 전에 검토, 테스트 및 프로덕션으로 롤아웃되기 때문에 항상 발견 가능하고 버그가없는 안정적이고 릴리스 가능한 상태에있게 됩니다 master.

내가 본 문제는 Git / Hub 흐름 배포 / 병합은 한 번에 하나의 기능이 개발 / 테스트 / 병합 / 배포되고 있다고 가정한다는 것입니다. 종종 내 경험상 그렇지 않습니다. 기능을 한 번에 병합하면 회귀 문제가 발생할 가능성이 높아집니다. 기능이 마스터 및 프로덕션에 병합 된 후에 만 ​​가능합니다.

여러 기능을 테스트하고 여러 기능을 병합하고 배포하는 방법이 필요합니다. qa / uat에 배포되는 '번들 브랜치'(테스트 준비 기능 브랜치가 병합 된 마스터에서 만든 브랜치)를 사용하고 있습니다. uat 중 수정은 기능 분기에서만 발생하며 번들 분기에 다시 병합됩니다. 번들 분기의 하위 섹션이 승인 된 후 번들 내에서 승인 된 기능 만 마스터에 풀 요청되며주기는 연속적입니다.

나는 이것을 Gitflow와 함께 사용하지만 GitHub 흐름에 사용하려고 생각합니다. QA / UAT는 한 번에 많은 기능이 문제가 된 것으로 보입니다. GitHub 흐름의 또 다른 문제는 모든 sr 개발자를 가정한다는 것입니다. 항상 그런 것은 아닙니다.

오히려 단순화로 인해 GitHub 흐름을 사용하고 싶습니다. 기능과 같은 번들을 사용하면 더 나은 준비가 될 것이라고 생각합니다. 번들이 릴리스와 유사하지는 않습니다. 그러나 나는 여전히 이것에 대해 숙고하고 있습니다.

또 다른 문제는 풀 요청 프로세스가 마스터로 병합하기 전에 마지막에 발생한다는 것입니다. 그러나 때로는 비즈니스 QA 테스트 전에 코드 검토를 원하기 때문에 병합하기 전에