Git 워크플로우를 우아하게 플레이하는 방법을 공유하세요

개발 중에는 팀으로 함께 프로젝트를 개발하든, 독립적으로 프로젝트를 개발하든 상관없습니다. git을 다루는 것은 필수입니다. 다양한 개발 시나리오에 직면하면 각 팀에는 고유한 git 워크플로가 있을 수 있습니다. 여기서는 현재 저희 팀에서 사용하고 있는 gitlab 기반의 git 워크플로를 공유해드리고 싶습니다. 함께 이야기합시다. git打交道。面对不同的开发场景，或许每个团队都有自己的git工作流。这里，我想分享一下我的团队目前正在使用的基于gitlab的git工作流。一起交流一下。

规范化的git流程能降低我们的出错概率，也不会经常遇到git问题，然后去搜一堆git高阶用法。我们的这套git玩法儿，其实只要会基本的git操作就行了，然后规范化操作，基本不会遇到git问题，这样大家就可以将时间用于业务上。最终，希望大家研究git的时候是在感兴趣的时候，而不是遇到问题，紧急去寻找答案的时候

我们的这种git工作流玩儿法呢，主要是分为下面几个分支：

• master分支   最新的稳定代码
• vx.x.x分支   版本分支，x.x.x是此次开发的版本号。
• feat-xxx分支 特性（新的功能）分支
• fix-xxx分支  修复分支

上面的这些分支呢，就是我们在开发中需要经常去创建并使用的分支。下面详细说说每个分支代表的意思。

master分支代表的是最新的稳定版本的代码，一般是版本分支或者修复分支的代码上线后合并过来的。

feat-xxx

표준화된 Git 프로세스는 오류 확률을 줄일 수 있으며 Git 문제가 자주 발생하지 않으며 고급 Git 사용법을 검색합니다. 우리의 git 방법은 실제로 기본적인 git 작업을 알고 작업을 표준화하면 기본적으로 git 문제가 발생하지 않으므로 모든 사람이 비즈니스에 시간을 보낼 수 있습니다. 궁극적으로 모두가 문제에 부딪혀 급하게 답을 찾을 때보다는 관심이 있을 때 git을 공부하기를 바랍니다🎜

🎜우리의 git 작업 흐름 방식은 주로 다음과 같은 여러 갈래로 나누어집니다: 🎜

• master 브랜치 최신 안정 코드
• vx.x.x 브랜치 버전 브랜치, x.x.x는 개발 브랜치 버전 번호입니다.
• feat-xxx 분기 기능(새로운 기능) 분기
• fix-xxx 분기 복구 분기
🎜위 브랜치는 개발 과정에서 자주 생성해서 사용해야 하는 브랜치입니다. 아래에서 각 가지의 의미에 대해 자세히 이야기해 보겠습니다. 🎜🎜 master 브랜치는 최신 안정 버전의 코드를 나타내며, 일반적으로 버전 브랜치나 복구 브랜치의 코드가 온라인 상태가 된 후 병합됩니다. 🎜🎜feat-xxx 브랜치는 특정 버전의 새로운 기능을 개발하기 위해 생성된 브랜치를 나타냅니다. 🎜

vx.x.x는 버전 브랜치를 나타냅니다. 이는 버전 번호가 시작되기 전에 이 버전 번호 이름으로 master에서 생성한 브랜치입니다. 2.0.1인 경우 버전 분기는 v2.0.1입니다. 그런 다음 이 버전의 새로운 기능이 feat-xxx에서 개발될 때까지 기다리고 스모크 테스트를 통과한 다음 gitlab에 mr 병합을 제출하여 이 버전 분기. 각 환경 테스트를 통과한 후 버전 분기의 코드를 master에 병합한 다음 이 버전 분기를 삭제하세요. vx.x.x代表的是版本分支，这个是我们在每个版本开始前，以此次版本号为名从master创建的分支，比如版本号是 2.0.1，那么版本分支则为 v2.0.1。然后等到该版本的各个新功能在feat-xxx开发完成并冒烟测试通过后，就到gitlab上提一个mr合并到该版本分支上。等到各个环境测试通过后，就将版本分支的代码合并到master上，然后就可以删除本次的版本分支了。

fix-xxx表示的是修复分支，通常在处理线上问题时，创建一个以缺陷名称命名的分支，在缺陷测试通过后，通过mr合并到master分支去

注意：这里有个细节是，在特性分支上开发提交的commit信息，一般认为是无用信息，会在合并给版本分支的时候给合并到一个commit（由于我们是使用gitlab来合并，所以在发起mr请求时勾选squash选项就好了），而在提测后不论是修复测试过程中bug，或者是优化功能的commit则会全部保留，这个目的是一个警示，因为我希望最好的情况是提测即上线，虽然达到这个目标有难度，但是这些留下的commit信息可以帮助我们复盘

各个分支的作用如上面所描述的那样，接着聊聊我们开发的一些经典场景该怎么做：

第一个场景：正常开发迭代

我们以本次需要开发一个 1.0.0版本为例，这个其中有两个功能模块，一个是需要添加一个按钮，一个是需要添加一个表格

sequenceDiagram
master->>v1.0.0: 从master切出 v1.0.0
master->>feat-add-button: 从master切出 feat-add-button
master->>feat-add-form: 从master切出 feat-add-button
feat-add-form->>feat-add-form: 开发完成
feat-add-button->>feat-add-button: 开发完成
feat-add-button->>v1.0.0: 在gitlab发起mr到v1.0.0,并合并所有commit
feat-add-form->>v1.0.0: 在gitlab发起mr到v1.0.0,并合并所有commit
v1.0.0->>v1.0.0: 提测
feat-add-button->>feat-add-button: 修复测试bug
feat-add-button->>v1.0.0: 将修复的 commit cherry pick到 v1.0.0
v1.0.0->>master: 在gitlab上mr到master，并将合并信息改成 v1.0.0



通过上面的时序图，可以看到，我们以我们即将开始的版本命名了一个版本分支 v1.0.0,并且也根据这个版本下面的两个功能创建了两个特性分支 feat-add-button和feat-add-form,然后等功能开发完成后再通过gitlab发起mr（注意，这里要把合并commit选项勾选上）合并到 v1.0.0,那么 v1.0.0分支的代码就会从dev环境开始流转，直到生产环境。这其中，如果有需要修复或者优化的地方，也是先修改特性分支，然后再cherry pick

fix-xxx는 복구 분기를 나타냅니다. 일반적으로 온라인 문제를 처리할 때 결함 이름을 딴 분기가 생성되고, mr가 병합됩니다. master 브랜치
참고: 여기에 세부정보가 있습니다. 기능 브랜치에서 개발을 통해 제출된 commit 정보는 일반적으로 쓸모 없는 정보로 간주되어 버전 분기할 때 commit으로 병합합니다. (우리는 gitlab을 사용하여 병합하므로 mr 요청을 실행할 때 squash를 확인하세요. 옵션은 괜찮을 것입니다) 그리고 테스트가 제출된 후에는 테스트 과정에서 버그를 수정하기 위한 것인지, 아니면 최적화 기능을 <code>commit하기 위한 것인지, 모든 commit 이 목적은 경고입니다. 가장 좋은 상황은 테스트가 시작되자마자 온라인에 접속하는 것입니다. 비록 이 목표를 달성하기는 어렵지만 남겨진 commit 정보는 가능합니다. 검토를 도와주세요

각 브랜치의 기능은 위에 설명되어 있습니다. 그런 다음 우리가 개발한 몇 가지 고전적인 시나리오를 수행하는 방법에 대해 이야기해 보겠습니다.

첫 번째 시나리오: 일반적인 개발 반복

이번에는 1.0.0 버전을 예로 들어 개발해야 합니다. 두 가지 기능 모듈이 있는데 하나는 버튼을 추가해야 하고 다른 하나는 양식을 추가해야 합니다

sequenceDiagram
master->>fix-button-click: 从master切出 fix-button-click
fix-button-click->>fix-button-click: 修复问题并测试
fix-button-click->>master: 从gitlab发起mr合并到master



일반적인 반복 과정에는 또 다른 장면이 있습니다. 즉, 개발 과정에서 PM이 갑자기 찾아와서 어떤 불가항력으로 인해 기능을 중단해야 한다고 말했습니다. 이때, 코드가 아직 테스트되지 않았거나 기능이 상대적으로 단순하다면 처리하는 것이 그리 어렵지 않습니다. 하지만 그렇다면 귀하의 기능과 다른 동료의 코드가 이미 테스트 중이고 일부 버그가 수정되었습니다. 커밋이 모두 얽혀 있으며, 특히 많은 파일을 수정하는 요구 사항은 현재로서는 처리하기가 매우 어려울 것입니다. , 다른 사람의 코드도 봐야 할 뿐만 아니라, 자신의 코드에서도 실수하지 않도록 주의해야 합니다. 현재 우리 프로세스에서는 매우 간단합니다. 기존 버전 브랜치를 삭제한 다음 온라인 상태여야 하는 기능 브랜치를 다시 그룹화하면 됩니다. 버전 브랜치는 기능 브랜치에 의해 결합된다는 것을 알 수 있습니다. 즉, 버전 브랜치는 다른 기능 브랜치에 의해 임의로 결합될 수 있습니다. 이게 처리하기 더 편해요

두 번째 시나리오는 온라인 버그 복구입니다

온라인에서 수정해야 할 버튼의 클릭 이벤트를 예로 들어보겠습니다

rrreee

사실 여기서의 프로세스는 위와 크게 다르지 않습니다. , 하지만 여기서 주의할 사항이 있습니다. 예, 온라인 문제 수정, 버그당 하나의 커밋, 마스터에 병합할 때 커밋이 병합되지 않습니다. 그리고 병합 정보를 이 버전 번호로 수정해야 합니다. 예를 들어 이번에는 v1.0.1입니다

🎜세 번째 시나리오는 다중 버전 병렬 개발입니다🎜🎜이 시나리오는 일반적인 반복 시나리오와 다르지 않습니다. 단지 여러 버전이 있는지에 따라 다르므로 해당 버전을 생성하면 됩니다. 나뭇가지. 각 버전 분기에 대한 일반적인 반복 프로세스를 따르십시오. 🎜🎜Q&A🎜🎜Q: 푸시 배포가 가능하도록 개발, 테스트 등의 환경에 해당하는 브랜치가 없는 이유는 무엇입니까?🎜🎜A: 우리 프로세스에서는 이러한 고정 브랜치의 사용을 포기했습니다. 여러 가지 이유가 있습니다. 🎜

• 코드를 테스트한 후 개발부터 테스트까지, 심지어 uat(사전 출시) 환경까지, 다양한 환경에서 코드 변경이 있는 경우 이러한 분기의 코드를 일관되게 유지하려면 코드가 다음을 수행해야 합니다. 각 환경에 동기화해야 합니다. 분기하는 것은 약간 번거로운 작업입니다. 버전 브랜치에서는 이 문제가 발생하지 않습니다. 다양한 환경에 대응할 수 있는 버전 브랜치가 하나만 있습니다.

• 다중 버전 병렬 개발을 촉진합니다. 여러 버전 분기를 생성할 수 있으므로 병렬 개발 중에 다양한 테스트 환경에 배포하는 것이 더 편리합니다. 버전 간 모듈이 밀접하게 관련되어 있지 않은 경우 병렬로 테스트할 수도 있습니다.

• 의미. 버전 브랜치를 사용하면 브랜치 이름을 통해 현재 어떤 브랜치가 개발 중인지 알 수 있습니다.

Q: 마스터 브랜치의 변경 사항을 처리하는 방법

A: 마스터 브랜치에 변경 사항이 있으면 적시에 자신의 기능 브랜치에 병합하여 다른 멤버의 코드와의 충돌을 방지하세요

추천 학습: "Git 비디오 튜토리얼" 》

위 내용은 Git 워크플로우를 우아하게 플레이하는 방법을 공유하세요의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!