Git : les développeurs utilisent-ils le système de contrôle de version de façon optimale ?
Git : les développeurs utilisent-ils le système de contrôle de version de façon optimale ?
Il semblerait que beaucoup de développeurs se limitent au strict minimum
Git est un outil DevOps utilisé pour la gestion du code source. Il s'agit d'un système de contrôle de version gratuit et open source utilisé pour gérer efficacement des projets de petite à très grande envergure. Git est utilisé pour suivre les modifications du code source, permettant à plusieurs développeurs de travailler ensemble sur un développement non linéaire. Linus Torvalds a créé Git en 2005 pour le développement du noyau Linux. Depuis le développement et la publication de Git, il a gagné une énorme popularité parmi les développeurs et, étant open source, il a intégré de nombreuses fonctionnalités.
Les capacités de Git sont-elles sous-exploitées par les développeurs ?
Aujourd'hui, un nombre impressionnant de projets utilisent Git pour le contrôle de version, qu'ils soient commerciaux ou personnels. En outre, Git est utile et possède des avantages pour toutes les équipes, des équipes de développeurs aux équipes de marketing en passant les équipes de ressources humaines ou encore les équipes de concepteurs. Cependant, même si le système de contrôle de version est aussi populaire, il ne serait pas utilisé de façon optimale. Chaque nouvelle version de Git apporte des améliorations, ajoute de nouvelles fonctionnalités et rend l'utilisation du logiciel plus facile.
Les mises à jour ajoutent également des fonctions pour accroître la productivité des utilisateurs de Git. Mais selon les experts, ces nouvelles fonctions et fonctionnalités passent très souvent inaperçues. L'on estime que les développeurs restent cantonnés à leur utilisation de base. Il existerait plusieurs explications à ce problème, mais les plus citées dans la communauté sont : Git est déroutant et difficile à prendre en main ; les débutants se jettent sur les outils GUI pour Git, etc. Dans un billet de blogue la semaine dernière, Dragos Barosan, un développeur, donne son avis sur ce problème.
Selon lui, si les utilisateurs ont une connaissance limitée de Git et le trouvent déroutant, c'est parce qu'ils n'explorent pas ou n'apprennent pas en profondeur le système de contrôle de version. Barosan donne l'exemple de nouvelles fonctionnalités introduites dans la version 2.23 du logiciel, notamment "switch" et "restore", pour tenter de réduire les agacements que pourrait engendrer la commande "git checkout". Ces commandes seraient très peu populaires. Il estime que "git checkout" est l'une des nombreuses raisons pour lesquelles les nouveaux arrivants trouvent Git déroutant. L'effet de "git checkout" dépend du contexte.
La façon dont la plupart des gens l'utilisent est de changer la branche active dans leur dépôt local. Plus précisément, ils l'utilisent pour changer la branche vers laquelle HEAD pointe. Par exemple, vous pouvez passer à la branche de développement si vous êtes sur la branche principale : "git checkout develop". Vous pouvez aussi faire en sorte que votre pointeur HEAD fasse référence à un commit spécifique au lieu d'une branche (pour atteindre l'état HEAD détaché). Là où les choses se compliquent, c'est lorsque vous fournissez un fichier comme argument au lieu d'une branche ou d'un commit.
À ce stade, les modifications locales apportées à ce fichier seront rejetées et le fichier sera restauré à l'état de branche. Par exemple, si vous avez extrait la branche "develop" et que vous avez apporté des modifications au fichier test.txt, vous pouvez restaurer le fichier tel qu'il est dans le dernier commit de votre branche avec : "checkout -- test.txt". D'après Barosan, si vous regardez ces deux comportements pour la première fois, vous pouvez penser que cela n'a aucun sens.
Les commandes git switch et git restore apportent plus de clarté
Pourquoi une seule commande fait-elle deux actions différentes ? Eh bien, les choses sont un peu plus subtiles que cela. Si vous regardez la documentation de Git, vous pouvez voir que la commande a un argument supplémentaire qui est généralement omis : "git checkout <tree-ish> -- <pathspec>". Que signifie la partie "<tree-ish>" ? Cela peut signifier beaucoup de choses différentes, mais le plus souvent cela signifie un hash de commit ou bien un nom de branche. Par défaut, on considère que c'est la branche actuelle, mais cela peut être n'importe quelle autre branche ou commit.
Ainsi, les choses commencent peut-être à avoir du sens. Lorsque vous fournissez seulement une branche ou un commit comme argument pour "git checkout", alors il changera tous vos fichiers à leur état dans la révision correspondante, mais si vous spécifiez aussi un nom de fichier, il changera seulement l'état de ce fichier pour correspondre à la révision spécifiée. C'est un comportement que les débutants peuvent trouver déroutant et ainsi choisir de ne pas l'utiliser ou de voir si les interfaces utilisateur de Git proposent une prise en charge abstraite de cette commande. Mais la version 2.23 de Git a apporté du nouveau.
Cette version de Git a été publiée avec environ 500 changements, y compris deux nouvelles sous-commandes conçues pour fournir une alternative expérimentale à la commande "git checkout". Les sous-commandes "git switch" et "git restore" sont conçues pour indiquer clairement si l'intention est de modifier des fichiers ou des branches. Comme l'a expliqué l'équipe de développement de Git, la commande "git switch" est utilisée pour passer à une nouvelle branche (si nécessaire en la créant d'abord), tandis que "git restore" peut être utilisé pour restaurer les changements d'un commit donné.
Lors de la publication de Git 2.23 en 2019, l'équipe a affirmé que l'utilisation de "git checkout" pour ces deux fonctions a provoqué une certaine confusion chez certains nouveaux utilisateurs de Git. Elle a expliqué que si "git switch" peut être considéré comme une invocation sans option de "git checkout", "git restore" est en revanche beaucoup plus intéressant. Lorsque vous utilisez "git restore" pour restaurer les modifications d'un commit, il est plus facile de déterminer exactement quels fichiers vont être modifiés, ce qu'ils vont devenir et où ils vont être modifiés.
Il y a deux options pour spécifier où les changements restaurés iront – la copie de travail ou votre index. Il permet également de comprendre plus facilement d'où provient le contenu que vous restaurez grâce à l'option "--source".
Devriez-vous apprendre Git dans une GUI ou en ligne de commande ?
Les GUI de Git sont des programmes qui offrent une expérience interactive de Git. Vous obtenez souvent une visualisation de l'état de votre dépôt, de l'historique des livraisons et des branches. Au lieu d'écrire vos commandes dans un terminal, vous pouvez cliquer sur des boutons et des éléments de menu. Les interfaces graphiques de Git peuvent être des applications autonomes comme GitHub Desktop, Sourcetree et GitKraken ; ou elles peuvent faire partie d'un éditeur de texte ou d'un environnement de développement intégré (EDI) comme Visual Studio Code, Atom et PyCharm.
En revanche, Git CLI (Command Line Interface) est basé sur des commandes. Plus précisément, vous ouvrez un terminal, tapez des commandes et dites à Git ce qu'il doit faire. C'est l'interface par défaut et celle que vous obtenez lorsque vous installez Git. À la question de savoir lequel vous devez apprendre en premier, les experts conseillent majoritairement Git CLI. Selon ces derniers, il existe plusieurs avantages à cela, dont en voici quelques-unes :
- Git CLI est le même dans tous les environnements et sur toutes les machines. Tant que vous avez installé Git, vous avez accès à Git CLI. Mais on ne peut pas en dire autant des interfaces graphiques. Il se peut que vous ne puissiez pas les installer en raison de politiques informatiques ou qu'elles ne soient pas disponibles pour votre système d'exploitation ;
- l'exhaustivité de l'expérience Git est un autre avantage de la CLI par rapport aux interfaces graphiques. Toutes les fonctionnalités de Git sont couvertes par l'interface CLI. Cependant, toutes les interfaces graphiques ne couvrent pas toutes les fonctionnalités de Git ;
- vous avez plus de chances d'obtenir de l'aide en ligne si vous posez une question en utilisant la terminologie de la CLI de Git plutôt qu'en utilisant la terminologie d'une interface graphique spécifique de Git. En plus de cela, la plupart des interfaces graphiques de Git ont une documentation non exhaustive ou inexistante ;
- etc.
Git CLI n'est cependant pas parfait. Il existe des domaines où les interfaces graphiques Git sont supérieures à l'interface CLI. Lorsqu'il s'agit de visualiser les branches et l'historique des livraisons, les interfaces graphiques Git offrent une expérience plus agréable visuellement et plus interactive. Vous pouvez regarder l'historique des livraisons, vous pouvez cliquer sur chaque livraison et voir ce qui s'est passé dans cette livraison, voir qui l'a faite et ainsi de suite. La sortie par défaut de "git log" affichée dans le terminal peut être difficile à appréhender pour un débutant.
Toutefois, vous pouvez la rendre plus agréable visuellement et plus facile à comprendre. Un autre domaine dans lequel les interfaces graphiques de Git ont un avantage est l'affichage des différences. Le résultat de la commande "git diff" affiché dans le terminal est parfois difficile à comprendre. Cependant, même avec ces deux inconvénients mineurs, il est recommandé d'apprendre d'abord à utiliser Git en ligne de commande. Assurez-vous de comprendre les concepts de base : cloning, staging, committing, checking out commits, branches, remotes, merging et rebasing.
« Ensuite, si vous souhaitez utiliser une interface graphique Git, n'hésitez pas à le faire. Consommez-la avec modération et essayez simplement de ne pas trop vous y fier. Tôt ou tard, vous vous retrouverez dans une situation délicate avec Git, et la ligne de commande sera alors votre seul ami », a commenté un ingénieur logiciel.
Git est-il un outil nécessaire ou les développeurs peuvent-ils s'en passer ?
Par ailleurs, malgré cette recommandation, certains estiment qu'il n'est pas nécessaire de maîtriser Git. « Je ne suis pas payé pour connaître Git au bout des doigts. Je suis payé pour livrer et corriger du code et pour ne pas marcher sur les pieds des autres. Je suis conscient que la deuxième partie est ce que beaucoup considèrent comme un cas idéal pour connaître Git de fond en comble, mais ce n'est pas mon cas et celui de presque tous les développeurs avec lesquels j'ai travaillé. Je veux en effet pouvoir lancer une commande et en avoir fini avec elle », a répondu un développeur.
Selon ce développeur, les capacités de Git sont surcotées. « Par exemple, Git ne fait pas un bon travail pour amener les changements à distance dans votre branche. Il peut faire beaucoup mieux, comme détecter des changements identiques simultanés, ce qui est quelque chose qui arrive souvent dans les grandes équipes », estime-t-il. « Le problème de Git est super classique dans tous les outils de développement. Les créateurs ont exposé directement les structures de données sous-jacentes et font peser sur l'utilisateur la charge de les apprendre à fond. Par opposition à la création d'une bonne interface utilisateur », a-t-il ajouté.
Bien sûr, il y a eu des contre-arguments. Pour d'autres, la maîtrise de Git est un atout important pour l'ingénieur d'aujourd'hui. Ceux-ci estiment que les entreprises se tournent de plus en plus vers des pratiques modernes de développement, comme le DevOps et le Database DevOps, afin de profiter des fonctionnalités telles que l'intégration continue et la livraison continue. « Votre argument est toujours le même que celui des autres détracteurs de Git, et il est toujours faux. Cela fait partie de votre travail, cela fait partie de la livraison et de la correction du code », a déclaré l'un d'entre eux.
« C'est la même chose que tout ce que vous utilisez. C'est peut-être une plus grande surface à laquelle vous êtes exposé, mais ce n'est pas différent de l'intégration continue et la livraison continue, des systèmes de construction ou de quelque chose comme un gestionnaire de paquets. Vous n'avez pas besoin de comprendre le fonctionnement de pip, npm ou maven pour livrer efficacement un logiciel, mais si vous avez des problèmes, vous n'avez pas d'autre solution que rm-rf », a-t-il ajouté. Enfin, il faut noter que les arguments selon lesquels Git est un outil compliqué à utiliser reviennent très souvent et semblent dominer le débat.
« Le problème ici est que Git est beaucoup plus compliqué à apprendre, parce qu'il a 10 000 options qui peuvent faire ce que vous voulez faire ou faire quelque chose de complètement différent. Imaginez que votre pipeline de déploiement vous oblige à créer manuellement des paquets TCP à envoyer à vos machines pour déployer du code. Diriez-vous toujours : "cela fait partie de votre travail, cela fait partie de la livraison et de la correction du code, ou diriez-vous simplement que c'est stupide ? Avec Git, vous passez plus de temps à apprendre et à vous battre avec les outils nécessaires à la livraison du code qu'à écrire et à tester le code », a commenté un utilisateur du groupe de ceux qui voient Git comme logiciel difficile à prendre en main.
Source : billet de blogue
Et vous ?
Quel est votre avis sur le sujet ?
Voir aussi
Répondre avec citation
Envoyé par Bill Fassinou
) au fin fond des fichiers de configuration de ton projet ou de Git lui-même. Bref le genre de choses qui ne te pose pas problème si tu n'as rien d'autre à faire.
Surtout avec les téléphones, mais ceci est un autre débat.
Partager