Reprise du message précédent :

 
Je ne crois pas qu'il y a plus de 50% utilisant un GUI dans mon entourage.

 
Quel intérêt ?

Moi. C'était un peu chiant parce que beaucoup voyaient le management des branches différement.
Perso j'utilise uniquement git j'ai jamais eu de soucis et j'arrive toujours à retomber sur mes pattes. Y'a un truc qui fait chier, c'est quand tu rebases et que y'a rien à add dans un resolve, c'est un peu l'enfer.
 
Bazaar peut-être?

Ça évite les commit de merdes qui contiennent des choses qui n'ont pas à être commitées, ou des choses qui n'appartiennent pas à ce commit.
Pour le message de commit on a des règles strictes, on a très peu de one line.

 
C'est quel langage ?
 
Comme dit plus haut, avec un ( ou plusieurs ) gitignore, je ne vois pas comment tu peux te rater.
 
Et j'ai toujours bossé avec des PR, du coup tu ne merges jamais rien directement, ce qui permet de rattraper toute connerie ( ce qui est très rare de toute façon ).

 
on est d'accord, la version GUI avec ces ptites cases à cocher au moins t'évite à coup sur ce soucis...

 
Mercurial is all good  

Ah ben moi si on m'explique clairement quelles sont les règles de add et de commit je le fais hein
D'ailleurs, dans un git commit le -e te permet réellement de faire quoi ? tu as un cas concret ?

 
Ici 0% de gens en GUI pour Git.
 
Une fois que t'a le flow qui va bien, ya quasi aucune raison de sortir des clous
 
D'ailleurs au final la seule condition pour être efficace en arrivant chez nous, c'est avoir compris les grandes lignes de Git, le reste c'est pas grave, vu que tout passe par des PR.

Ici, on tourne sur du git-svn. On utilise la ligne de commande 98% du temps, l'UI c'est juste quand on veut voir le changeset d'un commit particulier.

 
git add -u aussi
 
Ca fait 5 ans que je fais du git en CLI à peu près, visiblement j'ai du avoir moins d'emmerdes que vous (on a eu à gérer des problématiques sympa avec un repo de 10Go et on a bien joué avec les grafts qd on avait migré sous git et qu'on s'était rendu compte au bout de 2 semaines qu'on avait merdé la migration de certaines branches/tags).

Pourtant c'est infiniment plus pratique à manipuler en GUI, pour visualiser les branches, faire des commits partiels, visualiser les différences entre 2 commits, consulter l'historique d'un fichier à travers les branches, etc

http://chrishadfield.ca/space-oddity/
s'te merdier.

-e force l'édition dans $EDITOR. On a tous vim par défaut y'a une coloration syntaxique qui permet de savoir si la première ligne du commit est trop longue.

Peu importe le langage. add -p permet de virer les sauts de ligne inutiles et d'avoir une bonne granularité dans ton commit.

Je connaissais pas -u, c'est sympa. Idem, aucune emmerde. Et pourtant parfois on fait des branches de branches et des rebases à tout va. Notre graph est manifique, avant c'était un plan de métro.

 
Quand je git commit j'ouvre les premiers quotes du message puis j'appuie sur entrée et ensuite la cli attends que je tape les autres lignes

commit fait

 
Revoir ses diffs pour les minimiser avant de les commettre c'est la base, tu commits pas tes fichiers tels quels sans relire ta copie. Ou alors je bosse avec des gens propres  

 
Voilà    
 
Je vois toujours pas l'intérêt.
 
Je comprends pas ce qu'il entend par granularité.

Je pense qu'il bosse avec des mecs qui ont l'habitude de faire git commit -a -m "Un message bien bullshit qui sert à rien" à tout bout de champ

Ce qui m'inquiète, c'est que le genre te type qui dit: "il faut utiliser tel outil" avec un outil manuel force du boulot sur les autres.
 
Quand je force l'équipe à utiliser le même IDE avec le même formateur de code, c'est pour leur virer le boulot de formatage et une tonne de charge cognitive. Quand t'es en ligne de commande, tu dois tout apprendre et plus rien n'est explorable. (enfin, faire un merge avec git, c'est toujours l'horreur quel que soit l'outil, je pense que la ligne de commande est tellement merdique que les IDE savent pas la masquer)

 
Hmm on fait l'inverse :tu viens avec ton IDE favori (et ton OS que tu veux), par contre tu manges :
 

• le fichier editor config pour les règles du jeu de base
• le coding style/linter (genre standard pour JS)
• tu bosses dans ta branche et tu fais une PR

Au pire tu rebases de temps en temps, mais le boulot d'intégration c'est autre chose.

tu peux jamais régler 2 formateurs de la même manière, ils ont pas les même options.

Je comprends pas ce que tu veux dire

On a jamais eu de soucis/conflits vis à vis de nos linters (à part peut être la casse non vérifiée pour des appels de modules, pour un collaborateur sous Windows )

En tout cas avec JS et https://github.com/feross/standard , mais je ne saurai dire pour les autres langages/styles

bienvenue dans le passé.
 
au moins ça explique pourquoi je dois tout le temps corriger certaines libs pour qu'elles marchent dans les workers.

Ici on a une politique de branching un peu merdique à grande échelle, mais pour le quotidien, on bosse sur des feature branch pour chaque modif et on fait des merge requests sur gitlab.
La majorité de mes interactions d'ajout de fichier, de diff, de commit c'est tout dans IntelliJ, les diffs du XVème siècle très peu pour moi.

Je suis d'accord, les diff en ligne de commandes sont complètement illisibles.

C'est parce que vous faites des commits trop gros

c'est pas toujours de ta faute, ça m'est arrivé avec three.js ou fritzing, j'ai pas la main sur le code. Et même quand t'as la main sur le code, il faut du temps pour le tronçonner quand t'arrives dans la boite, tu vas avoir une période assez longue où il va falloir gérer des gros fichiers.

Vim ftw.
 

On tourne en rond, c'est précisement à quoi servent  git add -p et git checkout -p. Sauf si vous vous emmerdez à faire des aller retour entre git diff et votre éditeur

 
Cool j'ai été choisi par un algorithme.  

Linus n'a pas conçu l'interface CLI de git , lui il n'a fait que le bas  niveau. Que le bas-niveau n’empêche pas de faire des trucs dangereux ça c'est plutôt normal, parce que de toute façon le bas niveau n'a même pas notion de ces choses là.

"They now want to continue development so this leaves the prototype phase and it goes into 'Product' mode."
fuck, il va vraiment falloir que je mette un pantalon tous les jours je crois
 
Ils ont même de la thune

Justement, je trouve que c'est plus pratique de revoir ses diffs depuis une GUI qui t'ouvre ton éditeur/ide préféré en mode diff que de devoir faire un git add -p en console à la fin. Tu peux coder/revoir ton code depuis un vimdiff d'ailleurs si vim c'est ton truc, pour minimiser les diff c'est assez génial tu devrais aimer

Sourcetree a une interface vraiment pas mal pour les commits partiels de fichiers d'ailleurs, où tu coches/highlightes juste les morceaux que tu veux.

Nano ou autre

Je ne bosse que sur des petits projets mono ou dual dev, pas de quoi fouetter un chat pour le moment, mais la stack est propre avec tout ce qu'il faut pour pas coder de travers.

 
C'est quelque chose qu'on utilise pas nous, mais c'est un bon argument à rapporter chez eux pour modifier ça
 

 
Gros pluzun, et avec ça aucun A/R entre ma console et un autre outil de diff. Le seul besoin c'est en cas de merge compliqué, et pour ça c'est Meld (et ça arrive pas souvent)

chasse à courre = mixité sociale

nanvi' Shinuza  

J'ai jamais aimé les GUI pour git. Je fais tout en console depuis 2008. To each his own    

Please bare my children.

 
Ben je sais pas comment vous faites, mais tant mieux si git add -p vous suffit ma foi perso j'y reviendrai pas

 
Naviguer dans l'historique sans GUI j'ai jamais réussi à faire ça efficacement voir l'historique d'un fichier à travers toutes les branches et faire apparaître les diff entre 2 (ou 3, 4, ...) versions du fichier en les sélectionnant par un click c'est vraiment rapide.

Weird

 
Je ne suis pas sûr que ce mot veut dire ce que tu penses qu'il veut dire