Obtenez une compréhension approfondie des différents workflows de Git

Cet article vous présentera Git, vous présentera les connaissances de base de git et divers workflows basés sur git. J'espère qu'il vous sera utile !

Grâce à cet article, vous pouvez apprendre :

• L'origine de git
• Connaissance de base de git
• La manière de base du processus gitflow
• Divers workflows basés sur git

Avant de parler de Git Flow, nous Parlons d'abord d'autre chose

• Qu'est-ce qu'une version ?
  La version fait référence à la version lors de l'impression, et la version est la version du livre imprimé est un titre utilisé pour décrire diverses formes, états ou contenus d'une même chose qui sont différents les uns des autres.
  En d'autres termes, tant que quelque chose est différencié, cela impliquera le concept de version. Cependant, les versions dont nous parlons ici, y compris les choses dont nous parlerons plus tard, devraient toutes être des versions significatives. Le 31 janvier, un document de planification était révisé chaque jour. Le 1er février, le Parti A de Xiao Ming a déclaré que la version précédente était meilleure. À cette époque, pour Xiao Ming, quelle était la version précédente ? C'était peut-être le dernier plan que Xiao Ming a envoyé au parti A, ou peut-être que c'était le dernier plan que le parti A a jugé acceptable, mais Xiao Ming ne se souvient peut-être pas de la date précise à laquelle le plan a été révisé au parti A.

• Quels sont les contrôles de version courants ?
  La façon dont les fichiers de copie sont distingués par leur nom, la fonction d'annulation/transfert de cet éditeur et l'utilisation d'outils professionnels tels que svn, git, etc. appartiennent tous à la catégorie du contrôle de version. Différents contrôles de version ont des utilisations différentes, telles que. comme l'annulation d'un éditeur de texte. Vous pouvez facilement annuler cette modification, comme la copie de fichiers, ce qui permet aux nouveaux et aux anciens fichiers d'exister en même temps pour une comparaison facile. Cependant, ces méthodes sont trop simples et les processus intermédiaires sont temporaires. et ne suffisent pas pour servir de référence d'historique de modification ou de version complète. Pour le voir, pour cela, certains outils professionnels sont également nécessaires, tels que les systèmes de gestion de versions centralisés SVN, CVS, les systèmes de gestion de versions distribués BitKeeper, Git, etc.

• Contexte du développement de Git

  Comme beaucoup de grandes choses dans la vie, Git est né à une époque de grands conflits et d'innovation. Le projet open source du noyau Linux compte un grand nombre de participants. La grande majorité du travail de maintenance du noyau Linux a été consacrée à la tâche fastidieuse de soumission de correctifs et de sauvegarde des archives (1991-2002). En 2002, toute l'équipe du projet a commencé à utiliser BitKeeper, un système propriétaire de contrôle de version distribué, pour gérer et maintenir le code.
  En 2005, le partenariat entre la société commerciale qui a développé BitKeeper et la communauté open source du noyau Linux a pris fin et ils ont repris le droit de la communauté du noyau Linux d'utiliser BitKeeper gratuitement. Cela a obligé la communauté open source Linux (en particulier Linus Torvalds, le créateur de Linux) à développer son propre système de versions basé sur les leçons tirées de l'utilisation de BitKeeper. Ils ont fixé plusieurs objectifs pour le nouveau système :

  • Vitesse ​​
  • Conception simple
  • Prise en charge forte des modèles de développement non linéaires (permettant des milliers de branches de développement parallèle)
  • Entièrement distribué
  • Capable Gérer efficacement des systèmes extrêmement volumineux faire évoluer des projets comme le noyau Linux (vitesse et volume de données) Depuis sa naissance en 2005, Git a mûri et mûri, devenant très convivial tout en conservant les objectifs fixés à ses débuts. Il est rapide, idéal pour gérer de grands projets et dispose d'un incroyable système de gestion de branches non linéaire (voir Branches Git).

• En 1991, Linux a développé le système Linux, un projet open source. Les fichiers sources étaient envoyés par courrier électronique avec des correctifs joints pour l'écriture et le développement, et Linux lui-même les a fusionnés manuellement

• En 2002, BitKeeper ; a conclu un accord avec la communauté Linux. Autoriser la communauté Linux à essayer BitKeeper gratuitement En raison de l'essai gratuit, le contenu de l'accord concerne davantage la protection de BitKeeper lui-même.

• En 2005, BitKeeper était mécontent de la communauté Linux pour avoir détruit le contenu de l'accord (pour parler franchement, elle décompilait BitKeeper, essayait de créer une version crackée ou autre), et a mis fin à sa coopération

• ; La même année que 2005, Linux a passé 2 semaines à développer Git La première édition, utilisez Git pour gérer le code Linux en un mois

Connaissance de base de Git

Espace de travail (espace de travail), zone de transit (index), référentiel ( Dépôt)

# 创建并进入 testGitFlow 目录
# 此时 testGitFlow 就是我们的工作区(Workspace)，也就是工作目录

$ mkdir testGitFlow && cd testGitFlow

# 初始化 git 仓库
# 此时目录中增加了 .git 目录，.git 目录就是 git 仓库，不属于工作区

$ git init

# 新增两个文件
$ echo 111 > a.txt
$ echo 222 > b.txt

# 添加两个文件到暂存区/索引(Index)
$ git add .

# 把索引中的两个文件添加到版本库(Repository)
$ git commit -m 'init'

Plusieurs concepts impliqués ci-dessus :
Espace de travail : Une compréhension simple est notre répertoire de projet
Index : Une compréhension simple est la zone où stocker le contenu à soumettre
Dépôt : Dépôt de versions

Commit , Tree, Objets Blob

# 通过 git log 查看版本
$ git log

>
commit 2b304a56998989dbcfd77f370f4b43fcad9e5872 (HEAD -> master)
Author: huihuipan <huihuipan163@163.com>
Date:   Mon Feb 27 17:56:53 2023 +0800

    init


# 通过 git cat-file 查看 commit 信息

# 查看 commit 类型
$ git cat-file -t 2b304a
> commit

# 查看 commit 内容
$ git cat-file -p 10d717

>
tree 4caaa1a9ae0b274fba9e3675f9ef071616e5b209
author huihuipan <huihuipan163@163.com> 1677491813 +0800
committer huihuipan <huihuipan163@163.com> 1677491813 +0800

init

# 可以发现有 tree, author, committer 等信息
# 继续查看 tree 内容
$ git cat-file -t 4caaa1
> tree

$ git cat-file -p 4caaa1
>
100644 blob 58c9bdf9d017fcd178dc8c073cbfcbb7ff240d6c	a.txt
100644 blob c200906efd24ec5e783bee7f23b5d7c941b0c12c	b.txt

# 可以发现有 blob 信息
# 继续查看 blob 内容
$ git cat-file -t 58c9bd 
> blob

$ git cat-file -p 58c9bd 
> 111

# 可以看到里面存储的是 a.txt 的内容

Plusieurs des éléments ci-dessus impliqués Un concept :
commit : le commit enregistre la version soumise
tree : l'arborescence enregistre la structure du répertoire et le nom du fichier sous différentes versions
blob : le blob enregistre le contenu du fichier

À l'heure actuelle, la structure de notre projet git est la suivante

Que se passe-t-il lorsque vous modifiez un fichier et soumettez un commit ?

1. Tout d'abord, le contenu de a.txt est modifié de 111 à 333. Pour le moment, l'entrepôt git n'a pas changé, mais le contenu de l'espace de travail et de l'index ne correspondent pas
2. Exécutez le Commande git add
   1. L'entrepôt git est basé sur le nouveau Le contenu de a.txt (333) crée un nouveau nœud blob et enregistre le contenu de a.txt
   2. L'index pointe de l'ancien blob vers le nouveau blob
3. Exécutez la commande git commit
   1. Selon l'état de l'index, un objet arbre est généré
   2. Générez un nouvel objet de validation basé sur l'objet arbre nouvellement généré et l'objet de validation précédent
   3. Déplacez le pointeur de branche de l'ancien commit object vers le nouvel objet commit

HEAD, Branch, Tag

Branch  : C'est le pointeur vers le Commit. Chaque fois qu'un nouveau commit est soumis, la branche actuelle pointe vers le commit. dernier commit ;

HEAD : C'est le pointeur vers la branche. Lorsque le paiement atteint une non-branche, il vous demandera Dans l'état du pointeur de tête détaché, vous pouvez effectuer des actions expérimentales ;

Tag : Pointeur vers Commit, utilisé comme étiquette, généralement utilisé pour enregistrer la version corrigée, et peut également être compris comme un alias pour le commit spécifié ;

Nous pouvons apprendre de ce qui précède que la granularité de gestion des versions de git atteint le niveau du fichier, et la comparaison entre les blobs peut devenir différente. Cela conduit également à une réflexion sur le développement, lorsque la base de la conception de notre programme est une comparaison. Lorsque la granularité est petite, le développement et l'expansion ultérieurs seront plus flexibles. Le fonctionnement du commit de git est également très flexible, si flexible que des accidents peuvent survenir si vous ne faites pas attention.

Checkout, Merge, Rebase, Fetch, Pull

checkout : extrayez HEAD vers la branche ou le commit spécifié, ou extrayez le contenu du fichier spécifié dans la version spécifiée, car l'extraction dans git contient trop de plusieurs fonctions, toutes les branches de commutation ont des commandes exclusives . switch

merge merge:

rebase rebase:rebase modifiera l'historique des versions, même si le contenu avant et après rebase est cohérent, la version n'est plus la même version

fetch : Téléchargez des objets et des références depuis un autre référentiel, comme une bibliothèque distante

pull : git pull = fetch + merge Plusieurs workflows basés sur Git

Git Flow

Introduction

provient d'un article

"Un modèle de branchement Git réussi" écrit par Vincent Driessen en 2010

branche principale

Il y a deux branches qui parcourront toute la version cycle de vie , c'est-à-dire la branche à long terme :

• branche master : pour la publication
• branche develop : pour le développement La relation entre la branche master et la branche de développement est la même que ci-dessus. La ligne pointillée indique que les deux branches ne sont pas directement liées, mais sont liées via la branche release/hotfix

branche de support

• branches de fonctionnalités : utilisé pour le développement de la demande

Lors du développement des exigences, retirez la branche de fonctionnalités de la branche de développement Une fois la branche de fonctionnalités développée (et qu'il n'y a aucun problème avec l'auto-test de développement), elle sera fusionnée avec. la branche de développement. Après la fusion, la branche sera supprimée si un bug survient ultérieurement, elle sera modifiée dans la branche de développement.

• branches release : utilisées pour la publication

Lorsque la branche de développement est dans un état relativement stable, la branche de publication peut être extraite de la branche de développement pour préparer la publication. La branche de publication n'effectue pas de développement de fonctions. , uniquement des corrections de bogues, jusqu'à ce qu'il n'y ait aucun problème, fusionnez-le dans la branche master pour la publication. En même temps, fusionnez-le à nouveau dans la branche de développement et supprimez la branche de publication.

• branches hotfix : utilisées pour résoudre les problèmes de production

les branches hotfix sont utilisées pour corriger les bugs qui doivent être corrigés de toute urgence dans l'environnement de production. Lorsqu'un bug se produit dans l'environnement de production, extrayez la branche hotfix du maître. et fusionnez-la dans la branche principale après réparation. Publiez-la, fusionnez-la dans la branche de développement et supprimez-la.

Enfin, examinez le gitflow complet

Supplément

En 2020 Vincent Driessen a ajouté une note de réflexion, en grosGit FlowCe modèle est sous logiciel de livraison continue Il semble compliqué, tu peut envisager d'utiliser Github Flow au lieu de forcer Git Flow dans le projet.

Après Git Flow, Adam Ruka a optimisé les détails techniques de Git Flow et a proposé One Flow

Github Flow

contre Git Flow , Github Flow n'ont qu'une seule branche principale, et le processus PR est ajouté via la plateforme github : Lors du développement d'une certaine fonction, retirez la branche de fonctionnalités de la branche principale, soumettez un PR après avoir terminé la fonction et laissez le personnel concerné l'examiner. La fonctionnalité peut toujours être soumise pendant l'examen et la branche de fonctionnalités peut être fusionnée dans la branche principale. via PR jusqu'à ce qu'il soit confirmé qu'il n'y a aucun problème. Branche pour publier

GitLab Flow

GitLab Flow Utilisez la branche master comme branche de développement, basée sur la branche master. publier la branche de production production
GitLab Flow ajouté Les définitions de branche suivantes :
Branche d'environnement  : utilisée lorsque vous devez publier différentes versions dans différents environnements
branche de publication  : utilisée lorsque le projet doit publier différentes versions. Après avoir déclaré une branche de publication, ces branches ne seront fusionnées qu'avec des mises à jour de correction de bugs sérieuses.

Version continue

gitlab-flow recommande d'utiliser la branche master pour le développement et de construire une branche de production basée sur la branche master pour la publication. Il propose également le concept de branches d'environnement, qui sont fusionnées couche par couche en fonction. différents environnements, et enfin résumé en production pour la publication. Libération après branchement

Version release

Si votre projet doit publier différentes versions, le mode de publication de la version gitlab-flow peut être plus approprié en mode de publication continue, différentes versions auront des branches de version différentes pour la version.

Aone Flow

Aone-flow est basé sur la branche principale, et autres que la branche principale sont des branches temporaires. Les branches d'environnement sont extraites en fonction de la branche principale. Il n'y a aucune connexion entre les branches d'environnement et elles sont développées indépendamment. Les branches d'environnement ne peuvent pas être modifiées directement, mais sont combinées en fusionnant différentes branches de fonctionnalités. La branche de fonctionnalités ne sera pas supprimée tant qu'elle n'aura pas été fusionnée dans la branche de publication. L'un des avantages est que la granularité des opérations est plus élevée et plus contrôlable. L'inconvénient est que même si le contenu de la branche d'environnement est le même, l'historique des versions peut être incohérent.

Comment choisir le contrôle de version

Plusieurs flux sont présentés ci-dessus À partir de gitflow, gitflow permet à git, qui a un haut degré de liberté, d'obtenir une méthode d'utilisation guidée
Et github-flow propose également une solution pour la complexité ; de gitflow. Une version minimaliste de flow ;
gitlab-flow propose sa propre solution de compromis pour les méthodes trop complexes ou trop simples de gitflow et github-flow, et fournit également des solutions pour deux méthodes de livraison (livraison continue, livraison de version) Solution ;
Enfin, AoneFlow est également introduit, une solution avec une granularité de fonctionnement plus libre.

En fait, il n'existe pas de solution universelle. Différentes équipes/projets ont leurs propres situations particulières. Pour différentes situations, le flux change également, et celui qui convient est le meilleur.

Enfin

Pour conclure, rappelez-vous toujours que les paniques n'existent pas. Ne décidez pas par vous-même.

Citation de Vincent Driessen : « Enfin, rappelez-vous toujours qu'il n'y a pas de solution miracle. Tenez compte de votre propre parcours. Ne décidez pas par vous-même »

Pour plus de connaissances sur la programmation, veuillez visiter : Vidéos de programmation. ! !

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!