Les DVCS (Git, mercurial...) ne sont pas plus compliqués à appréhender que les VCS (SVN, CVS), si l'on a jamais touché à un VCS auparavant.
La principale différence, c'est qu'au lieu de devoir faire des requêtes sur un serveur distant au moindre pet (sauf la remise au dernier état connu), on a tout en local, et c'est donc infiniment plus rapide (enfin, sauf les synchronisations quand une quantité importante de code à été modifiée sur le dépôt de référence, ce qui inclue les clonages de gros projets).
En fait, un DVCS, c'est un peu comme si tu avais le serveur SVN sur la même machine que le client, sauf que le serveur en question aurait la capacité de se synchroniser avec un autre serveur SVN.
Au niveau des avantages, ça facile par exemple le fait de faire un commit après chaque modification: un renommage quelconque, une correction de bogue, un ajout de fonctionnalité...
Les DVCS rendent les commits atomiques plus simples à gérer parce qu'il n'y a pas besoin de se réserver l'usage des fichiers sur lesquels on bosse (puisque le serveur est chez nous et que personne n'y a accès en écriture normallement).
Le principe c'est en gros:
_ je code
_ je considère qu'un jeu des modifications que j'ai faite est atomique, je le commit (commit)
_ je code
_ je considère qu'un jeu des modifications que j'ai faite est atomique, je le commit (commit)
_ je veux envoyer mes modifs sur un serveur tiers (sur lequel j'ai le droit d'écrire) donc je commence par tirer son état (pull) lors d'un commit précis
_ je résouts les conflits potentiels (pour git, il écrit directement dans le fichier les passages anciens et nouveaux séparés par des "<<<<<<<<<<<<<<<<<<<", "=================" et ">>>>>>>>>>>>>>>>" si je me rappelle bien)
_ je commit quand les conflits sont résolus (commit)
_ je pousse mes modifications sur le serveur en question (push)
Bon, en fait, on peut tirer le code d'un serveur sur lequel on a pas le droit d'écrire, c'est uniquement le push qui nécessite ce droit, mais j'ai voulu faire au plus simple.
Le reste des subtilités viens surtout du fait que les DVCS ont intégré d'autres mécaniques non-spécifiques au fait d'être décentralisés: cherry-picking, branches, tags,... directement dans le logiciels, plutôt qu'avoir des dossiers pénibles à synchroniser (dans le cas des branches, je ne maîtrise pas le reste, je connais juste de nom) comme c'est le cas habituellement avec SVN.
Les tags sont gérés... comme de simples tags associés à un commit. Moi je m'en sers pour les versions, mais j'imagine qu'une branche serait plus appropriée si on a une politique de correction des bogues des versions publiées.
Ensuite, le trunk est souvent simplement la branche "master", voire "experimental", tandis que les branches (les sous-dossiers du dossier "branch"
implémentant, par exemple, l'ajout d'une fonctionnalité qui pourrait tout péter ont leur branche propre.
SVN pourrait très bien avoir intégré ce mode de fonctionnement, ça aurait été assez agréable, car c'est beaucoup plus simple de synchroniser les branches lorsqu'elles sont gérées par le VCS plutôt que de devoir les gérer à coup de diff, meld, ou autres winmerge... mais j'insiste: ça n'a rien à voir avec le fonctionnement décentralisé, c'est juste que les auteurs de DVCS ont estimé cette fonctionnalité intéressante. Un VCS pourrait le faire aussi (et à mon sens, ils devraient... quoique, je les considère obsolète donc je m'en moque un peu
)
La seule chose qui pourrait me faire utiliser à nouveau un VCS centralisé, c'est mon patron. Maîtriser GIT est complexe, mais heureusement, il n'y a pas besoin de le maîtriser pour être capable de faire des choses qui sont difficiles et/ou lentes avec SVN. La maîtrise viens à l'usage, et permets juste de régler des cas particuliers.
1 |
0 |
Microsoft accentue le support de Git, l’outil open source de gestion de versions décentralisé, dans Visual Studio et Team Foundation Server (TFS).
Télécharger Visual Studio Tools for Git
Envoyé par Hinault Romaric
...
