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

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

추천(무료) : gib tutorial

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

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

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

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

이것이 사람의 브랜치 관리입니다. 솔루션은 A 성공적인 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

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

개발

🎜일반적으로 영장류는 하늘에 제사를 드리는 등의 조작을 경외하므로 우리는 변화를 만들기 위해서는 새로운 세상을 열어야 합니다. 대규모 군대와의 일관성을 유지하기 위해 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라는 새로운 브랜치를 생각해 보겠습니다. 브랜치는 마스터 브랜치에서 직접 생성되며, 제품 라인에서 긴급 코드 복구를 수행하거나 일시적으로 작은 기능을 추가하는 데 사용됩니다. 개발자는 이 브랜치에서 직접 개발합니다. 기능이 완료된 후 바로 마스터 브랜치로 이동하여 온라인에 접속합니다. 핫픽스가 온라인 상태가 될 때마다 기능을 개발자에게 다시 동기화한 다음 각 기능의 분기에 다시 동기화해야 합니다.

---

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

위 내용은 GIT 코드 분기 관리 모델 중 하나를 소개합니다.의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!