git-flow 대 github-flow의 장단점은 무엇입니까? [닫은]

최근 GitLab을 사용하기 시작했습니다.

현재 "중앙 집중식"워크 플로를 사용하고 있습니다.

우리는 github-flow로 이동을 고려하고 있지만 확인하고 싶습니다.

git-flow 대 github-flow 의 장단점은 무엇입니까 ?

Nicholas Zakas 가 " 회사 내부의 GitHub 워크 플로 "에 대한 기사 에서 GitMinutes 에피소드 17에서 논의한대로 :

Git-flow 는 Vincent Driessen이 만든 Git의 변경 사항을 관리하기위한 프로세스이며 해당 흐름을 관리하기위한 일부 Git 확장 과 함께 제공됩니다 .
자식 흐름 뒤에 일반적인 생각은 항상 다른 목적을 위해 각각 존재하는 몇 가지 별도의 지점을 가지고하는 것입니다 : master, develop, feature, release,와 hotfix.
기능 또는 버그 개발 프로세스는 최종적으로 출시되기 전에 한 분기에서 다른 분기로 이동합니다.

일부 응답자는 git-flow일반적으로 사용한다고 답했습니다 .
일부는 시작하여 git-flow멀어졌습니다.

이동하는 주된 이유는 git-flow프로세스가 연속 (또는 거의 연속) 배포 모델에서 처리하기 어렵 기 때문입니다.
일반적인 느낌은 git-flow릴리스가 몇 주에 한 번 수행되는보다 전통적인 릴리스 모델의 제품에 적합하지만 하루에 한 번 이상 릴리스 할 때이 프로세스가 상당히 중단된다는 것 입니다.

요컨대 :

가능한 한 단순한 모델 (GitHub 흐름이있는 경향이 있음)으로 시작하고 필요한 경우 더 복잡한 모델로 이동합니다.

" A simple git branching model " 에서 GitHub-Flow 를 기반으로 한 간단한 워크 플로에 대한 흥미로운 그림을 볼 수 있으며 주요 요소는 다음과 같습니다.

1. master 항상 배포 가능해야합니다.
2. 기능 분기 (풀 요청 + 병합)를 통해 이루어진 모든 변경
3. 갈등을 피 ​​/ 해결하기 위해 리베이스; 에 합치다master

실제로 더 완벽하고 강력한 워크 플로 는 gitworkflow (한 단어)를 참조 하세요 .

모든 모델이 차선책이기 때문에 모든 사람이 따라야하는 은색 총알 워크 플로는 없습니다. 즉, 아래 사항을 기반으로 소프트웨어에 적합한 모델을 선택할 수 있습니다.

프로덕션의 여러 버전 -Git-flow 사용

코드에 여러 버전이있는 경우 (예 : 운영 체제, Office 패키지, 사용자 지정 응용 프로그램 등과 같은 일반적인 소프트웨어 제품) git-flow를 사용할 수 있습니다. 주된 이유는 다음 버전을 개발하는 동안 프로덕션에서 이전 버전을 지속적으로 지원해야하기 때문입니다.

프로덕션 단순 소프트웨어의 단일 버전 -Github-flow 사용

코드에 항상 하나의 버전 만있는 경우 (예 : 웹 사이트, 웹 서비스 등) github-flow를 사용할 수 있습니다. 주된 이유는 개발자를 위해 복잡한 작업이 필요하지 않기 때문입니다. 개발자가 기능을 완료하거나 버그 수정을 완료하면 즉시 프로덕션 버전으로 승격됩니다.

프로덕션의 단일 버전이지만 매우 복잡한 소프트웨어 -Gitlab-flow 사용

Facebook 및 Gmail과 같은 대규모 소프트웨어의 경우 프로덕션에 들어가기 전에 CI / CD> 도구를 실행할 수있는 지점과 마스터 지점간에 배포 지점 을 도입해야 할 수 있습니다 . 아이디어는 수백만 명의 사람들이 사용하기 때문에 프로덕션 버전에 더 많은 보호 기능을 도입하는 것입니다.

나는 1 년 넘게 git-flow 모델을 사용해 왔으며 괜찮습니다.

그러나 실제로는 응용 프로그램을 개발하고 배포하는 방법에 따라 다릅니다.

개발 / 배포 흐름이 느린 애플리케이션이있을 때 잘 작동합니다.

하지만 예를 들어 GitHub와 같이 개발 / 배포 흐름이 빠른 애플리케이션이 있고 매일 배포하고 때로는 하루에 여러 번 배포합니다.이 경우 git-flow는 제 생각에 모든 것을 느리게하는 경향이 있으며 저는 GitHub를 사용합니다. 흐름.

고려해야 할 또 다른 사항은 git-flow가 표준 git이 아니기 때문에 그렇게 할 수 있다는 것입니다. 그리고 제가 말할 때 실제로는 그것을 모르는 개발자를 발견하고 학습 곡선이 있습니다. 일을 엉망으로 만들 기회. 또한 위에서 언급했듯이 누군가가 git-flow를 더 쉽게 사용할 수 있도록 스크립트 세트를 개발 했으므로 모든 명령을 기억할 필요가 없으며 명령을 지원할 수 있지만 실제 흐름을 기억하는 것이 작업입니다. , 저는 개발자가 그것이 핫픽스인지 기능인지 알지 못하거나 흐름을 기억하지 못하고 문제를 해결하는 최악의 경우를 두 번 이상 보았습니다.

Mac 및 Windows SourceTree 용 git-flow를 지원하는 GUI가 하나 이상 있습니다 .

요즘에는 단순하고 관리하기 쉽기 때문에 GitHub 흐름에 더 의존하고 있습니다. 또한 "초기 배포 자주 배포"때문에 ...

도움이 되었기를 바랍니다