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

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #1
    Chroniqueur Actualités

    Homme Profil pro
    Rédacteur technique
    Inscrit en
    juin 2016
    Messages
    2 088
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Bénin

    Informations professionnelles :
    Activité : Rédacteur technique
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : juin 2016
    Messages : 2 088
    Points : 46 010
    Points
    46 010
    Par défaut 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.

    Nom : 1200px-Git-logo.svg.png
Affichages : 47160
Taille : 30,0 Ko

    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 »
    Contribuez au club : corrections, suggestions, critiques, ... Contactez le service news et Rédigez des actualités

  2. #2
    Membre éprouvé
    Homme Profil pro
    Développeur
    Inscrit en
    août 2003
    Messages
    589
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : août 2003
    Messages : 589
    Points : 1 219
    Points
    1 219
    Par défaut
    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. #3
    Membre du Club
    Nettoyeur de code de M....
    Inscrit en
    mars 2003
    Messages
    28
    Détails du profil
    Informations professionnelles :
    Activité : Nettoyeur de code de M....

    Informations forums :
    Inscription : mars 2003
    Messages : 28
    Points : 44
    Points
    44
    Par défaut Git est une Ferrari ...
    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.

  4. #4
    Membre chevronné
    Inscrit en
    janvier 2006
    Messages
    605
    Détails du profil
    Informations forums :
    Inscription : janvier 2006
    Messages : 605
    Points : 2 107
    Points
    2 107
    Par défaut Agité
    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.

  5. #5
    Membre régulier
    Homme Profil pro
    Développeur informatique
    Inscrit en
    mars 2009
    Messages
    39
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : mars 2009
    Messages : 39
    Points : 77
    Points
    77
    Par défaut
    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.

  6. #6
    Membre habitué
    Homme Profil pro
    Inscrit en
    juillet 2003
    Messages
    31
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : juillet 2003
    Messages : 31
    Points : 144
    Points
    144
    Par défaut
    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".

  7. #7
    Rédacteur/Modérateur


    Homme Profil pro
    Network game programmer
    Inscrit en
    juin 2010
    Messages
    6 792
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : Canada

    Informations professionnelles :
    Activité : Network game programmer

    Informations forums :
    Inscription : juin 2010
    Messages : 6 792
    Points : 31 103
    Points
    31 103
    Billets dans le blog
    4
    Par défaut
    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.
    Pensez à consulter la FAQ ou les cours et tutoriels de la section C++.
    Un peu de programmation réseau ?
    Aucune aide via MP ne sera dispensée. Merci d'utiliser les forums prévus à cet effet.

  8. #8
    Membre du Club
    Nettoyeur de code de M....
    Inscrit en
    mars 2003
    Messages
    28
    Détails du profil
    Informations professionnelles :
    Activité : Nettoyeur de code de M....

    Informations forums :
    Inscription : mars 2003
    Messages : 28
    Points : 44
    Points
    44
    Par défaut
    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.

  9. #9
    Membre chevronné
    Inscrit en
    janvier 2006
    Messages
    605
    Détails du profil
    Informations forums :
    Inscription : janvier 2006
    Messages : 605
    Points : 2 107
    Points
    2 107
    Par défaut Option
    Citation Envoyé par bigjeff Voir le message
    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.
    Eh bien, ce n'est pas pour rien que --force est une option! Une option qui est considérée comme une mauvaise pratique sauf dans des cas très particuliers (idéalement, uniquement dans une branche modifiée par un seul développeur). D'ailleurs certaines forges permettent d'interdire cette option ou de la limiter à certaines branches. Alors quand on a des utilisateurs qui font des erreurs avec, même après qu'on leur ait expliqué, faudrait réfléchir à cette interdiction.
    Alors non, encore une fois ça ne me gêne pas que des utilisateurs ne se servent que des commandes de base. Il y a certes des inconvénients (quand on ne réécrit pas l'historique on peut avoir des commits qui gagneraient à être fusionnés pour plus de clarté) mais je préfère alors le faire moi-même avant de faire un push --force ... mais dans ma branche.

    Citation Envoyé par bigjeff Voir le message
    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.
    Je doute que la documentation aide à faire différemment, le mieux c'est une formation. Pour ma part j'ai fait mes premiers pas avec Git en utilisant git-svn pour convertir des dépôts SVN pour ensuite faire des expériences avec les clones Git. C'est comme ça que j'ai appréhendé les différences.

    Citation Envoyé par SaiRictus Voir le message
    la CLI a été développé par des développeurs pour des développeurs ... et pas pour des utilisateurs.
    Même si on peut l'utiliser pour d'autres choses (de la documentation en LaTeX par exemple) Git reste avant tout un gestionnaire de code source, et ceux qui écrivent du code source, donc ses utilisateurs, sont en général... des développeurs.

    Citation Envoyé par Bousk Voir le message
    J'ai toujours préféré Mercurial pour ça, avec le client tortoise hg.
    Oui, c'est connu que Mercurial est plus simple que Git, même sans tortoise, mais un peu moins puissant. Maintenant si on a beaucoup de développeurs aux profils très différents dans une équipe, mieux vaut un outil plus simple que tout le monde maîtrise qu'un outil puissant où la moitié font des erreurs qui pénalisent tout le monde.

    Citation Envoyé par vbarr Voir le message
    Mais bon git est à la mode... en ce qui me concerne, je dis "vivement la prochaine".
    Eh oui, Git n'est pas parfait et il aura espérons-le des successeurs. Il y a d'ailleurs de nouveaux DVCS encore peu connus, ceux qui sont orientés patches (alors que git est orienté snapshot). Alors plutôt que d'attendre, ça vaudrait déjà le coup d'essayer Darcs ou Pijul.
    A la base, c'est plus simple, plus intuitif. Par contre, les adeptes des gui seront forcément déçus parce que ces outils n'en ont généralement pas - pas parce qu'ils le refusent mais seulement parce qu'ils sont beaucoup plus récents et que le développement d'une GUI se fait toujours après, en se basant sur les librairies ou la ligne de commandes. Git non plus n'avait pas de GUI, à l'origine.
    Ces outils ne sont pas encore aussi aboutis que Git, mais ça vaudrait peut-être le coup de déjà les commenter, histoire de ne pas attendre qu'ils soient aussi omniprésents que Git pour venir se plaindre de certains noms de commandes ou d'options qui auraient pu être corrigées depuis longtemps.

  10. #10
    Nouveau membre du Club
    Profil pro
    Inscrit en
    avril 2003
    Messages
    22
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : avril 2003
    Messages : 22
    Points : 31
    Points
    31
    Par défaut
    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.

  11. #11
    Membre chevronné
    Inscrit en
    janvier 2006
    Messages
    605
    Détails du profil
    Informations forums :
    Inscription : janvier 2006
    Messages : 605
    Points : 2 107
    Points
    2 107
    Par défaut j'espère que non
    Citation Envoyé par matd53 Voir le message
    J'espère que vous ne suggérez pas que GIT puisse être utilisé par les ressources humaines et les équipes marketing?
    Moi aussi j'espère que non parce que je me suis déjà vu plusieurs fois imposé un mauvais gestionnaire de versions ou simplement de mauvaises pratiques par ce genre de personnes.
    Faut dire que pour ces personnes, ces outils ne servent pas à gérer un historique, mais dans le meilleur des cas, à gérer les "livrables" (là pas de problème, je mais un tag sur la version livrée) ou dans le pire des cas, ils le voient comme un backup. Et là on nous impose des pratiques aberrantes comme un commit obligatoire par jour, à heure fixe, sous prétexte de suivre l'avancement du projet ou parce que le PC perso pourrait crasher pendant la nuit. Ce qui implique parfois de faire un commit d'une version non terminée, provoquant l'ire des collègues le lendemain matin. Mais comme c'est écrit dans le contrat, alors...

    Paradoxalement c'est une mauvaise pratique d'un client avec SVN qui m'a définitivement poussé vers GIt: le client nous imposait d'utiliser son SVN et considérait tout commit comme un livrable, ce qui m'empêchait de faire des commits intermédiaires alors que je travaillais par étapes. Ils ne l'avaient pas dit, je m'en suis rendu compte le jour où j'ai voulu faire un commit intermédiaire et qu'on m'a appelé quelques heures plus tard parce que le client avait cru bon d'essayer de l'installer. Du coup j'ai testé git-svn, j'ai pu faire mes commits intermédiaires localement, et pousser le tout au moment où c'était bien propre.
    Pour les partisans de SVN, je n'en pense absolument pas du mal, le mieux est de migrer quand on a un vrai cas d'utilisation, comme ce fut mon cas, et pas quand des accros au marketting nous l'imposent.
    Et Git a aussi ses défauts, raison pour laquelle je teste d'autres outils cités dans le message du dessus, mais en partant de dépôts Git tout en essayant de penser différemment, histoire de voir si ça rapporte réellement quelque chose.

  12. #12
    Membre expert Avatar de air-dex
    Homme Profil pro
    Inscrit en
    août 2010
    Messages
    1 621
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : France

    Informations forums :
    Inscription : août 2010
    Messages : 1 621
    Points : 3 644
    Points
    3 644
    Par défaut
    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 :

    Nom : svn-v-git-why-did-svn-lose-1024x865.png
Affichages : 2303
Taille : 171,2 Ko

    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 ?
    "Ils ne savaient pas que c'était impossible alors ils l'ont fait." Mark Twain

    Mon client Twitter Qt cross-platform Windows et Linux. (en cours de développement).

  13. #13
    Rédacteur/Modérateur


    Homme Profil pro
    Network game programmer
    Inscrit en
    juin 2010
    Messages
    6 792
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : Canada

    Informations professionnelles :
    Activité : Network game programmer

    Informations forums :
    Inscription : juin 2010
    Messages : 6 792
    Points : 31 103
    Points
    31 103
    Billets dans le blog
    4
    Par défaut
    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).
    Pensez à consulter la FAQ ou les cours et tutoriels de la section C++.
    Un peu de programmation réseau ?
    Aucune aide via MP ne sera dispensée. Merci d'utiliser les forums prévus à cet effet.

  14. #14
    Membre averti
    Homme Profil pro
    Dev
    Inscrit en
    novembre 2006
    Messages
    104
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Alpes Maritimes (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Dev

    Informations forums :
    Inscription : novembre 2006
    Messages : 104
    Points : 318
    Points
    318
    Par défaut
    Pour info ,les equipes de Java sont passé de Mercurial à Git pour
    • Taille de l'espace de meta data qui passe de 1.2Go a 300 Mo
    • On ne doit pas tout telecharger (toute les branches ) quand on fait un clone
    • Meilleur connaissance de Git de la part des développeurs
    • Meilleur gestion de Git dans les IDE
    • Passage à git Lab

    voir https://openjdk.java.net/jeps/357
    et https://openjdk.java.net/jeps/369

  15. #15
    Nouveau Candidat au Club
    Homme Profil pro
    Consultant informatique
    Inscrit en
    juin 2015
    Messages
    5
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 31
    Localisation : France, Seine Saint Denis (Île de France)

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : Transports

    Informations forums :
    Inscription : juin 2015
    Messages : 5
    Points : 0
    Points
    0
    Par défaut Devient git celui qui fait git
    Deux liens pour se familiariser en surface et en profondeur avec git :
    https://gitexplorer.com
    https://codeworks.recurse.com/issues...the-inside-out

    Profiter du week-end 😄

  16. #16
    Membre averti
    Homme Profil pro
    Dev
    Inscrit en
    novembre 2006
    Messages
    104
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Alpes Maritimes (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Dev

    Informations forums :
    Inscription : novembre 2006
    Messages : 104
    Points : 318
    Points
    318

  17. #17
    Membre chevronné
    Inscrit en
    janvier 2006
    Messages
    605
    Détails du profil
    Informations forums :
    Inscription : janvier 2006
    Messages : 605
    Points : 2 107
    Points
    2 107
    Par défaut Compatibilité
    Citation Envoyé par air-dex Voir le message
    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.
    Ah bon, tous les développeurs du monde partagent leur code sur Github? Tous les projets de code du monde sont devenus open source, tout à coup?
    Bon tu vas me dire qu'il y a aussi les dépôts privés dans Github. Mais comme maintenant le compte Github fait presque partie du CV d'un développeur, et qu'ils sont restreints sauf à utiliser l'offre payante, qui les utilise vraiment?

    Quoi qu'il en soit, qui a dit que je ne pouvais pas reverser dans git? De la même façon qu'autrefois j'utilisais Git en local pour pousser dans SVN via git-svn, les nouveaux DVCS ont tous une commande pour se synchroniser avec un Git. Pas encore au point, et on perd forcément des fonctionnalités (avec git-svn on ne pouvait avoir qu'un seul SVN et tout rebase restaurait l'historique à partir de ce seul SVN) mais ça finira par arriver.

    Citation Envoyé par air-dex Voir le message
    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.
    Git est arrivé avant GitHub, donc tu confonds peut-être la cause et la conséquence. Ta courbe de progression, intéressante au demeurant, montre bien qu'à l'arrivée de GitHub, git avait déjà largement supplanté les autres systèmes distribués comme Mercurial, faudrait peut-être se demander pourquoi, alors que Mercurial a une interface bien plus simple. C'est dommage aussi que ta courbe ne montre pas le moment où Sourceforge a intégré Git: avant Github, c'était Sourceforge qui était la "forge la plus populaire".
    Autre chose, la courbe confirme un point que je supposais, à savoir le temps qu'il a fallu à SVN pour surpasser le vieux CVS. Je le supposais parce que jusqu'en 2009 au moins la plupart de mes employeurs restaient encore à CVS. Mais vu que Sourceforge proposait déjà SVN à l'époque, pourquoi n'a-t-il pas décollé plus tôt, si on suit ta logique?

    Citation Envoyé par Bousk Voir le message
    C'est la raison pour laquelle j'ai du migrer mes projets perso dessus vers git (et github).
    Intéressant. Petite question, est-ce que tu as utilisé un outil de migration, pour préserver l'historique, ou tu as créé de nouveaux dépôts à partir de la dernière version?

  18. #18
    Membre averti
    Homme Profil pro
    Dev
    Inscrit en
    novembre 2006
    Messages
    104
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Alpes Maritimes (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Dev

    Informations forums :
    Inscription : novembre 2006
    Messages : 104
    Points : 318
    Points
    318
    Par défaut
    Citation Envoyé par esperanto Voir le message

    Intéressant. Petite question, est-ce que tu as utilisé un outil de migration, pour préserver l'historique, ou tu as créé de nouveaux dépôts à partir de la dernière version?
    pour Bousk , je ne sais pas ,mais pour java , ils ont conservé l'historique , ils ont mis au point un outil

  19. #19
    Rédacteur/Modérateur


    Homme Profil pro
    Network game programmer
    Inscrit en
    juin 2010
    Messages
    6 792
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : Canada

    Informations professionnelles :
    Activité : Network game programmer

    Informations forums :
    Inscription : juin 2010
    Messages : 6 792
    Points : 31 103
    Points
    31 103
    Billets dans le blog
    4
    Par défaut
    Je n'ai plus les détails mais ils donnaient les étapes détaillées pour faire la migration en gardant l'historique.
    Juste quelques clicks, c'était plutôt simple de mémoire.
    Pensez à consulter la FAQ ou les cours et tutoriels de la section C++.
    Un peu de programmation réseau ?
    Aucune aide via MP ne sera dispensée. Merci d'utiliser les forums prévus à cet effet.

Discussions similaires

  1. Les développeurs sont-ils des destructeurs d’emploi ?
    Par Hinault Romaric dans le forum Débats sur le développement - Le Best Of
    Réponses: 450
    Dernier message: 09/09/2020, 10h08
  2. Les développeurs détestent-ils les antivirus ?
    Par Hinault Romaric dans le forum Débats sur le développement - Le Best Of
    Réponses: 38
    Dernier message: 30/09/2019, 19h14
  3. Pourquoi les développeurs travaillent-ils la nuit ?
    Par Gordon Fowler dans le forum Humour Informatique
    Réponses: 122
    Dernier message: 06/10/2013, 01h30
  4. Les développeurs sont-ils des destructeurs d’emploi ?
    Par Hinault Romaric dans le forum Actualités
    Réponses: 345
    Dernier message: 05/05/2013, 17h20
  5. Réponses: 17
    Dernier message: 24/02/2012, 11h33

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo