Teilen Sie eine elegante Art, den Git-Workflow zu spielen

In der Entwicklung, egal ob es sich um ein Team handelt, das gemeinsam ein Projekt entwickelt, oder darum, ein Projekt unabhängig zu entwickeln. Es ist unabdingbar, sich mit git auseinanderzusetzen. Angesichts unterschiedlicher Entwicklungsszenarien verfügt möglicherweise jedes Team über seinen eigenen Git-Workflow. Hier möchte ich den git-Workflow basierend auf gitlab teilen, den mein Team derzeit verwendet. Lass uns gemeinsam reden. 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

Der standardisierte Git-Prozess kann unsere Fehlerwahrscheinlichkeit verringern, und wir werden nicht oft auf Git-Probleme stoßen und dann nach einer Reihe fortgeschrittener Git-Nutzung suchen. Unsere Git-Methode erfordert eigentlich nur, dass Sie die grundlegenden Git-Operationen kennen und diese dann standardisieren, und Sie werden grundsätzlich nicht auf Git-Probleme stoßen, sodass jeder seine Zeit mit dem Geschäft verbringen kann. Letztendlich hoffe ich, dass jeder Git studiert, wenn er interessiert ist, und nicht, wenn er auf Probleme stößt und dringend nach Antworten sucht🎜

🎜Unsere Git-Workflow-Methode ist hauptsächlich in die folgenden Bereiche unterteilt: 🎜

• master branch Der neueste stabile Code
• vx.x.x branch version branch, x.x.x ist die Versionsnummer des Entwicklungszweigs.
• feat-xxx Branch Feature (neues Feature) Branch
• fix-xxx Branch Repair Branch
🎜Die oben genannten Zweige sind die Zweige, die wir während der Entwicklung häufig erstellen und verwenden müssen. Lassen Sie uns im Folgenden ausführlich über die Bedeutung der einzelnen Zweige sprechen. 🎜🎜Der Zweig master stellt die neueste stabile Version des Codes dar, die normalerweise zusammengeführt wird, nachdem der Code des Versionszweigs oder Reparaturzweigs online geht. 🎜🎜feat-xxx branch stellt einen Zweig dar, der erstellt wurde, um eine neue Funktion einer bestimmten Version zu entwickeln. 🎜

vx.x.x stellt den Versionszweig dar, den wir vor dem Start jeder Version von master unter dem Namen dieser Versionsnummer erstellen 2.0.1, dann ist der Versionszweig v2.0.1. Warten Sie dann, bis die neuen Funktionen dieser Version in feat-xxx entwickelt sind und den Rauchtest bestehen, und senden Sie dann einen mr merge auf gitlab an dieser Versionszweig. Nachdem jeder Umgebungstest bestanden wurde, führen Sie den Code des Versionszweigs in master zusammen und löschen Sie dann diesen Versionszweig. 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 stellt einen Reparaturzweig dar. Normalerweise wird bei der Bearbeitung von Online-Problemen ein Zweig erstellt, der nach dem Fehlernamen benannt ist. Nachdem der Fehlertest bestanden wurde, wird mr zusammengeführt der master-Zweig
Hinweis: Hier gibt es ein Detail: Die von der Entwicklung im Feature-Zweig übermittelten commit-Informationen werden im Allgemeinen als nutzlose Informationen betrachtet und in den zusammengeführt Version Wenn Sie verzweigen, führen Sie es in einem commit zusammen (da wir zum Zusammenführen gitlab verwenden, überprüfen Sie daher squash, wenn Sie eine <code>mr-Anfrage ausgeben ist in Ordnung), und nach der Übermittlung des Tests werden alle commit-Befehle ausgeführt, unabhängig davon, ob es darum geht, Fehler während des Testvorgangs zu beheben oder die Optimierungsfunktion zu commit Dieser Zweck ist eine Warnung, da ich hoffe, dass die beste Situation darin besteht, sofort nach dem Start des Tests online zu gehen. Obwohl es schwierig ist, dieses Ziel zu erreichen, können die commit-Informationen zurückbleiben Helfen Sie uns bei der Überprüfung

Die Funktionen jedes Zweigs sind wie oben beschrieben. Lassen Sie uns dann darüber sprechen, wie wir einige klassische Szenarien umsetzen, die wir entwickelt haben:

Das erste Szenario: normale Entwicklungsiteration

Wir nehmen uns diese Zeit, um eine Version 1.0.0 als Beispiel zu entwickeln. Es gibt zwei Funktionsmodule, eines dient zum Hinzufügen einer Schaltfläche und das andere zum Hinzufügen eines Formulars

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



Es gibt eine weitere Szene im normalen Iterationsprozess. Das heißt, während des Entwicklungsprozesses kam plötzlich PM vorbei und sagte, dass aufgrund höherer Gewalt eine Funktion unterbrochen werden müsse. Wenn der Code zu diesem Zeitpunkt noch nicht getestet wurde oder die Funktion relativ einfach ist, ist die Handhabung nicht allzu mühsam. Wenn ja, werden Ihre Funktion und der Code anderer Kollegen bereits getestet und einige Fehler wurden behoben. Die Commits sind alle miteinander verflochten, insbesondere die Anforderungen, die das Ändern vieler Dateien erfordern. , müssen Sie sich nicht nur den Code anderer Leute ansehen, sondern auch darauf achten, keine Fehler in Ihrem eigenen Code zu machen. Zu diesem Zeitpunkt ist es in unserem Prozess sehr einfach, die vorhandenen Versionszweige zu löschen und dann die Funktionszweige neu zu gruppieren, die online sein müssen. Es ist ersichtlich, dass Versionszweige durch Feature-Zweige kombiniert werden, was bedeutet, dass Versionszweige durch verschiedene Feature-Zweige beliebig kombiniert werden können. Dies ist bequemer zu handhaben

Das zweite Szenario ist die Online-Fehlerbehebung

Wir nehmen als Beispiel das Klickereignis einer Schaltfläche, die online repariert werden muss

rrreee

Tatsächlich unterscheidet sich der Prozess hier nicht wesentlich vom oben , aber hier gibt es Dinge zu beachten, Online-Problembehebungen, ein Commit pro Fehler und Commits werden beim Zusammenführen in den Master nicht zusammengeführt. Und die Zusammenführungsinformationen müssen auf diese Versionsnummer geändert werden. Diesmal ist es beispielsweise v1.0.1

🎜Das dritte Szenario ist die parallele Entwicklung mehrerer Versionen🎜🎜Dieses Szenario unterscheidet sich nicht vom normalen Iterationsszenario. Es hängt nur davon ab, ob Sie mehrere Versionen haben. Erstellen Sie also einfach die entsprechende Version Zweig. Befolgen Sie einfach den normalen Iterationsprozess für jeden Versionszweig. 🎜🎜Q&A🎜🎜F: Warum gibt es keine Zweige, die der Umgebung wie Dev und Test entsprechen, sodass eine Push-Bereitstellung erreicht werden kann? 🎜🎜A: Unser Prozess hat die Verwendung dieser festen Zweige aufgegeben. Dafür gibt es mehrere Gründe, 🎜

• Nachdem der Code getestet wurde, von der Entwicklungs- zur Test- und sogar zur uat-Umgebung (Vorabversion), wenn es Codeänderungen in verschiedenen Umgebungen gibt, muss der Code geändert werden, um den Code dieser Zweige konsistent zu halten Die Verzweigung muss mit jeder Umgebung synchronisiert werden, was etwas mühsam ist. Dieses Problem besteht bei Versionszweigen nicht. Es gibt nur einen Versionszweig, der verschiedenen Umgebungen entsprechen kann.

• Erleichtert die parallele Entwicklung mehrerer Versionen. Es können mehrere Versionszweige erstellt werden, was die Bereitstellung in verschiedenen Testumgebungen während der parallelen Entwicklung bequemer macht. Wenn die Module zwischen den Versionen nicht eng miteinander verbunden sind, können Sie sie auch parallel testen.

• Semantisch. Mithilfe von Versionszweigen können Sie anhand des Zweignamens erkennen, welche Zweige sich derzeit in der Entwicklung befinden.

F: So gehen Sie mit Änderungen im Master-Zweig um

A: Wenn es Änderungen im Master-Zweig gibt, führen Sie diese rechtzeitig in Ihren eigenen Funktionszweig ein, um Konflikte mit den Codes anderer Mitglieder zu vermeiden

Empfohlenes Lernen: „Git-Video-Tutorial“ 》

Das obige ist der detaillierte Inhalt vonTeilen Sie eine elegante Art, den Git-Workflow zu spielen. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!