Une introduction au contrôle de version et à Git

Vous connaissez Google Docs ? Eh bien, si vous l'êtes, il est prudent de supposer que vous êtes au courant du petit onglet "Historique des versions" qui permet aux rédacteurs et aux personnes impliquées de vérifier et de suivre toutes les modifications apportées au document. à un moment donné. Un outil pratique, n'est-ce pas ?

Imaginez maintenant qu'au lieu d'une feuille pleine de paragraphes, il y ait des fichiers pleins de centaines de lignes de codes. Et contrairement à un seul document, il existe des tonnes de fichiers différents, constamment mis à jour.

Dans un scénario comme celui-ci, où il y a des milliers de lignes de codes en jeu et le résultat final, c'est-à-dire que l'application mobile est ce dont dépend l'avenir d'une entreprise, il devient encore plus important d'avoir un logiciel qui garderait un œil sur tous les changements. faites dans les fichiers de code.

C'est là qu'un logiciel de contrôle de version entre en scène.

Pourquoi le contrôle de version est-il important dans le développement de logiciels

Comme son nom l'indique, un logiciel de contrôle de version permet aux développeurs d'applications mobiles de suivre les différentes versions du cycle de développement logiciel et d'y apporter des modifications. Cette capacité à suivre toutes les modifications apportées au code, puis la possibilité d'annuler les modifications, est ce qui fait de Version Control une partie importante du processus d'une société de développement d'applications mobiles qui implique plusieurs développeurs.

Maintenant, en ce qui concerne le contrôle de version, il existe un certain nombre de logiciels disponibles sur le marché à l'heure actuelle. Examinons certains d'entre eux -

Logiciels disponibles pour le contrôle de version

Bien que dans son enquête GitLab, le leader des logiciels distribués ait constaté que 98 % des utilisateurs utilisent les outils open source Git et que plus de 92 % des développeurs utilisent Git comme langage de contrôle de version dans le processus de développement d'applications, il existe un certain nombre des raisons pour lesquelles les développeurs pourraient envisager une alternative à Git. Certaines de ces raisons peuvent varier entre la structure de tarification de GitHub et le fait que Github est lancé à la fois sur iOS et Android, une aversion pour Octocat ou un simple niveau de confort avec un langage de contrôle de version qui n'est pas Git.

Quelle que soit votre raison, voici l'alternative de Git pour le contrôle de version -

Maintenant, même lorsqu'il existe un certain nombre d'alternatives disponibles pour Version Control et chez Appinventiv, nous avons une expérience de première main pour travailler sur beaucoup d'entre elles, en raison des exigences variables des clients, nous sommes en effet partisans de Git. Laissez-moi vous dire pourquoi.

Pourquoi Appinventiv utilise Git pour le contrôle de version

1. Pour sa vitesse fulgurante

Parmi tous les logiciels de contrôle de version du marché, la vitesse à laquelle les éléments Git log et Commit fonctionnent est inégalée. Et lorsque votre équipe de développeurs travaille sur une plateforme, il devient absolument nécessaire que le logiciel soit rapide.

2. Pour la capacité de travailler hors ligne

Lorsque vous travaillez sur un logiciel qui s'appuie sur Internet, cela peut être risqué lorsque vous êtes en déplacement et que vous perdez la connexion avec le référentiel central. Mais ce n'est pas le cas avec Git. Avec Git, vous pouvez effectuer presque toutes les tâches sur votre machine locale : valider, parcourir l'historique du projet, créer une branche ou fusionner.

3. Pour le soulagement d'annulation

Git est livré avec une commande "annuler" qui vous permet de corriger et d'annuler l'ensemble du commit. En fait, il vous donne même la possibilité de restaurer le commit "supprimé" via son option Reflog.

4. Pour la sauvegarde

Lorsque l'équipe travaille sur Git, chaque clone que l'équipe a sur sa machine est livré avec une sauvegarde utilisable. En plus de cela, presque toutes les actions Git ne font qu'ajouter les données et ne les suppriment pas.

5. Pour faire des commits utiles

Lorsque notre équipe de développeurs commet un ensemble de modifications sans rapport - prendre certaines fonctionnalités de A, apporter des corrections de bogues à une autre - il peut être très difficile pour les autres membres de l'équipe de comprendre ce qui s'est passé et il peut être difficile pour eux de revenir en arrière Fonctionnalités de A si cela cause des problèmes.

Git résout ce gâchis en créant un commit granuel. Grâce à son concept de "zone de préparation", on peut facilement savoir quels changements seraient inclus dans le prochain commit, même lorsque vous n'avez qu'à regarder des lignes uniques.

Ce sont donc les cinq principales raisons pour lesquelles nous utilisons Git ici chez Appinventiv. Maintenant que nous avons examiné le pourquoi, il est temps d'examiner le comment. Comment nous intégrons Git dans notre processus de contrôle de version.

Venons-en à cela maintenant.

Processus de contrôle de version lors de l'utilisation de Git

Création de référentiel

Le but de Git est de gérer un ensemble de fichiers, alias Project. Pour ce faire, Git enregistre toutes les informations dans une structure de données appelée Repository. Un référentiel se compose des codes sources de l'application, des ressources et des ensembles de données. Fondamentalement, il contient tout ce qui définit le projet d'application.

Maintenant, il existe deux façons d'obtenir un référentiel sur Git. Vous pouvez soit utiliser un répertoire local et le convertir en un référentiel Git à l'aide de la ligne de commande, soit copier un référentiel Git déjà téléchargé dans le vôtre.

Lorsque vous créez un référentiel, vous obtenez généralement deux options : public et privé. Le référentiel public est celui qui peut être consulté par d'autres développeurs utilisant Git et le référentiel privé, en revanche, est celui qui ne peut être consulté que par quelques personnes.

Ramification

À côté de la création de référentiel se trouve la création de branches. Dans une entreprise comme Appinventiv, où à tout moment plus de 15 à 20 développeurs travaillent sur un projet, il n'est pas rare que les développeurs partagent le même code source et y travaillent. Ce qui se passe, c'est que certains développeurs étant occupés à résoudre des problèmes, d'autres pourraient implémenter certaines fonctionnalités.

Dans une situation comme celle-ci, nous avons besoin d'un système qui facilite la gestion de différentes versions de code dans la même base de code.

C'est là que Gitflow entre en scène. Gitflow est un framework utilisé pour créer des branches de manière systématique et efficace.

Avant de continuer avec le fonctionnement du processus de branchement sur Gitflow, permettez-moi d'expliquer le concept avec un exemple.

Supposons qu'il y ait 5 développeurs dans votre équipe et qu'ils travaillent sur le développement d'une application de type Instagram. Désormais, les fonctionnalités individuelles de l'application, telles que supposer que le flux et les notifications sont désignés comme module 1, module 2, etc. Or ces différents modules sont des branches de développement, qui après avoir travaillé sont fusionnées avec la branche mère ou Master.

Dès qu'un développeur ajoute une branche, il crée une ligne de développement indépendante, qui isole son travail de celui des membres de son équipe. Les différentes branches sont ensuite fusionnées dans la branche mère.

La création de branches est la méthode qui permet aux membres de l'équipe d'identifier tous les changements auxquels ils doivent s'attendre et qui facilite le retour en arrière.

Dans nos projets, nous gardons généralement ces branches -

• Branche principale
• Direction du développement
• Branche de fonctionnalité
• Branche de libération
• Correctifs et corrections de bogues

S'engager

Les modifications apportées par un développeur dans le fichier individuel sont appelées Commit. Les modifications ou la validation sont ajoutées dans le référentiel local et non sur le serveur. Ensuite, nos développeurs prennent l'habitude d'écrire un message de validation, dans lequel la description de la validation (modifications apportées au fichier) est publiée, afin que les autres développeurs connaissent également les détails des modifications apportées au fichier.

Pousser

Lorsque vous validez dans le référentiel Git local, ce qui se passe ensuite, c'est que les modifications sont ensuite envoyées au serveur, appelé Push .

Il est assez facile de pousser l'historique de validation sur le serveur lorsque vous êtes le seul à travailler sur un fichier, mais au cas où d'autres développeurs seraient également impliqués dans le processus, vous devrez extraire les modifications avant de pouvoir pousser votre ensemble de s'engager sur Git.

Ensuite, nous examinerons ce qui est fait à l'étape Pull Change.

Demande d'extraction

Lorsque plusieurs développeurs travaillent sur le même fichier, ce qui se passe, c'est que certains commits peuvent être poussés sur le serveur par l'autre développeur avant que vous ne les poussiez. Et lorsque cela se produit, un conflit survient (nous en reparlerons plus tard).

Pour éviter de télécharger deux fois la même base de code sur le serveur, les développeurs extraient d'abord les modifications du référentiel et s'assurent que les codes sont différents. Maintenant, généralement, lorsque deux développeurs ou plus travaillent sur le même fichier et poussent leur validation sur le serveur, l'option de "Fusionner" apparaît.

Parlons ensuite de Merge.

Fusionner

La fusion est l'étape où les développeurs associent d'abord toutes les branches entre elles, puis avec la branche principale ou parente.

Chaque fois qu'un livreur entre une commande Push, il obtient une option Merge, qui lui demande ensuite la branche avec laquelle il souhaite fusionner le commit.

Maintenant, au stade de la fusion, l'apparition de conflits est très courante. Un conflit se produit généralement lorsque les deux branches que vous envisagez de fusionner ont été modifiées dans la même partie du même fichier. Ce qui se passe ici, c'est que Git n'est pas en mesure de déterminer quelle version doit être utilisée.

Lorsque ce problème de conflit survient, Git propose deux résolutions : automatique et manuelle.

Comme son nom l'indique, l'un est l'endroit où Git découvre le problème lui-même et dans ce dernier cas, les développeurs doivent le faire manuellement. Chez Appinventiv, nous nous concentrons sur la résolution manuelle des conflits, car nous éliminons même les moindres risques d'apparition de bogues.

Pendant que nous utilisons Git pour contrôler la version de notre processus de développement d'applications, ce qui se passe simultanément est le suivi des problèmes.

Depuis que nous sommes un grand adepte d'Agile et que nous faisons confiance à Agile pour notre processus de développement d'applications mobiles , nous comprenons l'importance de gérer plusieurs processus de développement en même temps. Et avec la fonction de suivi des problèmes, il devient beaucoup plus facile pour les testeurs de surveiller en temps réel le code écrit et poussé sur le serveur Git.

Nous utilisons le tableau ZenHub pour surveiller le flux de travail dans chaque référentiel. Le tableau nous permet de garder une trace de la priorité du changement suggéré et aide également les développeurs à mettre à jour leur commentaire sur le tableau en temps réel.