Comment utiliser Git ?

Salut,

Déjà félicitation, Git est une aventure dont on ne revient pas ! Pour commencer par une lecture, je ne peux que te conseiller le Git Book.

Déjà il faut différencier le fait d’utiliser Git et de mettre son code en ligne, les deux étant bien différents.
Git est un outil qui s’utilise localement, qui te permet d’organiser ton travail grâce aux commits et aux branches. Les dépôts distants ne sont utiles que pour des raisons de sauvegarde, de partage et de contributions.

Le tout est de penser en terme de branches. Tu auras généralement sur tes projets des branches considérées comme stables, sur lesquelles tu n’ajouteras pas de commits pour des fonctionnalités non terminées.
Mais à côté de ça tu peux disposer de toutes les branches que tu veux et y pousser ce que bon te semble. Même un POC qui serait amené à disparaître.

Il est courant de travailler avec des branches de fonctionnalités, basés sur master (ou une branche develop) qui représentent la fonctionnalité en cours de développement. Et une fois la fonctionnalité terminée, la branche se retrouve fusionnée dans la principale.

Ça aide beaucoup pour l’organisation, les commits te permettent déjà de donner un nom et un commentaire à tes modifications. Les branches te permettent de naviguer entre fonctionnalités, pour traiter plusieurs sujets en parallèle sans se mélanger dans les fichiers (chaque branche se retrouve associée à un état des fichiers, basculer d’une branche à l’autre modifie les fichiers du répertoire).

Pour la sauvegarde aussi, si tu fais des modifications sur un fichier pour tester quelque chose, tu sais que tu pourras toujours revenir sur tes pas si ce fichier a été commit. De même que tu pourras toujours revenir sur un commit particulier en cas de bug. En parlant de bug, des commandes telles que git bisect et git blame sont bien utiles pour déceler l’introduction d’un bug.

Et ça ce n’est que pour l’aspect local. En travail collaboratif ça devient indispensable pour la gestion des conflits entre fonctionnalités. Tu ne peux pas te permettre de bloquer tout un projet le temps d’implémenter quelque chose pour que les autres se basent ensuite dessus.
Avec un gestionnaire de versions, tout le monde peut travailler en parallèle sur des fonctionnalités différentes, et la résolution des conflits se fait à la fusion des branches.

Si les modifications portent sur un même fichier mais sur des lignes bien distinctes, Git retrouvera ses petits et la fusion se déroulera sans problème. Si les mêmes lignes sont modifiées de part et d’autre, alors il lui sera impossible de savoir quelle version garder, c’est ce qui provoque un conflit.
Tu auras alors accès à un diff pour réécrire le bloc qui pose problème, en sélectionnant ce que tu souhaites garder d’un commit ou de l’autre.

Mais il n’y a pratiquement jamais de possibilité de pertes avec Git. Les seuls cas où cela peut se produire c’est sur des commits plus référencés depuis suffisamment longtemps pour que le garbage collector les supprime. Et encore, il faut que cela se produise sur tous les dépôts qui contiennent ce commit.

A quel moment faut-il mettre notre code en ligne ? Dois-je mettre le tout sur Git une fois que j’arrête de programmer pour aujourd’hui (ce qui veut dire : le mettre en ligne même si je n’ai pas terminé de coder une fonctionnalité) ? Ou alors faut-il le mettre en ligne une fois la fonctionnalité terminée et testée ? Ou bien, dois-je attendre de terminer plusieurs fonctionnalités avant de mettre le code en ligne ?

Avec un gestionnaire de version moderne, tu dois avoir plusieurs branches. Au minimum tu dois avoir :

• Une branche stable, souvent nommée master, tu n’y placeras que du code utilisable et testé uniquement ;
• Une branche de développement ;
• Une branche personnelle.

La branche de développement est plus fourre tout. Tu peux en faire une par version, une par fonctionnalité à développer, un mix des deux. L’important est que ce soit du code pas forcément fini et totalement testé mais utilisable pour les tests.

Une branche perso qui ne sert que pour toi. Genre sauvegarder quelque part tes travaux du jour. Que cela fonctionne ou pas, que ce soit testé ou non est ton affaire.

Le but est de segmenter le code pour te simplifier la vie. Simplifier ton déploiement et favoriser les contributions extérieures si tu le souhaites.

Quels sont les avantages d’utiliser un gestionnaire de version ?

Beaucoup.

Par exemple, si tu développes une fonctionnalité, tu as ton code sur master qui est propre. Tu crées une autre branche pour une nouvelle fonctionnalité. Si tu abandonnes ta fonctionnalité ou que tu souhaites corriger un bogue avant de le finir (car c’est urgent), pas de soucis tu as ton code sur master qui est dispo. Revenir en arrière est simple.

Quand tu fais du développement exploratoire c’est sympa aussi. Tu développes une fonctionnalité un peu grosse, tu peux faire des commits intermédiaires dans ta branche de développement. Si tu réalises au milieu que tu dois faire autrement ce n’est pas un soucis, tu peux revenir en arrière à un point intéressant. Car en commitant, tu ne perds rien.

Tu associes une signification à ton code et à son évolution. Tu peux facilement voir que telle ligne a été crée pour une fonctionnalité ou corriger un bogue précis. Et éventuellement voir comment ça marchait avant. Ça aide beaucoup à comprendre le projet notamment pour els personnes extérieures ou toi même dans longtemps.

Enfin, quand on travail en équipe, comment ça se passe ? Imaginons que je travail sur un fichier, et qu’une autre personne de l’équipe travail sur un autre fichier, mais dois modifier le mien pour terminer son code. Comment ça se passe ? Si je met mon fichier en ligne, il perd ses modifications, et inversement. Ou alors, cela n’arrive jamais ?

S’il y a conflit sur un fichier, en gros deux personnes bossent sur le même fichier, git le détectera quand le second poussera son travail. Si c’est trivial à résoudre, genre vous travaillez sur le même fichier mais pas sur la même partie du code, git résoudra le soucis de lui même. Si par contre le code modifié de ton côté et celui de ton collègue se superposent, git signalera une erreur et demandera à ton collègue de résoudre le conflit à la main avant d’accepter le commit.

D’où l’importance d’avoir une branche master propre qui sert de référence à tout le monde et ensuite on applique individuellement nos travaux dessus quand c’est prêt. Ça évite d’avoir des conflits de partout et d’embêter son voisin pour un code qui ne marche peut être même pas.