wagaf a écrit :



Il semble qu’encore aujourd’hui tu n’a pas saisi grand chose au fonctionnement de Git, pas une seule de tes affirmations n’est juste " /> Mais en effet quand on appréhende l’outil comme si c’était CVS sans connaître le fonctionnement des branches, tags etc. on est vite perdu, ce n’est pas une critique.



Il est quasi impossible de perdre des données avec Git, même après un reset Hard ou des rebase tordus il est toujours possible de revenir en arrière, à moins d’avoir fait “git gc” dont le but est de nettoyer le repo.







Perso j’utilise svn au quotidien et à une époque je bossais aussi sur Clearcase et je n’ai jamais eu de soucis particuliers, même avec des branches, des tags et des externals un peu tordus. A une époque j’avais envisagé de tester Hg mais visiblement il n’est “plus à la mode”, tout le monde passe sur Git même pour un projet perso ou avec 2 collaborateurs …



Concernant la perte de données je ne saurais dire, juste un jour que j’ai voulu récup des maj d’un autre et j’ai jamais pu récupérer mes sources derrière, impossible de comprendre ce qu’il fallait faire et “l’expert” a séché en disant “ben t’es niqué t’as tout perdu, fallait pas faire comme ça”.



Depuis quand je veux merge sur un dépot Git j’utilise un truc atroce, je merge à la main sur un repo propre et ensuite j’écrase … (et je vous parlerai même pas de comment je fais pour nettoyer un fork, y’a des âmes sensibles ici " /> )

HarmattanBlow a écrit :



J’ai quand même une dizaine d’années d’expérience sur des nix, hein ? Et tout ça bien avant les UI user-friendly d’aujourd’hui. ;)



Et quant à la ligne de commandes, non ce n’est pas un outil très puissant. J’aimerais certes en avoir une (et, oui, la ligne de commande sous Windows, y compris Powershell, est exaspérante) mais je la réserverais aux tâches qui ne gagnent rien à avoir une UI et simplement parce qu’il est plus rapide de taper deux mots que d’ouvrir une fenêtre.



Or les outils de contrôle de version gagnent grandement à bénéficier d’un UI, ne serait-ce que pour un contrôle et un examen rapide des fichiers modifiés avant le commit ou la recherche .





Parce qu’apprendre les pelletées d’options textuelles de Git t’enseigne le fonctionne interne des algorithmes de Git ?



La seule chose que t’enseigne la ligne de commandes, c’est la ligne de commandes.







Merci ! Un qui me comprend ! " />



(Note: j’utilise les script quotidiennement et côté programmes obscurs j’ai déjà fort à faire avec les outils internes au travail, donc si on doit en plus en rajouter une couche avec les outils externes … on a pas fini)







petogo a écrit :



Dans le cas de git les lignes de commandes sont excellente et suivent un workflow logique. enchaîner les lignes de commandes permet de comprendre le workflow et l’utilité de chaque action. De plus la ligne de commande offrent un panel d’options très étendu qui permet d’aller bien plus vite qu’une GUI sur certains scénario.

Connaitre la ligne de commande permet également de l’utiliser sur un serveur, sur tout OS ou encore de l’associer git à des gestionnaire de tâche tel que Grunt ou Gulp.



Mais comme dit plus haut je suppose que c’est un point de vue windowsien, je suis d’accord c’est pas mal une gui dans un IDE, mais ça apporte une couche d’abstraction et un peu trop de “magie” pour comprendre ce qu’il se passe







Merci pour cette explication, je comprends le point de vue.

seb2411 a écrit :



En gros tu veux migrer sur un nouvel outil sans avoir a apprendre comment il fonctionne ? Soit tu reste sur ce que tu connais soit tu prends le temps de voir comment ça fonctionne.



Git n’est pas forcement complique une fois que tu connais les commandes de base. Et te permet de faire pas mal de choses. Bref un excellent outil très puissant.







Nope, je cherche à éviter de me prendre la tête “inutilement”. Les DVCS et VCS ne sont vraiment pas simples pour passer de l’un à l’autre car ils encouragent un mode de fonctionnement trop différent; mais en plus de ça Git rajoute une surcouche de complexité – et c’est cette dernière que je reproche, pas la première (par ex j’ai moins de problèmes avec Mercurial).