여러 병렬 릴리스 분기가있는 Git 흐름 및 마스터

여러 병렬 릴리스 분기가있는 Git 흐름 및 마스터

---

우리는 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.

---

대부분은 가지를 너무 많이 강조하는 정신적 모델처럼 보입니다. 동의합니다. 릴리스 한 커밋을 마스터로 다시 병합하는 대신 태그 만 지정할 수 있습니다.

그래도 그림은 예쁘다. 모든 것을 마스터로 다시 병합하면 버전 태그가 그래프 전체에 흩어져있는 대신 시간적 순서로 릴리스가 명확하게 표시됩니다.

하지만이 모델은 이전 릴리스의 버그 수정에는 작동하지 않는다고 생각합니다. 깔끔한 주문을 엉망으로 만듭니다.

1. 버전 1.0.1을 출시하고 나중에 기능을 추가하고 1.1.0을 출시했다고 가정 해 보겠습니다.
2. 1.0.1에서 버그를 발견했으며 두 버전 모두에서 수정하고 싶습니다.
3. master에서 1.1.0 뒤에 1.0.2를 추가 한 다음 1.1.1도 직접 atfer (또는 이전)해야합니다.

귀하의 질문에 답하기 위해 : 이것은 어떤 경우에는 단순한 정신 모델을 만드는 일련의 규칙이라고 생각합니다. 모든 규칙이 순전히 기술적 인 관점에서 의미가있는 것은 아니지만 그렇다고해서 나쁜 것은 아닙니다. 정신 모델은 인간에게 좋습니다.

---

개인적으로 언급 된 git-flow가 너무 복잡하다고 생각합니다.

GitHub를 사용하는 경우 GitHub flow(Scott Chacon이 설명한대로) 시도해보십시오 .

여러 기능에 대한 공동 작업, 코드 검토에 특히 유용하며 Commit Status API.

업데이트 : The GitHub Flow ™의 새로운 공식 웹 사이트가 있습니다.

업데이트 2 : The GitHub Flow ™에 대한 새로운 공식 (및 단순화 된) GitHub 가이드 : https://guides.github.com/introduction/flow/

---

제 경우에는 기본이 동일하지만 각 버전마다 몇 가지 다른 기능이있는 동일한 소프트웨어의 두 가지 버전이 있습니다.

그래서 두 개 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는 다운로드 크기를 최소화하기 위해 수행합니다.

나에게는 마스터 를 개발의 메인 라인으로 사용 하는 것이 더 깨끗한 것 같습니다 .

Also there are some conflicts in release-* merging model to master and tagging it afterwards with idea to

use a Git hook script to automatically build and roll-out our software to our production servers everytime there was a commit on master

cause finishing (merging and tagging) is not a atomic transaction :

$ 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

and if git hook start build with automative versioning support:

$git describe --tags --long >.ver

then a mistaken version is possible to be built for:

$ git merge --no-ff release-1.2

I know that versioning in Successfull one introduces some bump-version process but it's not automatic.

So to sum - the key differences we introduce to branch model for releases-* merging and tagging are: - tagging release on Creating its branch - keep release's branch to enable maintainance them in future

---

The master branch should ALWAYS represent your production code base, hence you always merge the code back to master right after a production release.

Tagging is used to "memorize" the exact code which went into a production release so you can go back later and analyze the code if something went wrong.

With this theoretically it shouldn't matter if you tag your code on the release branch or on the master branch after you merged back to master. I personally prefer to tag the code on the release branch as this is exactly the code that went into the build/release (assuming something can go wrong with the merge).

The issue with the development branch concept is that it is single threaded. Brendan in this thread mentioned a strategy which could be used involving a development branch concept.

참고URL : https://stackoverflow.com/questions/16562339/git-flow-and-master-with-multiple-parallel-release-branches