분기 모델 GiitFlow 및 GiitHubFlow

브랜치 모델
브랜치 모델은
Git Flow,
Git Hub Flow,
이 두 개는 매우 유명하다.
각 지점의 구성을 살펴보자.
Git Flow
A successful Git branching model에서 제창한 지점 모델.
각 캐릭터는 각자의 지점이 있고, 지점은 5가지가 있다.


(참조: https://nvie.com/posts/a-successful-git-branching-model/
모든 개발자가 인용하는 창고와 개발자의 창고로 구성되어 있습니다.
(이하 origin/master는 origin 창고의 마스터 지점으로 표시됨)
5가지 유형의 세목은origin이 지속적으로 존재하는 2가지 주요 지점과 필요에 따라 제작하고 폐기하는 3가지 지점으로 구성된다.
5가지 내역)
1, origin/master: 소스 코드를 반영하는 HEAD는 항상 출하 가능 상태의 주 분기
We consider origin/master to be the main branch where the source code of HEAD always reflects a production-ready state.
2origin/develop: 주요 분기는 원본 코드의 HEAD가 항상 시기에 발표되는 최신 변화를 반영합니다.종합분지라고도 불린다.
We consider origin/develop to be the main branch where the source code of HEAD always reflects a state with the latest delivered development changes for the next release. Some would call this the “integration branch”. This is where any automatic nightly builds are built from.
3,feature: 새로운 기능을 개발하는 지점에서 기본적으로 개발자의 창고에 있는 것이지origin에 있는 것이 아니다.
개발자에서 시작하여 개발자에 통합합니다.
Feature branches (or sometimes called topic branches) are used to develop new features for the upcoming or a distant future release.
Feature branches typically exist in developer repos only, not in origin.
4,release: 다음 제품 발행 지점을 준비합니다.
새 버전을 발표할 때 닫고 작은 오류와 버전 번호를 준비합니다.
개발자부터 잘라서 개발자와 마스터에 통합합니다.
Release branches support preparation of a new production release. They allow for last-minute dotting of i’s and crossing t’s. Furthermore, they allow for minor bug fixes and preparing meta-data for a release (version number, build dates, etc.). By doing all of this work on a release branch, the develop branch is cleared to receive features for the next big release.
5,hotfixes:이것은 열 접두사 지점입니다.
제품에서 오류 등이 발견되면 차단돼 긴급 수정된다.
개발자부터 잘라서 개발자와 마스터에 통합합니다.
Hotfix branches are very much like release branches in that they are also meant to prepare for a new production release, albeit unplanned. They arise from the necessity to act immediately upon an undesired state of a live production version. When a critical bug in a production version must be resolved immediately, a hotfix branch may be branched off from the corresponding tag on the master branch that marks the production version.
GitHub Flow
대원이는 아마도 GiitHub 공동 창업자인 Scott Chacon의 GitHub Flow (링크 첨부) 일 것이다.
GiitFlow는 발매 중심으로 디자인됐고, 상대적으로 디자인 중심의 아이디어였다.
정기적인 디버깅과 수정을 통해 많은 오류가 섞이지 않습니다.
포즈를 만드는 절차는 다음과 같은 6가지 특징이 있다.
1, 마스터 지점의 물건은 모두 디자인할 수 있습니다.
Anything in the master branch is deployable
2, 새로운 작업을 할 때, 명명된 지점을 만들고, 이 지점은 상세하게 설명할 것이다.
To work on something new, create a descriptively named branch off of master (ie: new-oauth2-scopes)
3, 로컬로 제출하고 서버에 정기적으로 같은 이름의 지점에 저장합니다.
Commit to that branch locally and regularly push your work to the same named branch on the server
4, 피드백이나 도움을 원하거나 합병을 준비한 후 요청을 작성한다.
When you need feedback or help, or you think the branch is ready for merging, open a pull request
5, 누군가가 댓글을 달고 인정하면 그것을 마스터에 통합할 수 있다.
After someone else has reviewed and signed off on the feature, you can merge it into master
6, 마스터에 합병하면 바로 디버깅을 진행합니다.
Once it is merged and pushed to ‘master’, you can and should deploy immediately
GiitHub Flow 사용처
엄격한 테스트와 디자인을 가진 출하 문화를 가진 팀에게 GiitHubFlow는 가장 인기가 있다.
For teams that have set up a culture of shipping, who push to production every day, who are constantly testing and deploying, I would advocate picking something simpler like GitHub Flow.
GitLab Flow
위에서 열거한 두 가지는 주요 형식이고 그 외에 GitLab Flow(링크 포함) 등이 있다.
가능하면 한번 보세요.