GIT 코드 분기 관리 모델 중 하나를 소개합니다.-자식-php.cn

gib tutorial코드 브랜치 관리 모델을 소개하는 칼럼

GIT 코드 분기 관리 모델 중 하나를 소개합니다.

추천(무료) : gib tutorial

사람이 흩어져서 팀을 이끄는 것이 어려운 것처럼 코드도 많습니다. 버전 및 브랜치 관리가 쉽지 않습니다

제품 개발이 특정 수준에 도달하면 여러 버전이 동시에 개발되고, 다양한 핫픽스 및 기타 문제로 인해 필연적으로 버전 브랜치 관리 문제가 발생합니다. 오늘은 첫 번째 코드 브랜치 관리 솔루션을 살펴보겠습니다.

각 지점 관리 방법에는 고유한 장점이 있다는 점을 강조하고 싶습니다. 자신에게 더 적합한 사람은 없습니다.

인기 있고 성공적인 코드 지점은 없습니다. Management

이것이 사람의 브랜치 관리입니다. 솔루션은 A 성공적인 Git 브랜칭 모델이라는 이 기사에서 간단히 파생되었습니다. 많은 기업 프로젝트가 이러한 방식으로 관리됩니다. 아래 그림은 다양한 브랜치 디자인을 이런 식으로 다루고 있습니다:

GIT 코드 분기 관리 모델 중 하나를 소개합니다.

성공적인 Git 브랜치 모델

이 모델은 기본적으로 기업 프로젝트의 개발 과정에서 직면하게 되는 다양한 코드 버전 관리 요구 사항을 충족할 수 있습니다. 이 모델을 내려놓고 모든 사람에게 설명하세요.

푸른 언덕을 바라보고 절대 긴장을 풀지 마세요

위 그림에서 두 지점의 이름이 굵게 표시된 것을 볼 수 있습니다: master 및 develop, 이 두 가지는 브랜치의 중심입니다. master 和 develop，这两个是分支当中的中流砥柱。

master

这是新建一个GIT repository之后的第一个分支。在这个模型中，master分支代表的是当前产品线上的版本，它的最后一个commit可能是已经上线了，或者已经经过QA/PD/PO 千万次折磨、分分钟可以上线的功能。换句话说，这条分支要做到随时都可以上线的！要是谁把一个开发了一般的功能提交到这个版本上去，有可能会被PO拉去祭天的！所以如果有严格的权限管理的话，一般会把这个分支给锁起来，有且仅有上线的同事才有权限动它！

另外master的每次上线都会打一个tag，表明版本号是多少

develop

一般灵长类动物都敬畏祭天这样的操作，所以我们需要开辟一篇新天地来大有作为。为了和大部队保持一致，develop的分支是基于master创建出来的

C:\githome\github\gitdou (master) (gitdou@0.1.0)
λ git branch
* master

C:\githome\github\gitdou (master) (gitdou@0.1.0)
λ git checkout -b develop
Switched to a new branch 'develop'

C:\githome\github\gitdou (develop) (gitdou@0.1.0)
λ git show-branch -a --no-name
* [develop] add httpUtil.js
 ! [master] add httpUtil.js
  ! [origin/HEAD] add httpUtil.js
   ! [origin/master] add httpUtil.js
----

로그인 후 복사

最后的git show-branch -a --no-name 命令的输出可以看到develop的分支是基于master创建出来的

如果项目不是特别大，版本管理也比较简单，那么master跟develop这两个分支就基本够用了

文体两开花

当项目稍微大一些的时候，会遇到各种各样的版本管理需求，但不一定每一种你都需要，当需要的时候可以再建立这些分支，比如有features, release, hotfix

features

第一种情况比较常见，项目有很多同事并行开发，比如分了多模块给多个小组进行开发，如果各个模块都往develop分支上面丢，那么基本没办法做持续集成(Continue Integration)的操作。虽然最后集成的时候各模块一定会和谐相处的，但是在开发过程当中，不一定每一个commit都是向模块兼容，所以最好能每个模块都自行在一个旮旯捣腾，等最好确定能相亲相爱了，大家再杵到一块去。

这是我们可以基于模块创建各种feature

master

새 GIT 저장소를 만든 후 첫 번째 분기입니다. 이 모델에서 마스터 브랜치는 현재 제품 라인의 버전을 나타냅니다. 마지막 커밋은 이미 온라인 상태일 수도 있고, QA/PD/PO에 의해 수천만 번 고문을 거쳐 온라인 상태가 될 수도 있습니다. 분. 즉, 이 지점은 언제든지 온라인으로 이용 가능해야 합니다! 누구든지 이 버전에 일반 기능을 제출하면 PO에 의해 천국으로 끌려갈 수 있습니다! 따라서 엄격한 권한 관리가 있는 경우 일반적으로 이 지점은 잠기게 되며 온라인 동료만이 이동 권한을 갖습니다!

그리고 마스터가 온라인에 접속할 때마다 버전 번호를 나타내는 태그가 추가됩니다

개발
🎜일반적으로 영장류는 하늘에 제사를 드리는 등의 조작을 경외하므로 우리는 변화를 만들기 위해서는 새로운 세상을 열어야 합니다. 대규모 군대와의 일관성을 유지하기 위해 master🎜rrreee🎜를 기반으로 develop 브랜치가 생성됩니다. 마지막 git show-branch -a --no -name 명령의 출력은 <code>develop 분기가 master🎜🎜프로젝트가 특별히 크지 않고 버전 관리가 상대적으로 간단하다면 기본적으로 마스터와 개발 두 가지 브랜치로 충분합니다.🎜
🎜스타일과 스타일이 꽃피우고 있습니다🎜🎜🎜프로젝트가 조금 더 커지면 다양한 버전 관리 요구 사항에 직면하게 되지만, 아니요 필요한 경우 features, release, hotfix🎜🎜
features🎜첫 번째 상황이 더 일반적입니다. 프로젝트를 병렬로 개발하는 경우에는 여러 모듈이 여러 그룹으로 나누어져 각 모듈이 develop 분기에 배치됩니다. , 그러면 기본적으로 지속적인 통합(Continue Integration) 작업을 수행할 수 있는 방법이 없습니다. 최종 통합 과정에서는 모듈이 분명히 조화롭게 작동하겠지만, 개발 과정에서는 모든 커밋이 반드시 모듈과 호환되는 것은 아니므로 각 모듈이 한쪽 구석에서 자체적으로 작동하도록 하는 것이 가장 좋으며, 그 다음에는 그렇게 하는 것이 가장 좋습니다. 우리가 사랑에 빠지면 다시 만나자. 🎜🎜여기에서 모듈을 기반으로 다양한 feature 브랜치를 생성할 수 있습니다. 각 기능 브랜치가 기본적으로 완료되면 해당 브랜치를 개발로 병합합니다. to the top🎜🎜🎜기능 브랜치가 있으면 개발 브랜치는 기본적으로 통합 브랜치가 됩니다🎜

release

앞서 언급했듯이 마스터 브랜치는 현재 제품 라인의 버전을 나타내며, 하늘에 대한 희생처럼 끝나지 않고 몇 분 만에 온라인으로 배포할 수 있습니다. 하지만 일부 프로젝트나 팀에서는 제품이 온라인에 출시되기 전에 준제품 라인에 배포하여 확인한 후 약 1주일 동안 테스트해야 합니다. 전혀 문제가 없다는 것을 제품 라인에 담을 것입니다. 내부 테스트 주간에 문제가 발견되면 개발 브랜치에서 빠르게 수정한 후 유사제품 라인으로 이동하여 검증합니다. 준제품 라인을 배포하기 위해 마스터 브랜치를 사용하는데, 내부 테스트 주간에 문제가 발견되어 이때 우리 제품 라인에 시급하게 수정해야 할 문제가 있는 경우에는 를 직접 사용할 수 없습니다. master 브랜치가 온라인이므로 이전 약속을 이행할 수 없습니다. master는 천국에 희생할 필요 없이 몇 분 안에 온라인 상태가 될 수 있습니다.准产品线上去玩，内测一周左右，确定完全没有问题了再上到产品线上去。在内测的这一周，如果发现了有问题了，赶紧从develop分支进行修复，再上到准产品线来验证。如果我们用master分支来进行准产品线的部署，在内测的这一周发现问题，而这时我们的产品线上有紧急问题要fix，那么我们就无法直接拿master分支上线，这就做不到我们之前的承诺: master分分钟可以上线而不用祭天

所以我们可以创建一个release的分支来进行准产品线的部署和问题修复，知道确认完全没有问题了，我们再同步到master分支去上线

hotfix

做系统的哪可能没有bug！当产品线上无辜出现bug的时候，我们要去哪个分支做修复呢？

master ：显然不合适，产品线上由于设计或者考虑不周出现bug一般是不用祭天的，但如果因为这样，在master上面一通乱改，那就有可能要祭天了
release：这个是给下一个版本用的呢。如果是上一个版本的话，那新增的修改就破坏了原来版本号的意义了，比如原来分支叫release-1.0.1, 那么加了这个版本还叫这个名字吗？
developer: 如果还有一些其它正在开发的功能，那一会上线的时候就会连带这个也稍上去了！
feature：这就有点扯远了

看来上面这4种分支都不大合适，那就来款新的，就叫hotfix. hotfix分支是从master分支直接创建出来的，用来做一些产品线上紧急的代码修复，或者临时添加的小功能。开发人员直接在这个分支上进行开发，功能完成后直接上到master分支再上线。

记得每次hotfix上线后，要把功能同步回developer，再到各feature的分支上

以上就是关于这款 成功的代码分支管理模型

그래서 우리는 준 배포용 릴리스 브랜치를 만들 수 있습니다. -제품 라인을 확인하고 문제를 해결합니다. 전혀 문제가 없다는 것을 알고 마스터 브랜치에 동기화하여 온라인으로 전환합니다.

hotfix시스템에 버그가 없을 리가 없습니다! 제품 라인에 순진한 버그가 나타나면 어느 지점으로 가서 이를 수정해야 합니까?

마스터: 당연히 부적절합니다. 디자인이나 배려 부족으로 인해 제품 라인에 버그가 발생하면 일반적으로 이를 희생할 필요는 없습니다. 그러나 이로 인해 마스터를 임의로 변경하는 경우에는

release: 이것은 다음 버전을 위한 것입니다. 이전 버전인 경우 새 변경 사항으로 인해 원래 버전 번호의 의미가 손상됩니다. 예를 들어 원래 브랜치는 release-1.0.1이라고 했는데 이 버전을 추가한 후에도 계속 이 이름으로 불립니까?

개발자: 개발 중인 다른 기능이 있다면 출시되자마자 추가될 예정입니다!

특징: 좀 억지스럽네요

위의 4개 브랜치가 적합하지 않은 것 같아서 hotfix라는 새로운 브랜치를 생각해 보겠습니다. 브랜치는 마스터 브랜치에서 직접 생성되며, 제품 라인에서 긴급 코드 복구를 수행하거나 일시적으로 작은 기능을 추가하는 데 사용됩니다. 개발자는 이 브랜치에서 직접 개발합니다. 기능이 완료된 후 바로 마스터 브랜치로 이동하여 온라인에 접속합니다. 핫픽스가 온라인 상태가 될 때마다 기능을 개발자에게 다시 동기화한 다음 각 기능의 분기에 다시 동기화해야 합니다.

위 내용은 성공적인 코드 분기 관리 모델에 대한 것입니다. 설명은 기본적으로 대부분의 회사에서 대부분의 프로젝트의 코드 버전 관리 요구 사항을 충족할 수 있습니다! 나중에 또 다른 코드브랜치 관리 모델을 소개하겠습니다. 이는 저희 회사의 관리 방법을 의미합니다. 다음 시간에 만나요!