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 :
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
# 创建并进入 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
# 通过 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
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 : 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
Introduction
"Un modèle de branchement Git réussi" écrit par Vincent Driessen en 2010
Il y a deux branches qui parcourront toute la version cycle de vie , c'est-à-dire la branche à long terme :
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.
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.
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
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
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 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.
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
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 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.
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.
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!
Construisez votre propre serveur git
La différence entre git et svn
git annuler le commit soumis
Comment annuler l'erreur de commit git
Comment comparer le contenu des fichiers de deux versions dans git
Introduction aux logiciels de virtualisation
saut de ligne forcé de mot
Comment obtenir le numéro de série d'un disque dur physique sous Windows
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
