우리는 git-flow로 구현 된 성공적인 Git 분기 모델 을 채택하려고합니다 . 이제 우리는 적어도 두 개의 릴리스 브랜치를 작업하고 있습니다. 하나는 최신 안정 릴리스 용이고 다른 하나는 다음 ( "미리보기") 릴리스 용입니다. 내가 이해하지 못하는 것은 모든 릴리스가 마스터 에게 "선형화" 되고 태그가 지정된 것처럼 보이는 이유 입니다. 릴리스 브랜치에서 릴리스에 태그를 지정하지 않는 이유는 무엇입니까? 왜 주인 인가? 아니면 왜 개발 브랜치를 사용하고 마스터 를 사용하지 않습니까?
답변:
git-flow 모델에서 "최신 릴리스"버전은 실제로에 매핑되는 master반면 "미리보기 릴리스"는 git-flow release브랜치에 매핑됩니다 . 실제 릴리스가 발생할 때 분기되어 develop최종적으로 병합됩니다 master. 그러면 이것이 "최신 릴리스"가되고 일반적으로 git-flow hotfix브랜치를 사용하여 해당 릴리스의 버그만 수정합니다 . 이렇게하면 master항상 최신 릴리스 버전의 가장 안정적인 상태를 나타냅니다.
이전 릴리스의 버그를 수정하거나 거기에서 다른 개발을 수행하려는 경우 support적절한 커밋에서 분기를 포크합니다 master( 모든 버전이 생성됩니다). support브랜치는 여전히 실험적 이며 ( 문서에 따르면 ) 잘 문서화되어 있지 않습니다. 그러나 명령 줄 도움말에서 볼 수 있듯이 :
usage: git flow support [list] [-v]
git flow support start [-F] <version> <base>
이러한 분기는 방금 시작되었으며 다시 병합 할 의도가 master없습니다 develop. "고대"릴리스에 대한 수정 사항이나 "고대"릴리스에 구현되도록 고객이 요청한 기능은 master. 여전히 생각한다면 메인 개발 라인 ( master및로 develop표시됨)에 수정 사항을 이식하려면을 시작하고 hotfix변경 사항을 선택하고 hotfix.
git flow support실험용으로 표시되지 않았습니다.
대부분은 가지를 너무 많이 강조하는 정신적 모델처럼 보입니다. 동의합니다. 릴리스 한 커밋을 마스터로 다시 병합하는 대신 태그 만 지정할 수 있습니다.
그래도 그림은 예쁘다. 모든 것을 마스터로 다시 병합하면 버전 태그가 그래프 전체에 흩어져있는 대신 시간적 순서로 릴리스가 명확하게 표시됩니다.
하지만이 모델은 이전 릴리스의 버그 수정에는 작동하지 않는다고 생각합니다. 깔끔한 주문을 엉망으로 만듭니다.
귀하의 질문에 답하기 위해 : 이것은 어떤 경우에는 단순한 정신 모델을 만드는 일련의 규칙이라고 생각합니다. 모든 규칙이 순전히 기술적 인 관점에서 의미가있는 것은 아니지만 그렇다고해서 나쁜 것은 아닙니다. 정신 모델은 인간에게 좋습니다.
support브랜치는 이전 릴리스에서 버그 수정을 위해 설계되었지만 여전히 '실험용'으로 레이블이 지정되어 있습니다.
개인적으로 언급 된 git-flow가 너무 복잡하다고 생각합니다.
GitHub를 사용하는 경우 GitHub flow(Scott Chacon이 설명한대로) 시도해보십시오 .
특히 여러 기능에 대한 공동 작업, 코드 검토에 유용하며 .NET Framework를 사용하여 지속적 통합 솔루션과 결합 할 수 Commit Status API있습니다.
업데이트 : The GitHub Flow ™의 새로운 공식 웹 사이트가 있습니다.
업데이트 2 : The GitHub Flow ™에 대한 새로운 공식 (및 단순화 된) GitHub 가이드 : https://guides.github.com/introduction/flow/
master작업 연대의 변칙 인에 병합 될 수 없을 것 입니다.
support브랜치의 용도입니다. 그러나 당신이 옳습니다. 그러한 릴리스가 master모든 프로덕션 릴리스를 보유해야하는 으로 다시 병합되지 않는 것은 참으로 예외입니다 .
제 경우에는 기본은 동일하지만 각 버전에는 몇 가지 다른 기능이있는 동일한 소프트웨어의 두 가지 버전이 있습니다.
그래서 두 개 worktree를 만듭니다. 즉, 마스터 옆에 관련 장기 실행 분기를 두 개 만듭니다.
$git worktree add -b version-silver ..\version-silver master
$git worktree add -b version-gold ..\version-gold master
다음이 있습니다.
$git branch
master # base stuff here
version-silver # some normal features
version-gold # some better features
하나의 저장소가 있지만 위의 각 분기에 대해 서로 옆에 3 개의 별도 폴더가 있습니다. 그리고 마스터에서 일반적인 변경을 수행하십시오. 그런 다음 다른 두 버전과 병합하십시오.
cd master
vim basic.cpp
git add .
git commit -m "my common edit on basic.cpp"
cd ..\version-silver
vim silver.cpp
git add .
git commit -m "my specific edit on silver.cpp"
git merge master # here i get the basic.cpp latest changes for silver project
cd ..\version-gold
git merge master # here i get the basic.cpp latest changes for gold project
각 버전의 특정 변경 사항도 해당 폴더에 저장되며 각 프로젝트의 작업은 격리되어 IDE가 혼동되지 않습니다.
도움이 되었기를 바랍니다.
@Mot에 완전히 동의합니다.
같은 질문을 듣게되어 기쁩니다.
우리 팀은 또한 성공적인 분기 모델보다 더 많은 범용 분기 모델을 찾고 있었습니다. 예를 들어 안정적인 릴리스를 위해 kernel.org에서 수행하는 것처럼 별도의 * .git 저장소에서 release- * 분기를 지원하기위한 추가 저장소를 도입하지 않는 것이 주된 아이디어입니다. 하지만 kernel.org는 다운로드 크기를 최소화하기 위해 수행합니다.
나에게는 마스터 를 개발의 메인 라인으로 사용 하는 것이 더 깨끗한 것 같습니다 .
또한 릴리스-* 모델 을 마스터로 병합 하고 나중에 아이디어로 태그를 지정하는 데 약간의 충돌이 있습니다.
Git 후크 스크립트를 사용하여 마스터에 커밋이있을 때마다 소프트웨어를 자동으로 빌드하고 프로덕션 서버에 배포합니다.
원인 (병합 및 태그) 마무리 원자 거래되지 않습니다 :
$ git checkout master
Switched to branch 'master'
$ git merge --no-ff release-1.2
Merge made by recursive.
(Summary of changes)
$ git tag -a 1.2
그리고 git hook이 자동 버전 관리 지원으로 빌드를 시작하면 :
$git describe --tags --long >.ver
다음을 위해 잘못된 버전을 만들 수 있습니다.
$ git merge --no-ff release-1.2
성공적인 버전의 버전 관리는 일부 범프 버전 프로세스를 도입 하지만 자동은 아닙니다.
요약하자면-릴리스 용 브랜치 모델에 도입 한 주요 차이점-* 병합 및 태그 지정은 다음과 같습니다.-브랜치 생성시 릴리스 태그 지정-향후 유지 관리를 위해 릴리스의 브랜치 유지
마스터 브랜치는 항상 프로덕션 코드베이스를 나타내야하므로 프로덕션 릴리스 직후에 코드를 항상 마스터로 다시 병합합니다.
태깅은 프로덕션 릴리스에 들어간 정확한 코드를 "기억"하는 데 사용되므로 나중에 돌아가서 문제가 발생하면 코드를 분석 할 수 있습니다.
이론적으로는 마스터로 다시 병합 한 후 릴리스 브랜치 또는 마스터 브랜치에서 코드에 태그를 지정하는 것은 중요하지 않습니다. 개인적으로 릴리스 브랜치의 코드에 태그를 지정하는 것을 선호합니다. 이것은 빌드 / 릴리스에 정확히 들어간 코드이기 때문입니다 (병합에 문제가 발생할 수 있다고 가정).
개발 분기 개념의 문제는 단일 스레드라는 것입니다. 이 스레드에서 Brendan은 개발 분기 개념과 관련하여 사용할 수있는 전략을 언급했습니다.