Qu'est-ce que le contrôle de version?
Lorsque nous écrivons du code dans une équipe de développeurs, nous pouvons nous attendre à ce que d'autres travaillent sur la même base de code. Comment pouvons-nous y parvenir?
D'une manière - une personne fait les changements et partage le projet avec la personne suivante, puis ils apportent plus de changements et le partagent avec la personne suivante. Mais de cette façon, une seule personne peut travailler sur le code à la fois. Une autre manière pourrait être - ils utilisent tous un même code de base et créent leurs propres versions. Ensuite, quelqu'un (chef d’équipe) devrait s'asseoir et fusionner toutes les modifications manuellement.
Les méthodes ci-dessus semblent très délicates. Donc, pour résoudre ces problèmes, nous utilisons un système de contrôle de version comme git, mercurial, etc.
Avec git, nous pouvons créer plusieurs versions d'un code ou application et les mettre dans des branches, et quand tout est prêt, nous pouvons lancer une requête de fusion (pull request) et la fusionner dans la base de code principale. De cette façon, les développeurs peuvent continuer à travailler sur leur fonctionnalité et ne fusionner le code que lorsqu'ils pensent que leur code est prêt. Enfin, tout le code atterrira dans la base de code principale (master branch).
Qu'est-ce que git?
Git est un système de contrôle de version distribué gratuit et open source conçu pour tout gérer , des petits projets aux très grands projets avec rapidité et efficacité. Ce n'est rien d'autre qu'un outil CLI qui permet de gérer les versions de code sur une machine.
Git sert de base à de nombreux services, comme GitHub et GitLab, mais vous pouvez utiliser Git sans utiliser aucun autre service. Cela signifie que vous pouvez utiliser Git en privé ou en public. Cependant, il est logique d'utiliser github ou gitlab si vous voulez que d'autres personnes puissent travailler sur le code ou votre application.
Basic concepts
clone
git clone est une commande Git qui est utilisée pour cibler un référentiel existant et créer un clone (une copie). Nous clonons généralement un projet sur github ou gitlab vers notre système local. Essayez -
git clone https://github.com/lawalalao/to-do
cd mg-bot
git status
fork
Git Fork signifie que vous créez simplement une copie du référentiel principal du code source d'un projet dans votre propre profil GitHub. Si vous aimez un projet et que vous souhaitez y apporter des modifications, vous pouvez créer une copie du dépôt dans votre compte github et apporter les modifications que vous souhaitez.
local repo & remote repo
En termes simples - le local repositery est un référentiel git sur votre machine et le remote repositery est un référentiel git sur github ou gitlab. Nous pouvons effectuer diverses opérations comme push, commit and pull
pour synchroniser les fichiers entre plusieurs référentiels.
Une autre chose à noter est que nous pouvons avoir plusieurs référentiels distants connectés au même référentiel local. Nous utilisons pour cela git remote
, que nous apprendrons dans cet article.
Commit
Chaque fois que nous apportons des modifications au code, nous mettons en relief ces modifications en utilisant git add, puis nous les validons en utilisant git commit. La validation du code crée un instantané du code sous forme de validation, vous pouvez extraire n'importe quelle validation pour obtenir cette version du code. C'est comme un historique de toutes les modifications de votre référentiel. essayez d'utiliser la commande git log dans un dossier de dépôt git local pour voir une liste de commits.
git add . # mets en relief toutes les modifications apportes
git commit -m "modification faite"
branch
S'il y a plusieurs personnes qui travaillent sur différentes fonctionnalités, elles auront différentes versions du code. Pour y parvenir, ils peuvent faire des branches. Chaque branche peut avoir une version différente du code. Lorsque l'une des branches a un code prêt, cette branche peut être fusionnée avec la branche principale pour intégrer la fonctionnalité dans le code principal.
Les branches permettent à plusieurs personnes de travailler très facilement sur plusieurs fonctionnalités au même moment. essayez -
git branch # nous montre la branche sur laquelle on travaille
git checkout -b nouvelle-branch
tags
Nous savons maintenant ce que sont les commits. Les tags sont des références qui pointent vers des points spécifiques de l'historique de Git. Le balisage est généralement utilisé pour capturer un point de l'historique qui est utilisé pour une version (ex v1.5.1)
Nous pouvons récupérer des balises (tags) comme des branches ou des commits.
git checkout v1.5.1
pull and push
Deux des commandes Git les plus importantes. Pull - git pull est une commande Git utilisée pour mettre à jour la version locale d'un référentiel à partir du remote. git pull obtient les dernières modifications de la branche actuelle et d'autres métadonnées partir du remote comme - les branches et les balises distantes.
git pull
git pull origin master # pull a specific branch from origin remote
Push - git push est une commande utilisée pour envoyer les changements de code local (commits) au remote. git push trouvera tous les commits présents sur la branche locale qui ne sont pas présents sur le remote et il appliquera ces commits sur la branche distante. Nous faisons généralement un push git lorsque nous commettons des modifications localement.
git push origin master
staging (git add)
le staging revient à sélectionner quelques fichiers parmi les fichiers modifiés. Après quoi nous pouvons créer un commit.
Pour sélectionner tous les fichiers.
git add .
Pour sélectionner un fichier particulier.
git add <changed file>
pull request
Lorsque nous voulons fusionner les modifications d'une branche vers une autre branche (comme master), nous créons une pull request. La pull request est appelée merge request dans gitlab. Nous lançons une pull request lorsque nous sommes prêts à intégrer les modifications d'une branche dans master ou dans une autre branche. Lorsque nous lançons une pull request, nous pouvons continuer à ajouter plus de commits à la branche et elle sera automatiquement ajoutée dans la pull request également.
Vous trouverez ci-dessous l'interface utilisateur lorsque nous créons une nouvelle pull request.
Suppléments
Code Reviews
Lorsqu'une personne émet une pull request, d'autres peuvent examiner leurs modifications et donner des approbations. Plus d'approbations signifient que les gens pensent que le code est bon et qu'il devrait être fusionné. Si toutefois quelqu'un trouve des problèmes dans le code, il peut mettre des commentaires de révision, que le développeur peut corriger dans un nouveau commit. Cela permet de garantir que seul un code de bonne qualité est fusionné dans master (branche principale).
Git Merge
Lorsque nous avons deux branches différentes, disons branch1 et master
. Nous voulons fusionner les modifications de branch1
dans master
. Nous utilisons git merge
. Chaque fois qu'une demande Pull (PR) est fusionnée, elle appelle git merge
en interne. Il existe différentes manières de fusionner un PR -
Copy all commits from pr while merging
squash all commits into one commit while merging
git merge master
Git Rebase
Si nous avons trois branches b1, b2, master
et que nous voulons appliquer tous les changements dans master. Nous fusionnons la branche b1
vers master
. Maintenant b2
a des commits qui ne sont pas présents dans master, et master a des commits (de b1) qui ne sont pas dans b2
. Dans ce cas, nous pouvons rebase b2
pour obtenir les modifications de master dans la branche b2
git checkout b2
git rebase master
Conflict
Lorsque nous faisons du rebase ou un merge, nous pouvons avoir des conflits. Si deux personnes ont travaillé sur la même ligne de code, alors git ne peut pas déterminer quel code conserver et lequel supprimer. C'est à ce moment-là que nous avons un conflit de fusion. Pour continuer notre fusion ou notre rebase, nous devons d'abord résoudre les conflits, puis continuer.
NOTE: Lors d'un merge du code avec la branche principale, nous utilisons normalement les pull requests.
Voici quelques termes de base impliqués dans Git. En espérant que vous partagez avec d'autres pour qu'ils en bénéficient aussi