Contrôleur de code

source

Ibtissame Aouraghe
Introduction
Comment gérez-vous actuellement un projet ?
L’envoyer à travers un message sur Facebook, ... (Très mauvaise idée)
L’envoyer par mail (Un peu moins)
Utiliser une Dropbox, Google Drive, ... (Déjà mieux mais toujours risqué ou manque
de fonctionnalités)
Introduction
Comment gérez-vous actuellement un projet ?
L’envoyer à travers un message sur Facebook, ... (Très mauvaise idée)
L’envoyer par mail (Un peu moins)
Utiliser une Dropbox, Google Drive, ... (Déjà mieux mais toujours risqué ou manque
de fonctionnalités)

Solution : Utiliser un système de gestion de version de code source.

Définition
Source contrôle est la pratique du suivi et de la gestion des modifications du code
Les sources contrôles fournissent un historique de développement du code et aident
à résoudre les conflits lors de la fusion de contributions provenant de plusieurs
sources.
Le contrôle des sources protège le code source des dégradations occasionnelles suite
aux erreurs humaines.
Les avantages incluent: la réutilisabilité, la traçabilité, portabilité, l'efficacité, la
collaboration et l'apprentissage.
Définition
Version: Enregistre des « instantanés » du projet.
Gestion: Revenir en arrière, voir des différences, fusionner des modifications.
Décentralisé: Chacun
• a sa copie (avec son historique) sur son PC,
• peut mettre sa copie (et son historique) en ligne,
• peut récupérer sur son PC les copies et historiques disponibles en ligne,
• peut fusionner différentes copies (semi-)automatiquement.
Définition
Forces Idéal pour

• Prise en charge multiplateforme

(CrossPlatform)
• Petite modification de code.
• Un modèle de révision de code
• Évoluer grâce à l'open source.
convivial open source via des
• Des équipes réparties.
demandes de tirage (Pull)
• Des équipes travaillant sur toutes les
• Historique
plateformes.
• Demande de validation «Pull Request»
• Gestion des branches.

•Chaque développeur clone une copie d'un référentiel et à l'historique complet du projet.
•Les systèmes de contrôle de source distribuée courants sont Git et Azure DevOpsServeur
Principes de Git

Espace de travail : les fichiers, répertoires... dans lesquels on travaille. Ils n’ont rien de
spécial par rapport à d’autres dossiers sur l’ordinateur.
Dépôt : espace de travail + historique, sur un ordinateur.
Commit : ”version”, est le successeur d’une autre commit.
Historique : la ”chaîne” de tous les commits, du plus ancien au plus récent.
Dépôt distant : un dépôt qui se trouve chez GitHub.
Principes de Git
Contrôle workflow
Le contrôle de version a un flux de travail général que la plupart des développeurs
utilisent pour écrire du code et le partager avec l'équipe
1. Obtenez une copie locale du code s'ils n'en ont pas encore.
2. Apportez des modifications au code pour corriger les erreurs ou ajouter de
nouvelles fonctionnalités.
3. Une fois le code prêt, rendez-le disponible pour examen par votre équipe (Pull
Request).
4. Une fois le code révisé, fusionnez-le dans la base de code partagée de l'équipe.
Actions avec Git

Créer un dépôt sur GitHub.

Cloner (faire une copie d’) un dépôt de GitHub sur son PC.
Modifier/créer des fichiers (pas avec Git !).
Ajouter un fichier modifié : il sera pris en compte dans le prochain commit.
Faire un commit : créer une nouvelle version, qui contient tous les fichiers ajoutés. On
y ajoute un commentaire (qui décrit les changements).
Actions avec Git
Consulter un historique.
Push : envoyer ses nouveaux commits sur GitHub.
Pull : récupérer des changements (qui ont été envoyés par quelqu’un d’autre)
depuis GitHub.
Merge : quand on Pull et qu’on a aussi des nouveaux commits sur son PC. Git essaye
de fusionner automatiquement ; s’il ne sait pas le faire, il demande à l’utilisateur.
Bonnes pratiques pour le contrôle des
sources
• Faites de petits changements, avec des commit régulières.
• Ne pas commité des fichiers personnels.
• Mettre à jour souvent et juste avant de faire du « push» pour éviter les conflits de fusion.
• Vérifiez votre changement de code avant de faire du « push » dans un référentiel, assurez-
vous qu'il compile et que les tests réussissent.
• Portez une attention particulière à la validation des messages car ceux-ci vous indiqueront
pourquoi un changement a été effectué.
• Lier les modifications de code aux éléments de travail (WorkItem).

Un Work Item est accessible sous forme d'une fiche contenant de nombreuses informations et décrivant soit une tâche à réaliser, soit un scénario
utilisateur ou bien encore un bug à corriger.
Commandes importantes à suivre
$ git init : initialisation locale d’un repository.
$ git config -- global user.name « Ibtissame Aouraghe »
$ git config -- global user.email « b.aouragh@emsi.ma»
Pour mettre en ligne vos projets : Il faut créer un compte GitHub, puis créer un nouveau Repository
$ git remote add origin https://github.com/IAouraghe/MyProject-siteweb.git : linker Git avec GitHub Reposirtory
Après avoir codé et réalisé des modifications sur mes fichiers localement
$ git add . Ajouter les modifications temporairement dans une liste
$ git commit –m « création de fichier style.css »
$ git log : afficher les différents log existants
$ git push origin master
Commandes importantes à suivre
Ajouter des contributeurs au projet : Sur GitHub : Settings, puis je clique sur collaborateurs

Dans le terminal du 2ème utilisateur :

$ git clone https://github.com/IAouraghe/MyProject-siteweb.git : Permet de charger les fichiers

du GitHub vers le PC localement

$ git add .

$ git commit –m « création de fichier style.css »

$ git log : afficher les différents log existants

$ git push origin master

Commandes importantes à suivre
Je télécharge sur mon ordi les différents new commits effectués par mon équipe sur le
projet :
$ git pull origin master

$ git log : s’assurer du téléchargement des différents log existants

$ git reset – hard : Annuler les modifs réalisées avant la commande commit
Commandes importantes à suivre
Création de branches
$ git branch dev : créer une branche portant le nom dev

$ git checkout dev : accéder à la branche dev

Note : On peut également utiliser $ git checkout –b dev pour créer une branche et
basculer immédiatement dessus. Cela est l’équivalent d’utiliser git branch puis git
checkout.

$ git branch : Vérifier dans quelle branche nous pointons

Commandes importantes à suivre
$ git add .

$ git commit –m « Ajout de nouvelles lignes de code dans la branche DEV »

$ git log : afficher les différents log existants

$ git push origin dev

$ git merge : fusionner les différentes modifications