Maintenant que j’ai passé quelques semaines à utiliser Git, j’ai décider d’écrire noir sur blanc certaines choses que j’ai apprises en migrant de SVN (un système de contrôle de version centralisé) vers Git (un système de contrôle de version distribué) .
1°) Committer tôt, committer souvent
Git, contrairement aux systèmes de contrôle de version centralisé, autorise chaque développeur à posséder sa propre copie (“clone”) du dépôt, ce qui signifie que vous pouvez committer aussi souvent que vous le voulez sans affecter les autres — même si les changements sont incomplets, qu’ils cassent l’API, ou cause l’échec de la génération de la build. Ceci vous autorise à structurer vos commits comme des parties logiques de votre travail, au contraire du commit unique monolithique qui représente la fonctionnalité complète.
Une fois que vous avez votre fonctionnalité complète, vous pouvez allez de l’avant et partager vos commits avec les autres.
2°) Que la force du fork soit avec vous
Les services d’hébergements de projet comme GitHub sont une façon fantastique de partager les projets avec les autres. GitHub fournit une jolie interface web pour Git et est gratuit pour les projets open-source public, et pour quelques dollars il peut être utilisé en tant que dépôt privé. Git rend facile le fork de dépôt, les laissant évoluer indépendamment, et rend le processus de merge plus souple. Vous pouvez même prendre un des commits en particulier et les garder en tant que changements locaux. (J’aime laisser mon dépôt en local être propre ou comme je veux. Quand il devient trop large, il y a toujours git stash or git clean -f.) Avec Subversion, c’est tout ou rien.
Dans le passé, les forks n’étaient pas souvent appréciés car cela causait de la fragmentation et posaient des challenges pour le processus de merge. Un système de contrôle de version distribué a amélioré cela. Git enregistre les relation entre les commits, merger les forks au tronc principal est relativement facile.
Les forks peuvent être encouragés parmi les membres de l’équipe sans se casser la tête avec le processus de merge.
3°) Vérifier le tronc principal
Si vous arrivez dans la mauvaise branche, ou si par accident vous remettez à zero votre pointeur du tronc principal, votre l’arborescence de votre branche ne sera pas comme vous l’attendiez. Comprendre la façon dont Git représente les commits était le gros challenge dont j’ai eu à faire face. De bons articles se trouvent ici et là. Assurez-vous de ne pas perdre la tête : http://sitaramc.github.com/concepts/detached-head.html
4°) RTFL: Lire ce put*in de (ref)Log
Si vous faites face à des erreurs, ou que vous perdez des commits, ou que vous remarquez que vous avez cassé presque, allez voir le reflog. Cela vous montrera tous vos activités récentes sur les dépôts. A partir de là, vous pouvez remettre à zéro votre dépôt vers n’importe quel commit récent.
5°) Tirer ou récupérer (Pull or Fetch) ?
Dans la plupart des systèmes de contrôle de version centralisé, mettre à jour l’arborescence locale (pour correspondre au dépôt) ne peut pas être fait à la légère. Si vous avez fait des changements importants, mettre à jour depuis “HEAD” peut causer un énorme mal de tête. Ceci vient du fait que vous faites essentiellement “récupérer la nouvelle révision” et “merger celle-ci avec votre arborescence.”
Dans Git, le concept de “fetching” et “merging” peut actuellement être appliqué séparément. Si vous voulez simplement mettre à jour votre copie locale d’une branche distante, vous faites un fetch. Vous pouvez reporter le processus actuel de merger à une date ultérieure. Si vous voulez combiner ces 2 opérations (fetch et merge), vous pouvez ensuite faire effectuer une requête pull .
6°) Rebase et revenir à un état précédent
Gérer des branches et des merges dans les systèmes de contrôle de version centralisé requiert souvent beaucoup d’effort et de temps. En fait, tant que le code n’est pas proprement mergé et commité dans le “HEAD”, je ne considère pas cela comme complet. Git, d’un autre côté, enregistre les relations entre les commits, ce qui fournit un support pour le merge bien meilleur. Merger dans Git est souvent une opération sans efforts. Vous pourriez essayer de créer une branche dés que vous commencez à travailler sur une nouvelle fonctionnalité.
A n’importe quel moment, vous pouvez “merger” ou « rebase » vers la branche principale, ainsi que partager votre branche avec d’autres pour une collaboration facile. (Quand j’avais quelques commits locaux d’une branche mais j’avais besoin de récupérer les changements des autres mis dans cette branche, je peux simplement rebase mes commits locaux sur ces changements avec git pull --rebase.) Des branches séparées rendent très facile le travail entre différentes taches sans efforts. J’aime le fait que Git n’encourage pas la structure de code comme ceci : “branches/ tags/ trunk/ ”.
Quand un problème survient, c’est revenir en arrière dans Git (git checkout original_branch), ou simplement en allant dans chaque fichier qui possède un conflit. Je pense aussi “merge fait par toto” ferait une légende intéressant sur un tableau.
Revenir à un état précédent dans Git est assez simple quand vous avez juste besoin d’effacer une erreur. Faites juste un nouveau comit avec git revert commit_sha1 ce qui contrecarre le commit spécifique.
Lire la suite →
