Quels sont vos avantages et inconvénients de git après l'avoir utilisé ?

Question

J'utilise SVN en ce moment, et j'ai utilisé CVS et VSS dans le passé. SVN est actuellement le favori dans mes livres, mais j'ai beaucoup entendu parler de git. Parmi les personnes qui ont utilisé git, quels sont les avantages et les inconvénients selon votre expérience ?

Answer 1

Je n'ai pas de lot d'expérience avec git, mais :

Pour :

• C'est très rapide.
• Commits locaux rock
• Démarrage rapide d'un nouveau dépôt (pas de configuration, etc.)
• github est facile à utiliser

(Je n'ai pas encore vraiment "besoin" du côté distribué des choses, au-delà de la possibilité d'avoir un dépôt local et de pousser vers un dépôt public).

Cons :

• Le support de Windows est toujours à la traîne, je crois - et vous ne pouvez pas l'utiliser à partir d'une invite de commande normale.
• Manque d'intégration de l'IDE et de l'Explorer
• Il m'a fallu un certain temps pour trouver un bon texte d'introduction dans la lignée du livre de Redbean.
• Le fait que "l'ajout" d'un fichier modifié n'ajoute que le contenu à ce moment-là (de sorte qu'il peut apparaître comme "staged" pour les livraisons). y ont encore des modifications qui nécessitent un autre git add ) a mis du temps à comprendre

Answer 2

Nombre de commandes

Alors que svn et d'autres VCS modernes comme hg ou d'autres sont des outils agréables et utiles, git est un atelier rempli de machines-outils. C'est à la fois un avantage et un inconvénient. Alors que svn possède 30 commandes (selon 'svn help'), git propose 130 pages de manuel, chacune d'entre elles décrivant plus ou moins une seule commande. Une raison à cela est que git expose les fonctions de bas niveau dont la plupart des utilisateurs auront besoin en tant qu'outils de ligne de commande. Mais même sans ces commandes de bas niveau, git fournit un grand nombre d'outils très puissants que l'on ne trouve dans aucun autre VCS que je connais (cf. git-bisect , git-filter-branch , git-cherry o git-reset pour des exemples). Bien qu'il soit très utile d'avoir ces outils à portée de main, il est assez difficile pour un débutant de comprendre quelle commande il doit connaître et quelle commande il ne doit pas connaître.

---

Modèle de développement

Un sujet similaire est que git est suffisamment puissant pour supporter des modes de fonctionnement très différents. Cela rend les choses difficiles pour les débutants car il n'existe pas vraiment de document sur les "meilleures pratiques", celles-ci n'étant pas intégrées à git. Vous devez donc décider vous-même si vous

• Utilisez simplement les fusions pour éviter les conflits avec votre répertoire de travail.
• Utiliser les branches privées qui sont rebasées sur HEAD amont.
• Utiliser les branches amont
  • qui sont fusionnés régulièrement (poisson volant)
  • fusionnés une fois terminés
• Utiliser un arbre composé d'un mainteneur de projet, de mainteneurs d'arbres, de mainteneurs de sous-systèmes, de mainteneurs de pilotes et de contributeurs, chaque niveau tirant les correctifs du niveau inférieur (noyau linux).

Comme vous avez votre dépôt local, vous pouvez même utiliser un mode de fonctionnement très différent de celui du projet sur lequel vous travaillez et simplement ajuster vos jeux de modifications avant de les pousser/publier.

---

Le chemin des changements

Une autre chose qui compte également comme un pour et un contre selon votre point de vue est que travailler avec git est plus compliqué qu'avec n'importe quel VCS centralisé et encore plus compliqué que la plupart des autres VCS distribués.

Avec un VCS centralisé, il suffit normalement de faire un commit et les changements que vous avez faits vont dans le référentiel. Dans git, les modifications peuvent passer par un nombre assez important d'étapes avant d'arriver à leur destination finale. Les étapes typiques sont (les étapes moins courantes sont entre parenthèses) :

• Working dir (édition)
• Index aka staging area (git add)
• Dépôt local (git commit)
• (Autre branche locale) (git rebase, git cherry-pick, git merge)
• (sous le dépôt du mainteneur) (git push, git pull, mail)
• Dépôt en amont (git push, git pull, mail)

Comme vous pouvez le voir dans l'index, il y a au moins deux étapes à franchir, mais elles sont généralement plus nombreuses. Cela nécessite une compréhension plus approfondie de ce que vous faites et la saisie de beaucoup plus de commandes. D'un autre côté, cela vous donne le contrôle sur chacune de ces étapes. Vous pouvez

• décider quelles sont les jonctions/lignes qui vont dans le commit et celles qui n'y vont pas.
• décidez quels correctifs vous voulez dans chacune de vos branches locales
• décider lesquels de vos correctifs sont publiés
• retravaillez, corrigez, divisez, réorganisez vos correctifs avant de les publier.
• décidez vous-même des personnes en qui vous avez confiance et dont vous acceptez les correctifs
• déléguer des parties du projet à d'autres mainteneurs en qui vous avez confiance.

Tout ce pouvoir et ces décisions rendent difficile la prise en main de git par les débutants. Une fois maîtrisés, ils donnent un contrôle énorme sur le code.

---

Accès en écriture

Un avantage majeur pour tout VCS distribué est que les contributeurs n'ont pas besoin d'un accès en écriture pour bénéficier du VCS. Toute personne ayant un accès en lecture peut simplement cloner le dépôt, créer des branches si nécessaire et commencer à empiler des ensembles de correctifs. Travailler avec cvs sans accès en écriture est un véritable calvaire - avec git, la manière d'introduire vos correctifs n'est pas très différente. Il ne s'agit pas seulement d'un avantage technique, mais aussi d'un moyen d'éviter des discussions compliquées sur la question de savoir si un débutant doit vraiment avoir un accès en écriture.

Answer 3

Pro :

• Rapide - très rapide.
• La création d'un nouveau dépôt est très facile par rapport à SVN.
• Le repo complet est contenu dans un seul dossier .git - il n'ajoutera pas un dossier .SVN dans chaque dossier de votre code (ce n'est pas un gros problème, mais j'aime ça).
• Les ramifications sont plus faciles
• GitHub !

Cons :

• Impossible d'extraire une partie du référentiel (comme un seul dossier ou un seul fichier).
• Ne suit pas les dossiers vides
• Mauvais support de Windows (ne me dérange pas beaucoup - j'utilise Linux)
• Je n'ai pas encore trouvé un bon outil GUI pour Git (j'utilise KDESVN pour SVN). Ce n'est pas un gros problème si vous êtes à l'aise avec le CLI.

Answer 4

Beaucoup de gens le nient, mais le choix de l'outil de gestion du code source influence la façon dont vous travaillez. J'avais l'habitude de travailler beaucoup avec Subversion - jusqu'à ce que je découvre Git pour moi. J'évitais la plupart du temps les branchements dans Subversion. Quand je ne pouvais pas l'éviter, je préférais mettre en place un miroir local (en utilisant svk). Alors que les branchements sont faciles à faire à la fois dans Subversion et dans Git, seul Git rend la fusion (et le rebasage !) amusante, Subversion a toujours été une douleur royale quand il s'agissait du temps de fusion.

La deuxième chose que j'aime vraiment dans Git (en dehors de tous les points qui ont déjà été mentionnés) est l'"index", une zone de transit qui contient votre prochain commit, et la possibilité d'y ajouter seulement des morceaux uniques d'un fichier modifié.

Answer 5

Le support Windows est épouvantable, j'ai donc migré vers Mercurial un autre DVCS qui est aussi bon.

Les avantages du DVCS deviennent évidents lorsque, par exemple, vous avez un référentiel dans votre serveur au bureau et que vous travaillez sur place. Pouvoir commiter localement sans avoir accès à votre serveur au bureau (et faire un rollback si nécessaire) est génial !