IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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

Le , par Bill Fassinou

193PARTAGES

13  0 
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 ?
Que pensez-vous de la courbe d'apprentissage de Git ?
Sa maîtrise est-elle nécessaire pour prétendre être un bon développeur ?
Entre Git CLI et GUI Git, lequel recommandez-vous d'apprendre en premier ? Pourquoi ?
Pensez-vous aussi que Git est un outil compliqué ? Quelles sont les raisons qui justifient votre avis ?
Les débutants se limitent souvent à la maîtrise d'une dizaine de commandes Git. Pensez-vous que cela est suffisant ?
Est-il nécessaire de connaître Git au bout des doigts ? À part contribuer à son développement, à quoi d'autre cela pourrait-il servir ?

Voir aussi

Git, le système distribué de gestion de versions, vient de passer à la version 2.28 et remplace le nom master par init.defaultBranch lors de la création d'une première branche dans un référentiel

Git 2.26.0 est disponible avec le protocole de transport v2 par défaut et une mise à jour de la sous-commande git sparse-checkout

Git, le système distribué de gestion de versions, vient de passer à la version 2.23 et propose deux commandes expérimentales pour réduire l'usage de la commande « git checkout »

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de SaiRictus
Membre régulier https://www.developpez.com
Le 03/08/2021 à 18:31

Que pensez-vous de la courbe d'apprentissage de Git ?
Les commandes de bases peuvent facilement être apprises (checkout, commit, ...)


Pensez-vous aussi que Git est un outil compliqué ? Quelles sont les raisons qui justifient votre avis ?
Oui, Mille fois oui !
Avoir une option qui change complètement le comportement d'une commande, devoir repasser quasi systématiquement par la documentation dès qu'on veut utiliser une commande sont pour moi des indications très claires que la CLI a été développé par des développeurs pour des développeurs ... et pas pour des utilisateurs.

C'est un peu comme si je développais une API REST et que pour utiliser le moindre point de terminaison, il faille systématiquement repasser par la documentation.


Sa maîtrise est-elle nécessaire pour prétendre être un bon développeur ?
Non ...
Git est censé être un outil qui m'aide à réaliser une tâche. Si je dois passer plus de temps à comprendre le fonctionnement de l'outil qu'à réaliser la tâche que cet outil est censé m'aider à accomplir, cela veut dire (de mon point de vue) que l'outil n'a pas été suffisamment bien conçu.


Les débutants se limitent souvent à la maîtrise d'une dizaine de commandes Git. Pensez-vous que cela est suffisant ?
Etre développeur ça implique déjà d'appréhender des choses suffisamment complexes en soit. Si je peux m'éviter d'avoir un outil supplémentaire qui se met en travers de mon chemin lorsque je veux réaliser une action de développement, je serais toujours preneur.
Je revendique le droit d'être fainéant/paresseux et ce n'est pas une aberration ni un gros mot de vouloir avoir des outils qui font le job "sans avoir l'impression de taper dans des trucs bas-niveau".

C'est exactement l'image dans laquelle je ne veux pas voir le métier s'enfermer : ceux qui sauraient ... seraient ceux qui font de la ligne de commande et les autres seraient des gros nuls (je caricature à peine).
Je n'en peux plus de cette image élitiste qu'on se donne.
Evidemment que quand il n'est pas possible de faire autrement, j'ai recours moi aussi à la ligne de commande. Mais j'en limite l'usage au strict minimum et surtout je scripte tout ce que je peux pour avoir à y remettre le nez le moins souvent possible.

Si nous avions tous cet état d'esprit, je pense qu'on aurait des UI Git super puissants qui du coup seraient utilisé par beaucoup de devs.

Je considère que mon travail consiste surtout à conseiller et éclairer des personnes non techniques en leur apportant le niveau d'informations suffisant afin de les aider à prendre leurs décisions et faire leur choix. Maitriser parfaitement tel ou tel outil n'est qu'un aspect du job (sur lequel malheureusement on se focalise trop).

Comme j'étais trop nul pour comprendre les commandes Git, j'ai fait un effort et je me suis mis à l'utilisation d'une librairie https://nuke.build qui m'a permis d'intégrer certaines commandes git que j'utilise souvent, mais de manière plus simple. Je fais évoluer ces scripts en fonction de mes besoins et ça me suffit.

L'idée pour moi, sur les projets sur lesquels je travaille, c'est de faire en sorte que les développeurs aient le moins possible à ce préoccuper de ces aspects que je considère comme étant bas-niveau. Proposer un outil qui encapsule / masque la complexité c'est exactement mon job : et c'est valable aussi bien pour les utilisateurs des applications que je peux développer que pour les consommateurs/utilisateurs de librairies/API que j'essaie de créer.
11  1 
Avatar de matd53
Nouveau membre du Club https://www.developpez.com
Le 04/08/2021 à 18:24
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.
J'espère que vous ne suggérez pas que GIT puisse être utilisé par les ressources humaines et les équipes marketing? Les avantages pour eux sont peut-être indirects mais il est totalement déraisonnable que GIT soit utilisé par ce type de profil étant donné la complexité de l'outil.

Personnellement je trouve que GIT est bien trop complexe dans la plupart des cas. C'est pensé par un geek surdoué pour les geeks et pour gérer un projet aux très nombreux contributeurs. 0 intuitivité, 0 logique avec toutes ces nombreuses commandes obscures qui demandent de lire énormément de documentation pour les comprendre.
Dans le cas de petits projets, c'est beaucoup trop complexe et ça demande beaucoup trop de temps de montée en compétence. C'est sans doute très bien après une semaine de formation et quelques mois d'utilisation avec pas mal de galères formatrices. Mais est-ce bien raisonnable?

L'essentiel des cas d'utilisation d'un logiciel de gestion de versions, c'est d'enregistrer son code, de récupérer le code des autres, de faire des merges, et d'avoir un historique.

Avec svn, en quelques heures on est opérationnel, ce qui n'est pas le cas avec GIT.
C'est vrai qu'SVN a certains défauts. Il faudrait peut-être quelque chose d'intermédiaire entre ces 2 outils.
6  1 
Avatar de Bousk
Rédacteur/Modérateur https://www.developpez.com
Le 04/08/2021 à 16:33
Je commence à réutiliser git au boulot, et c'est toujours une plaie.
La courbe d'apprentissage est énorme. Et pendant ce temps j'ai juste l'impression de régresser et perdre mon temps parce que toute action que je faisais en 2 clicks et 3 minutes sous SVN, Mercurial ou Perforce me prend maintenant 2 recherches Google pour retrouver la command line pour y parvenir, comprendre la doc et les cas particuliers. Donc je crée des .bat, ou des .txt de cheat sheet, et c'est fatigant.
Mon métier c'est programmeur. L'outil de version et sauvegarde de mon travail c'est un outil. Un outil est censé nous faciliter la tâche, pas l'inverse.
J'ai déjà des dizaines de middlewares avec lesquels je travaille, dont plusieurs dont on a le code source interne, de multiples plateformes et leur documentation, les équipes support et contacts de chacun de ces trucs.
Avec des millions de lignes de code, plusieurs projets et responsabilités à gérer, c'est à l'outil de se rendre attrayant pour être adopté.
J'ai toujours préféré Mercurial pour ça, avec le client tortoise hg.
5  1 
Avatar de smarties
Membre éprouvé https://www.developpez.com
Le 03/08/2021 à 15:39
Que pensez-vous de la courbe d'apprentissage de Git ?
Aucune idée, je ne me suis jamais trop penché dessus, jmais il y a quelques thème qu'il serait bien de connaître :
- récupérer des sources
- soumettre son travail
- résoudre les conflits
- revenir en arrière
- utiliser des branches
- mettre son travail de côté sans commiter

Sa maîtrise est-elle nécessaire pour prétendre être un bon développeur ?
Non mais je pense qu'il faut connaître quelques commandes de base pour déployer sur un serveur en mode console
A côté, les outils graphiques sont pratiques pour faire les tâches courantes

Entre Git CLI et GUI Git, lequel recommandez-vous d'apprendre en premier ? Pourquoi ?
GUI c'est visuel et donc il est plus facile d'apprendre à partir de ce que l'on voit plutôt que de retenir des commandes par cœur au début.

Pensez-vous aussi que Git est un outil compliqué ? Quelles sont les raisons qui justifient votre avis ?
Peut être un peu car j'ai cherché que des cas particulier

Les débutants se limitent souvent à la maîtrise d'une dizaine de commandes Git. Pensez-vous que cela est suffisant ?
Oui et ensuite il y a Google, les forums pour des choses plus spécifiques
3  0 
Avatar de vbarr
Membre habitué https://www.developpez.com
Le 03/08/2021 à 22:56
J'utilise git tous les jours git depuis 4 ans. Je trouve que c'est un outil assez puissant mais compliqué. Tant que tout va bien, c'est assez simple, mais quand on commence avoir des problèmes ça devient vite la galère et il faut faire des dessins et sortir la doc et les forums parce que qu'on se retrouve dans un magma de commits incompréhensible.

Par exemple, savoir simplement la liste des demandes de fusion (pull request) qui a été dans une branche, ce n'est pas simple pour le débutant. Ah oui c'est vrai, git ne sais pas ce qu'est une pull request, il ne connaît que les commits !
Et vous voulez comment un fichier est dans une autre branche ? C'est pas immédiat non plus.

Comme il est dit plus haut, git est un truc d'assez bas niveau, d'où sa puissance, mais très souvent je le trouve inutilement compliqué et on peu perdre du temps à batailler avec. J'utilisais SVN auparavant et franchement, dans une entreprise où on a de toute façon un dépôt centralisé, je ne trouve pas que git ait été un progrès car la simplicité de SubVersioN et son outillage nous rendaient la vie plus facile.

Mais bon git est à la mode... en ce qui me concerne, je dis "vivement la prochaine".
4  1 
Avatar de bigjeff
Membre du Club https://www.developpez.com
Le 04/08/2021 à 16:35
Citation Envoyé par esperanto Voir le message

Je suis un utilisateur habitué de Git et pourtant je ne suis pas certain de comprendre. Déjà faudrait utiliser les bons termes, on ne "commite" pas vers un dépôt commun (à moins que tu fasses les modifications directement dans le .git?), on pousse (push). Et le push, ça consiste à prendre tous les commits (là c'est le bon terme) du dépôt local et les envoyer séparément, un par un, vers le dépôt distant. Et git a le bon goût de refuser si tu n'es pas à jour (sauf si tu utilises --force) alors où est le problème? Quand je le fais je sais exactement ce que je pousse parce que j'ai lu les commits avant (c'est dans ce cas que j'utilise une GUI!). A l'inverse quand on récupère le contenu du dépôt distant, il est soit simplement rangé dans un coin (fetch) soit fusionné au contenu local (pull = fetch + merge).
Le seul cas où on "commite tout", c'est git commit -a. Mais même quand je l'utilise, je relis ensuite et je n'hésite pas à faire des --amend, du moins tant que je n'ai pas fait un push.
Désolé je me suis très mal exprimé, je me souviens d'un cas où la personne faisait un pull de la branche de la livraison ensuite il modifiait son code et faisait un push force en se disant (sans volonté de mal faire) je ne pousse que mes modifications. Mais avant il ne faisait aucun pull pour récupérer les modifications des autres.
Pour lui il ne commitait(j'utilise ce terme car il utilisait la philosophie SVN et non Git) que ses modifications sans toucher au reste. Quand on lui a expliqué ce qu'il faisait il a compris qu'il aurait pu casser pas mal de chose.

C'est pour cela que je pense que la documentation est importante car j'ai vu plusieurs personnes se dire (encore une fois sans vouloir faire mal) je connais SVN, Git s'est un autre gestionnaire de source donc je fais pareil.
D'ailleurs, je lis dans les commentaires que c'est un gestionnaire de source comme un autre et il suffit de lire la documentation. Mais avant tout il faut comprendre la philosophie du produit et comprendre comment il fonctionne.
Pour l'instant toutes les personnes que j'ai croisé qui travaillent avec Git me disent que Git est un super outil mais qu'il ne faut pas faire n'importe quoi.

On m'a déjà demandé si Git est une bonne solution, ma réponse est oui SI on prévoit de la doc et de la disponibilité d'un architecte (ou un utilisateur confirmé) pour supporter l'équipe. Si ces conditions ne sont pas en place il y a danger.
2  0 
Avatar de air-dex
Membre expert https://www.developpez.com
Le 05/08/2021 à 20:02
Citation Envoyé par esperanto Voir le message
Mais les alternatives qui pourraient faire mieux tout en étant plus simples ne sont pour le moment pas encore dans un état suffisamment mature pour passer en production. Ou alors il leur manque l'intégration dans des IDE populaires, ce qui rebutera certains utilisateurs (je n'en fais pas partie mais beaucoup de mes collègues oui)
Plus que l'intégration à des EDI populaires il manque l'intégration à des forges populaires. Ta solution obscure ne te servira à rien si tu ne peux pas reverser ton code dans le pot commun avec ou pouvoir mettre ton code tranquillement à l'abri en ligne avec.

C'est d'ailleurs comme ça que git lui-même s'est imposé, parce qu'il était et est toujours le système de contrôle de version fétiche de GitHub. C'est aussi celui de GitLab. Idem avec Bitbucket, qui certes propose aussi du Mercurial (mais plus de SVN ni de CVS visiblement) mais dont le slogan est "la solution Git destinée aux équipes professionnelles". Cf. l'article (en anglais) "Git didn't beat SVN, GitHub did" qui résume bien les choses :



Citation Envoyé par Bousk Voir le message
Mon métier c'est programmeur. L'outil de version et sauvegarde de mon travail c'est un outil. Un outil est censé nous faciliter la tâche, pas l'inverse.
J'ai déjà des dizaines de middlewares avec lesquels je travaille, dont plusieurs dont on a le code source interne, de multiples plateformes et leur documentation, les équipes support et contacts de chacun de ces trucs.
Avec des millions de lignes de code, plusieurs projets et responsabilités à gérer, c'est à l'outil de se rendre attrayant pour être adopté.
J'ai toujours préféré Mercurial pour ça, avec le client tortoise hg.
+1000. Ce n'est pas parce que quelqu'un qui est dans ce secteur à naturellement un profil à mettre le nez dans le cambouis qu'il doit le faire pour tout et n'importe quoi, que ce soit pour le premier outil venu ou pour la connexion Wifi ou Bluetooth de son ordinateur Linux (ça rappellera des souvenirs à certains).

Git a été conçu par un geek pour des geeks, avec toutes les lacunes en matière d'expérience utilisateur, d'ergonomie et de qualité de vie que cela peut avoir. Et aussi avec les fétichismes geeks (linuxiens) qui vont bien telles que la CLI et ses moult options textuelles et complexes à rallonges ainsi que les fichiers à aller éditer (avec vim j'imagine ) 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.

En tant que techniciens on sait que c'est l'outil qui doit être notre esclave et pas nous qui devons être les esclaves de l'outil. Ce serait bien que certains s'en rappellent. Surtout avec les téléphones, mais ceci est un autre débat.

C'est d'ailleurs pour ça que j'ai préféré Bazaar à Git pour mes projets perso pendant très longtemps, parce qu'avec une bien meilleure UX que Git. Mais quand tu vois que c'est de moins en moins supporté même par son éditeur, que le logiciel est désormais complètement mort (la dernière version date d'il y a 5 ans 1/2, qui elle-même sortait 2 ans 1/2 après la précédente), qu'il n'y a guère que Launchpad qui le supporte comme forge, que c'est quand même plus utile de savoir maîtriser GitHub (où Git est roi) que Launchpad, que c'est mieux de ne pas avoir 1 dossier par branche... Tu finis par te faire une raison et passer complètement à Git. Certes certains ont forké Bazaar en Breezy, mais à quoi bon si ça reste ultra confidentiel ?
3  1 
Avatar de Bousk
Rédacteur/Modérateur https://www.developpez.com
Le 05/08/2021 à 20:15
BitBucket ne propose plus Mercurial depuis 2020.
https://bitbucket.org/blog/sunsettin...t-in-bitbucket
C'est la raison pour laquelle j'ai du migrer mes projets perso dessus vers git (et github).
2  0 
Avatar de bigjeff
Membre du Club https://www.developpez.com
Le 03/08/2021 à 16:29
Git permet beaucoup d'actions et il faut bien le comprendre.

Il faut comprendre comment fonctionne cet outil et éviter deux erreurs :
  • Ne pas utiliser Git comme SVN, ce n'est pas la même philosophie
  • Ne pas utiliser TortoiseGit qui essaie de ressembler à SVN


Un point essentiel quand on commite un dépôt dans un dépôt commun on commite tout pas uniquement ce que l'on croit avoir modifié. Combien de fois on a expliqué cette situation car la personne n'avait pas mis à jour son dépôt.
Pour des utilisateurs habitués à Git cela peu paraître logique ce que j'écris mais ceux qui arrivent sur ce produit commettent ces erreurs et d'autres.

La solution pour moi documenter les commandes et les situations, avoir un Git d'essai pour se pratiquer. Et surtout dire aux employés si vous avez le moindre doute demandez à quelqu'un de l'équipe mais ne faites rien si vous ne comprenez pas.
1  0 
Avatar de esperanto
Membre chevronné https://www.developpez.com
Le 03/08/2021 à 17:23
Citation Envoyé par Bill Fassinou Voir le message
Que pensez-vous de la courbe d'apprentissage de Git ?
Plus facile que pour les autres VCS distribués qui l'ont précédé (la première fois que j'ai entendu parler de VCS distribués, on en était à Gnu Arch/tla, qui était une horreur qui a bien failli me dégouter de la notion de système distribué). Par contre abondance de commandes et d'options qui fait que 12 ans après mes débuts je découvre encore de nouvelles commandes ou options à des commandes existantes.

Citation Envoyé par Bill Fassinou Voir le message
Pensez-vous aussi que Git est un outil compliqué ? Quelles sont les raisons qui justifient votre avis ?
Il y a beaucoup de commandes et d'options compliquées, on en fait même des parodies
Mais les alternatives qui pourraient faire mieux tout en étant plus simples ne sont pour le moment pas encore dans un état suffisamment mature pour passer en production. Ou alors il leur manque l'intégration dans des IDE populaires, ce qui rebutera certains utilisateurs (je n'en fais pas partie mais beaucoup de mes collègues oui)

Citation Envoyé par Bill Fassinou Voir le message
L'effet de "git checkout" dépend du contexte. [...] Les commandes git switch et git restore apportent plus de clarté
Je n'avais pas conscience de ce détail, j'utilisais checkout par habitude, mais avec les exemples que vous avez donnés, il devient évident que le design de cette commande a été mal fait au départ. Est-ce pour autant une erreur de continuer de l'utiliser? Au moins on reste compatible avec d'anciennes versions de git (au cas où on utilise des scripts notamment). Alors à moins qu'elle soit classée obsolète et destinée à disparaître, je dirais que je vais prendre tout mon temps pour m'habituer aux alternatives, si simples soient-elles. C'est comme quand tu apprends une langue, un mot nouveau ne chasse pas toujours l'ancien immédiatement.
En revanche il serait bon que les auteurs de documentation sur Git (pas la documentation de Git lui-même, mais les auteurs tiers) pensent à se mettre à jour et à valoriser les nouvelles commandes, tout en insistant sur le fait qu'elles n'existent que depuis une version récente de git, car tout le monde n'a pas toujours la dernière version. C'est seulement de cette façon que ces commandes s'imposeront, et alors les auteurs pourront penser à classer checkout obsolète, voire à le supprimer (en sachant qu'on pourra toujours le restaurer avec des aliases)

Citation Envoyé par Bill Fassinou Voir le message
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>".
En fait le vrai problème, c'est que quand vous ne spécifiez qu'un seul argument, git essaie de deviner si c'est un nom de fichier ou de révision. Au point que quand je tente d'utiliser l'auto-complétion dans mon terminal sous linux, parfois il privilégie un nom de fichier, parfois de branche. En voulant économiser un --nom-de-paramètre, en voulant simplifier, on a en réalité compliqué cette commande inutilement.

Citation Envoyé par Bill Fassinou Voir le message
Les débutants se limitent souvent à la maîtrise d'une dizaine de commandes Git. Pensez-vous que cela est suffisant ?
Si je dois collaborer avec des débutants, alors je préfère qu'ils se limitent à des commandes basiques plutôt que de lancer des git push --force foireux faute d'avoir vérifié avant que le contenu était correct (parce qu'après c'est moi qui récupère et dois gérer le contenu foireux...)

Citation Envoyé par Bill Fassinou Voir le message
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. [...] Un autre domaine dans lequel les interfaces graphiques de Git ont un avantage est l'affichage des différences.
Exactement. Pour ma part j'utilise une petite interface graphique (Gitk) uniquement pour visualiser le contenu du dépôt. Mais pour toute opération qui modifie le dépôt, là j'utilise la ligne de commandes. Toujours.

Citation Envoyé par bigjeff Voir le message
Un point essentiel quand on commite un dépôt dans un dépôt commun on commite tout pas uniquement ce que l'on croit avoir modifié. Combien de fois on a expliqué cette situation car la personne n'avait pas mis à jour son dépôt.
Pour des utilisateurs habitués à Git cela peu paraître logique ce que j'écris mais ceux qui arrivent sur ce produit commettent ces erreurs et d'autres.
Je suis un utilisateur habitué de Git et pourtant je ne suis pas certain de comprendre. Déjà faudrait utiliser les bons termes, on ne "commite" pas vers un dépôt commun (à moins que tu fasses les modifications directement dans le .git?), on pousse (push). Et le push, ça consiste à prendre tous les commits (là c'est le bon terme) du dépôt local et les envoyer séparément, un par un, vers le dépôt distant. Et git a le bon goût de refuser si tu n'es pas à jour (sauf si tu utilises --force) alors où est le problème? Quand je le fais je sais exactement ce que je pousse parce que j'ai lu les commits avant (c'est dans ce cas que j'utilise une GUI!). A l'inverse quand on récupère le contenu du dépôt distant, il est soit simplement rangé dans un coin (fetch) soit fusionné au contenu local (pull = fetch + merge).
Le seul cas où on "commite tout", c'est git commit -a. Mais même quand je l'utilise, je relis ensuite et je n'hésite pas à faire des --amend, du moins tant que je n'ai pas fait un push.
1  0