Github, Gitlab, Bitbucket : découvrons les principes des VCS !
En tant que Product Manager tu as sûrement entendu les termes PR, Merger, Issue ou Commit… Tout ces concepts sont liés aux systèmes de contrôle de version.
Commençons par expliquer le concept à ta grand-mère
Imagine que tu écris un livre avec plusieurs personnes. Chaque fois que quelqu'un ajoute un chapitre ou corrige une faute, il enregistre une nouvelle copie du livre avec un petit mot expliquant ce qu'il a changé. GitHub et les systèmes de contrôle de version font la même chose pour les développeurs, mais avec du code. Ils gardent une trace de chaque modification, de sorte que tout le monde peut travailler ensemble sans se perdre.
Let’s dive in !
GitHub, Gitlab ou même Bitbucket sont tous basés sur Git, un système de contrôle de version distribué créé par Linus Torvalds, le même qui a créé Linux. Git permet aux développeurs de suivre les modifications apportées au code source tout en travaillant sur des branches distinctes qui peuvent être fusionnées ultérieurement. GitHub ajoute une interface conviviale et une multitude de fonctionnalités collaboratives par-dessus Git.
La gestion des versions utilise plusieurs concepts:
Référentiels (Repositories) :
Un référentiel, ou repo, est l'endroit où tout le code du projet est stocké. Il contient les fichiers, les historiques de versions, les branches et les commits. Les repos peuvent être publics, permettant à n'importe qui de voir et de contribuer, ou privés, restreignant l'accès à des utilisateurs spécifiques.
Branches et Commits :
Les branches permettent aux développeurs de travailler sur différentes fonctionnalités ou corrections de bugs en parallèle. Chaque modification apportée au code est enregistrée sous forme de commit. Cela permet de garder une trace de chaque changement et de revenir à des versions précédentes si nécessaire.
Pull Requests (PR) :
Une pull request est une proposition de modification du code. Lorsqu'un développeur termine son travail sur une branche, il peut ouvrir une PR pour que les autres membres de l'équipe examinent et commentent ses changements. Une fois approuvée, la PR peut être fusionnée dans la branche principale du projet (on appelle ça merger la branche).
Issues :
Les issues sont des tickets utilisés pour suivre les bugs, les tâches et les nouvelles fonctionnalités.
Exemple : En tant que PM on a créé une issue pour passer la couleur d’un bouton de bleu à vert. Un développeur va créer une branche (une copie du code actuellement utilisé en production) sur laquelle il va pouvoir faire la modification de couleur qui sera enregistré sour la forme d’un commit. Il va ensuite ouvrir une PR pour proposer de venir merger ses modifications sur la branche principale.
Et pour une équipe de développement, l’utilisation d’un VCS est cruciale pour plusieurs raisons :
1. Suivre les modifications
Ils permettent de suivre chaque changement apporté au code source. Chaque modification est enregistrée avec un message de commit, une horodatage, et des informations sur l'auteur. Cela crée un historique complet du projet.
2. Compartimenter le développement
Ils permettent de créer des branches pour travailler sur des fonctionnalités ou des corrections de bugs sans affecter le code principal. Chaque branche est un espace isolé où les modifications peuvent être développées et testées indépendamment.
3. Résoudre les conflits
Lorsqu'un même fichier est modifié simultanément dans différentes branches, des conflits peuvent survenir lors de la fusion. Les VCS offrent des outils pour résoudre ces conflits en permettant aux développeurs de choisir quelles modifications conserver.
4. S’assurer de la qualité
Les VCS facilitent la collaboration en permettant aux membres de l'équipe de partager et de réviser le code. Les pull requests (PR) ou les merge requests sont des outils qui permettent à un développeur de proposer des modifications pour intégration dans la branche principale, après révision par d'autres membres de l'équipe (peer review).
5. Revenir en arrière
Les VCS permettent de créer des versions spécifiques du projet. Si une modification introduit un bug ou un problème, il est possible de revenir à une version antérieure du code.
Et d’un point de vue Product ?
Git n'est pas seulement un outil pour les développeurs, c'est un atout précieux pour les Product Managers. En comprenant et en exploitant ses fonctionnalités, on peut améliorer la transparence, la collaboration et l'efficacité de ses projets de développement.
En tant que Product Manager, on peut suivre les branches actives, les PRs ouvertes, et les issues en cours de traitement. Cela permet d’avoir une vue d'ensemble de l'avancement.
Les PRs et les issues sont également des outils qui documentent les discussions autour des changements de code et des décisions techniques ce qui peut vous permettre de mieux comprendre pourquoi certaines décisions ont été prises (très pratique si cette décision a été price il y a longtemps potentiellement par des gens qui ne sont plus dans l’entreprise)
PS : Les schémas sont inspirés du super dossier réalisé par Atlassian sur le sujet.