Wir stellen eines der GIT-Codezweigverwaltungsmodelle vor

gib-TutorialDie Kolumne stellt das Code-Zweig-Management-Modell vor

Empfohlen (kostenlos): gib-Tutorial

So wie Menschen verstreut sind und es schwierig ist, ein Team zu führen, gibt es viele Codes Versionen und Zweige sind nicht einfach zu verwalten

Wenn die Produktentwicklung ein bestimmtes Niveau erreicht, werden mehrere Versionen gleichzeitig entwickelt, verschiedene Hotfixes und andere Probleme führen unweigerlich zu Problemen bei der Versionszweigverwaltung. Heute werfen wir einen Blick auf die erste Code-Branch-Management-Lösung.

Ich möchte hier betonen, dass jede Branch-Management-Methode ihre eigenen Vorzüge hat. Keine ist unbedingt besser als die andere, nur eine ist für Sie besser geeignet als die andere.

Beliebte und erfolgreiche Code-Branche-Management-Methode

Das ist People's Branch Management. Die Lösung leitet sich einfach aus diesem Artikel mit dem Titel „Ein erfolgreiches Git-Branching-Modell“ ab. Viele Unternehmensprojekte werden auf diese Weise verwaltet. Das Bild unten zeigt verschiedene Zweigdesigns auf diese Weise:

Ein erfolgreiches Git-Branching-Modell

Dieses Modell kann im Wesentlichen die Anforderungen verschiedener Codeversionsverwaltungen erfüllen, die im Entwicklungsprozess von Unternehmensprojekten auftreten. Versuchen Sie es wie folgt zu brechen Gehen Sie dieses Modell herunter und erklären Sie es allen:

Halten Sie sich an den grünen Hügeln fest und entspannen Sie sich nie

Im Bild oben können Sie sehen, dass die Namen zweier Zweige fett gedruckt sind: master und develop, diese beiden sind die Grundpfeiler der Branche.

master

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都是向模块兼容，所以最好能每个模块都自行在一个旮旯捣腾，等最好确定能相亲相爱了，大家再杵到一块去。

这是我们可以基于模块创建各种featureDies ist der erste Zweig nach der Erstellung eines neuen GIT-Repositorys. In diesem Modell stellt der Master-Zweig die Version der aktuellen Produktlinie dar. Der letzte Commit ist möglicherweise bereits online, oder es handelt sich um eine Funktion, die zig Millionen Mal von QA/PD/PO gequält wurde und online sein kann Minuten. Mit anderen Worten: Diese Filiale muss jederzeit online verfügbar sein! Wenn jemand dieser Version eine allgemein entwickelte Funktion vorlegt, kann er von der PO in den Tod gezerrt werden! Daher ist dieser Zweig bei strenger Berechtigungsverwaltung normalerweise gesperrt und nur Online-Kollegen haben die Berechtigung, ihn zu verschieben!

Darüber hinaus wird jedes Mal, wenn der Master online geht, ein Tag hinzugefügt, um die Versionsnummer anzugeben Wir müssen eine neue Welt eröffnen, um etwas zu bewirken. Um mit der großen Armee konsistent zu sein, wird der Zweig von develop basierend auf master erstellt

rrreee

Der letzte git show-branch -a --no -name zeigt, dass der Zweig von <code>develop basierend auf master erstellt wird. 🎜🎜Wenn das Projekt nicht besonders groß ist und die Die Versionsverwaltung ist dann relativ einfach. Die beiden Zweige Master und Develop reichen grundsätzlich aus🎜

---

🎜Stil und Stil blühen auf🎜🎜🎜Wenn das Projekt etwas größer wird, werden Sie auf verschiedene Anforderungen an die Versionsverwaltung stoßen, aber Sie müssen diese Zweige bei Bedarf erstellen, z. B. features, release, hotfix🎜🎜

features🎜Die erste Situation ist häufiger. Es gibt viele Kollegen, die das Projekt parallel entwickeln. Beispielsweise werden mehrere Module zur Entwicklung in den Zweig develop eingeteilt Dann gibt es grundsätzlich keine Möglichkeit, kontinuierliche Integrationsvorgänge (Continue Integration) durchzuführen. Obwohl die Module bei der endgültigen Integration auf jeden Fall harmonisch miteinander harmonieren, ist während des Entwicklungsprozesses nicht unbedingt jedes Commit mit dem Modul kompatibel. Daher ist es am besten, jedes Modul in einer Ecke arbeiten zu lassen, und dann ist es am besten, dies zu tun sicher, dass es zusammenpassen kann. Wenn wir uns verlieben, lasst uns wieder zusammenkommen. 🎜🎜Hier können wir verschiedene Feature-Zweige basierend auf Modulen erstellen. Wenn jeder Feature-Zweig im Grunde fertiggestellt ist, werden wir diese Zweige in Develop zusammenführen nach oben🎜🎜🎜Wenn es einen Feature-Zweig gibt, wird der Entwicklungszweig im Grunde zu einem Integrationszweig🎜

Release

Wie bereits erwähnt, stellt der Master-Zweig die Version der aktuellen Produktlinie dar, die innerhalb von Minuten online bereitgestellt werden kann, ohne wie ein Opfer in den Himmel zu enden. Bei manchen Projekten oder Teams kommt es jedoch vor, dass das Produkt zum Spielen in die Quasi-Produktlinie eingebunden wird. Anschließend wird es intern getestet wird für die Produktlinie freigegeben, nachdem sichergestellt wurde, dass überhaupt keine Probleme vorliegen. Wenn während der Woche der internen Tests ein Problem gefunden wird, beheben Sie es schnell im Entwicklungszweig und gehen Sie dann zur Überprüfung zur Quasi-Produktlinie. Wenn wir den Master-Zweig zum Bereitstellen einer Quasi-Produktlinie verwenden und während der Woche interner Tests ein Problem entdeckt wird und zu diesem Zeitpunkt dringende Probleme in unserer Produktlinie behoben werden müssen, können wir nicht direkt verwenden master Der Zweig ist online, was bedeutet, dass wir unser bisheriges Versprechen nicht erfüllen können: master kann in wenigen Minuten online sein, ohne dem Himmel Opfer bringen zu müssen准产品线上去玩，内测一周左右，确定完全没有问题了再上到产品线上去。在内测的这一周，如果发现了有问题了，赶紧从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的分支上

---

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

So können wir einen Release-Zweig erstellen, um ihn quasi bereitzustellen -Produktlinien und beheben Probleme. Da wir wissen, dass es überhaupt kein Problem gibt, werden wir uns mit der Hauptniederlassung synchronisieren und online gehen

HotfixDas System kann auf keinen Fall fehlerfrei sein! Wenn ein unschuldiger Fehler in der Produktlinie auftritt, zu welchem ​​Zweig sollten wir gehen, um ihn zu beheben?

• Master: Wenn es aufgrund des Designs oder schlechter Überlegungen Fehler in der Produktlinie gibt, besteht im Allgemeinen kein Grund, Abstriche zu machen. Wenn Sie jedoch zufällige Änderungen am Master vornehmen Möglicherweise müssen Sie opfern.
• Veröffentlichung: Dies ist für die nächste Version. Wenn es sich um die vorherige Version handelt, zerstören die neuen Änderungen die Bedeutung der ursprünglichen Versionsnummer. Der ursprüngliche Zweig hieß beispielsweise „Release-1.0.1“. Wird er also nach dem Hinzufügen dieser Version weiterhin diesen Namen tragen?
• Entwickler: Wenn weitere Funktionen in der Entwicklung sind, werden diese hinzugefügt, sobald sie online sind!
• Feature: Das ist etwas weit hergeholt

Es scheint, dass die oben genannten vier Zweige nicht geeignet sind, also lassen Sie uns einen neuen namens Hotfix erfinden Der Zweig wird direkt aus dem Hauptzweig erstellt und wird verwendet, um einige dringende Codereparaturen an der Produktlinie durchzuführen oder um vorübergehend kleine Funktionen hinzuzufügen. Entwickler entwickeln direkt auf diesem Zweig. Nachdem die Funktionen abgeschlossen sind, gehen sie direkt zum Hauptzweig und gehen online. Denken Sie daran, die Funktionen jedes Mal, wenn ein Hotfix gestartet wird, wieder mit dem Entwickler und dann mit den Zweigen jeder Funktion zu synchronisieren

---

Oben geht es um dieses erfolgreiche Code-Zweigverwaltungsmodell Code> Die Erklärung kann grundsätzlich die Codeversionsverwaltungsanforderungen der meisten Projekte in den meisten Unternehmen erfüllen! Wir werden später ein weiteres Code-Branchenverwaltungsmodell vorstellen, das sich auf eine Verwaltungsmethode unseres Unternehmens bezieht. Bis zum nächsten Mal!

🎜🎜🎜Wenn Sie mehr über das Erlernen des Programmierens erfahren möchten, achten Sie bitte auf die Spalte „PHP-Schulung“! 🎜🎜🎜🎜

Das obige ist der detaillierte Inhalt vonWir stellen eines der GIT-Codezweigverwaltungsmodelle vor. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!