Partagez une manière élégante de jouer au workflow git

En développement, que vous développiez un projet ensemble en équipe ou que vous développiez un projet de manière indépendante. Il est indispensable de gérer git. Face à différents scénarios de développement, chaque équipe a peut-être son propre workflow git. Ici, j'aimerais partager le workflow git basé sur gitlab que mon équipe utilise actuellement. Parlons ensemble. 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

Le processus git standardisé peut réduire notre probabilité d'erreur, et nous ne rencontrerons pas souvent de problèmes avec git, puis rechercherons un tas d'utilisations avancées de git. Notre méthode git ne nécessite en fait que que vous connaissiez les opérations de base de git, puis que vous standardisiez les opérations, et vous ne rencontrerez fondamentalement aucun problème avec git, afin que tout le monde puisse consacrer son temps aux affaires. En fin de compte, j'espère que tout le monde étudiera git lorsqu'il sera intéressé, plutôt que lorsqu'il rencontrera des problèmes et cherchera de toute urgence des réponses🎜

🎜Notre méthode de workflow git est principalement divisée en plusieurs branches suivantes : 🎜

• master La dernière branche de version de branche de code stable
• vx.x.x, x.x.x est le numéro de version de la branche de développement.
• feat-xxx branche fonctionnalité (nouvelle fonctionnalité) branche
• fix-xxx branche branche de réparation
🎜Les branches ci-dessus sont les branches que nous devons créer et utiliser fréquemment pendant le développement. Parlons de la signification de chaque branche en détail ci-dessous. 🎜🎜La branche master représente la dernière version stable du code, qui est généralement fusionnée après la mise en ligne du code de la branche de version ou de la branche de réparation. 🎜🎜 La branche feat-xxx représente une branche créée pour développer une nouvelle fonctionnalité d'une certaine version. 🎜

vx.x.x représente la branche de version. Il s'agit de la branche que nous créons à partir de master sous le nom de ce numéro de version avant le début de chaque version, tel que le numéro de version. 2.0.1, alors la branche de version est v2.0.1. Attendez ensuite que les nouvelles fonctionnalités de cette version soient développées dans feat-xxx et réussissez le smoke test, puis soumettez une fusion mr sur gitlab à cette branche de version. Une fois chaque test d'environnement réussi, fusionnez le code de la branche de version dans master, puis supprimez cette branche de version. 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 représente une branche de réparation. Habituellement, lors du traitement de problèmes en ligne, une branche nommée d'après le nom du défaut est créée. Une fois le test de défaut réussi, mr Fusionne avec. la branche master
Remarque : Il y a un détail ici : les informations commit soumises par le développement sur la branche feature sont généralement considérées comme des informations inutiles et seront fusionnées dans la branche master version Lors du branchement, fusionnez-le dans un commit (car nous utilisons gitlab pour fusionner, alors vérifiez squash lors de l'émission d'une requête <code>mr < /code> conviendra), et une fois le test soumis, que ce soit pour corriger des bugs pendant le processus de test ou pour commit la fonction d'optimisation, tous les commit sera conservé. Cet objectif est un avertissement, car j'espère que la meilleure situation est de se mettre en ligne dès le lancement du test. Bien qu'il soit difficile d'atteindre cet objectif, les informations commit laissées peuvent. aidez-nous à revoir

Les fonctions de chaque branche sont telles que décrites ci-dessus, puis parlons de la façon de réaliser quelques scénarios classiques que nous avons développés :

Le premier scénario : itération de développement normale

Nous prenons le temps dont nous avons besoin pour développer une version 1.0.0 comme exemple, ceci. Il y a deux modules fonctionnels, l'un doit ajouter un bouton et l'autre doit ajouter un formulaire

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



Il y a une autre scène dans le processus d'itération normal. Autrement dit, pendant le processus de développement, PM est soudainement venu et a déclaré qu'en raison d'une sorte de force majeure, une fonction devait être interrompue. À l'heure actuelle, si le code n'a pas encore été testé ou si la fonction est relativement simple, il n'est pas trop difficile de le gérer. Mais si c'est le cas, votre fonction et le code d'autres collègues sont déjà en cours de test, et certains bugs ont été corrigés. Les commits sont tous liés, notamment les exigences qui impliquent la modification de nombreux fichiers. Ce sera très difficile à gérer pour le moment. , non seulement vous devez examiner le code des autres, mais vous devez également faire attention à ne pas commettre d'erreurs dans votre propre code. Pour le moment, notre processus est très simple. Supprimez simplement les branches de versions existantes, puis regroupez les branches de fonctionnalités qui doivent être en ligne. On peut voir que les branches de versions sont combinées par des branches de fonctionnalités, c'est-à-dire que les branches de versions peuvent être arbitrairement combinées par différentes branches de fonctionnalités. C'est plus pratique à gérer

Le deuxième scénario est la réparation de bugs en ligne

Nous prenons comme exemple l'événement de clic d'un bouton qui doit être corrigé en ligne

rrreee

En fait, le processus ici n'est pas très différent de celui ci-dessus , mais il y a des choses auxquelles il faut prêter attention ici. Oui, des corrections de problèmes en ligne, un commit par bug et aucun commit ne sera fusionné lors de la fusion dans le maître. Et les informations de fusion doivent être modifiées par ce numéro de version. Par exemple, cette fois, il s'agit de la v1.0.1

🎜Le troisième scénario est le développement parallèle multi-versions🎜🎜Ce scénario n'est pas différent du scénario d'itération normal. Cela dépend simplement si vous avez plusieurs versions, alors créez simplement la version correspondante. bifurquer. Suivez simplement le processus d’itération normal pour chaque branche de version. 🎜🎜Q&A🎜🎜Q : Pourquoi n'y a-t-il pas de branches correspondant à l'environnement telles que dev et test, afin que le déploiement push puisse être réalisé🎜🎜R : Notre processus a abandonné l'utilisation de ces branches fixes. Il y a plusieurs raisons, 🎜

• Une fois le code testé, du développement au test, et même dans l'environnement uat (pré-version), s'il y a des changements de code dans différents environnements, alors afin de garder le code de ces branches cohérent, le code doit être synchronisé avec chaque environnement de branchement, c'est un peu gênant. Ce problème n'existe pas avec les branches de versions. Il n'existe qu'une seule branche de versions, qui peut correspondre à différents environnements.

• Facilite le développement parallèle multi-versions. Plusieurs branches de versions peuvent être créées, ce qui est plus pratique à déployer dans différents environnements de test lors du développement parallèle. Si les modules entre versions ne sont pas étroitement liés, vous pouvez également les tester en parallèle.

• Sémantique. Les branches de version peuvent être utilisées pour savoir quelles branches sont actuellement en cours de développement grâce au nom de la branche.

Q : Comment gérer les changements dans la branche principale

A : S'il y a des changements dans la branche principale, fusionnez-les dans votre propre branche fonctionnelle à temps pour éviter les conflits avec les codes des autres membres

Apprentissage recommandé : "Tutoriel vidéo Git" 》

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!