Choix d'un soft de suivi de versions de sources - Page 3

Tortoisegit FTW

la cli de git n'est qu'un col dans la courbe d'aprentissage. il y a des machins beaucoup plus complexes que l'interface dans cet outil, et que ce soit en cli ou gui on s'y perd quand même.

je préfère nettement ca a tout machin git graphique qui demande des dizaines de clics pour faire la même chose qu'un one liner. c'est beaucoup plus rapide en pratique. comme vim, en somme.

Je refuse aussi d'utiliser vim. Je ne sais pas faire grand chose avec à part :q!.

ben tiens je viens de tomber sur ca:

https://people.gnome.org/~newren/eg/presentations/git-introduction.pdf
https://people.gnome.org/~newren/eg/

Plus aucune excuse!

Et ca aussi: https://git-scm.com/book/fr/v2

Zerosquare (./56) :
Et il y a aussi des développeurs qui préfèrent utiliser une GUI que taper des commandes

Je n'ai jamais dit que les développeurs ne devaient utiliser que la CLI, ça serait complètement idiot… au moins autant que de dire qu'une bonne interface est forcément en GUI ^^

5 ans plus tard, j'ai fini par me mettre à Git (mieux vaux tard que jamais )

J'ai voulu installer SourceTree, qui avait l'air sympa et qui m'avait été recommandé. Résultat : impossible d'aller au-delà de l'étape où il demande le nom et l'adresse e-mail à utiliser pour les commits, ça marque soit que l'adresse e-mail est invalide, soit ça réaffiche simplement la même boîte de dialogue. Le problème est connu et a été signalé dans le tracker de bugs, mais il n'y a aucune solution, et aucun des différents workarounds mentionnés ne fonctionne.

J'ai essayé GitEye : le soft plante immédiatement avec un message d'erreur Java (youpi !)

Là je teste Git Extensions, pour l'instant (je touche du bois) ça a l'air de fonctionner.

Et vous, vous utilisez quoi ?

TorgoiseGit pour la fonction "log" et la résolution de conflits, la ligne de commande pour tout le reste

Zerosquare (./68) :
J'ai voulu installer SourceTree, qui avait l'air sympa et qui m'avait été recommandé. Résultat : impossible d'aller au-delà de l'étape où il demande le nom et l'adresse e-mail à utiliser pour les commits

Curieux, on me l'avait recommandé aussi et le peu que j'ai pu tester ça avait l'air de fonctionner — je n'avais même pas essayé de m'enregistrer apparemment vu qu'il me le demande aujourd'hui, mais bon

Ligne de commande et gitk/git gui (pour un peu de graphique) et Gogs* cote serveur


* https://gogs.io/

Tiens c'est marrant que vous utilisiez la ligne de commande. C'est par goût personnel, ou parce que les features que vous utilisez ne sont pas dans les GUI ?

Je trouve qu'elle est assez efficace. Ça manque cruellement de logique au premier abord (coucou "git checkout") mais ensuite je trouve que c'est vraiment plus rapide que passer par une GUI pour la majorité des commandes standard (quand aux opérations un peu plus complexes c'est souvent l'enfer dans les GUI, voire simplement impossible car pas implémenté). C'est d'autant plus vrai que Git permet facilement de définir ses propres alias pour les commandes (ou combinaisons de commandes) que tu utilises fréquemment ; pour ma part toutes celles dont j'ai besoin régulièrement font une ou deux lettres, c'est difficile à battre avec une GUI.

Ça risque d'être un peu abscons si tu découvres Git mais pour info voilà ma liste d'alias :
[alias] amend = commit --amend --no-edit --reset-author b = branch ba = branch -a bd = branch -D c = checkout d = diff ds = diff --shortstat f = fetch --all i = commit ia = commit -a l = log --graph --pretty=tformat:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%an %cr)%Creset' --abbrev-commit --date=relative m = merge mf = merge --ff-only p = pull pf = pull --ff-only pr = pull --rebase r = rebase ra = rebase --abort ri = rebase -i rc = rebase --continue s = status u = submodule uu = submodule update --init y = cherry-pick yn = cherry-pick --no-commit z = reset zf = "!f() { upstream=\\"${1:-$(git rev-parse --abbrev-ref '@{u}' 2> /dev/null)}\\"; if [ -n \\"$upstream\\" ]; then git fetch \\"$(echo \\"$upstream\\" | cut -d / -f 1)\\" && git reset --hard \\"$upstream\\"; else echo >&2 \\"error: can't find upstream branch\\"; fi }; f" zh = reset --hard

Zerosquare (./68) :
Et vous, vous utilisez quoi ?

Git Cola et QGit.

(Pauvre Zerosquare, tout le monde utilise un truc différent )

yNgit est pas mal non plus !

Je me force un peu à utiliser Jetbrains (enfin, leurs IDE) pour quasiment tout, sauf git fetch/git push au boulot (j'ai eu la flemme de regarder comment utiliser une carte à puce ou ssh-agent) que je fais en CLI.
Jusqu'à présent, apprendre à utiliser ces produits a toujours été un investissement rentable, du coup je continue Leur interface pour les merge est vraiment pas mal également.

Merci pour les suggestions

Pen^2 (./75) :
(Pauvre Zerosquare, tout le monde utilise un truc différent )

Oh ben en posant une question comme ça à des geeks, je savais un peu à quoi m'attendre

Après, je n'ai pas forcément la même utilisation que vous de Git : sur les projets sur lesquels je travaille, je suis en général le seul à commiter (c'est pour ça que j'ai pu temporiser à ce point ^^), et je ne fais pas de trucs compliqués dans ma gestion des sources.

Oué moi c'est un peu pareil, en plus je ne reviens jamais sur mes devs vu qu'ils sont parfaits au premier coup

;D

Je te conseille d'essayer Git Cola alors, c'est libre, gratuit et multiplateforme, et ça suffit largement pour l'usage simple. (Pour les trucs pas évidents, il m'arrive de devoir RTFM et recourir à la ligne de commande, mais ce sont des trucs vraiment tordus qu'il m'arrive de faire avec Git. )

Quant au deuxième outil que j'utilise, QGit, c'est un visualiseur d'historique, et il permet aussi de facilement configurer des commandes custom, ce que j'utilise pour les commandes fedpkg.

Sinon, à vrai dire, j'utilise aussi un troisième outil de temps en temps, TeamGit, mais la seule fonctionnalité que j'utilise est le revert. Faudrait vraiment que j'envoie des patches à Git Cola et/ou QGit pour rajouter ça, c'est une commande git revert toute bête (avec un GIT_EDITOR raisonnable (kwrite) de configuré, TeamGit ne fait même pas ça automatiquement d'ailleurs, c'est sûr que lancer vi sans même un terminal ne va pas marcher…).

D'après les quelques tests que j'ai fait aujourd'hui, Git Extensions semble me convenir : l'interface est facile à utiliser, et l'installateur (au moins dans la version Windows) inclut tout ce qu'il faut. C'est un soft libre aussi, et ça utilise même KDiff3 pour les diffs/merges (mais ce n'est pas Kevin-compatible pour autant : la version Linux utilise Mono ).

pour git ligne de commande uniquement, ca fait tout de maniere efficace et c'est dispo partout, même sur une machine ou tu n'as qu'un acces SSH

(Et il est claire qu’il y aura un moment où un autre ou tu devras utiliser la CLI, donc ne pas trop se reposer sur une IHM est recommandé pour git.

A vrai dire la CLI est loin d’etre complexe.

Kevin: c’est quoi pour toi exactement « git revert »? Annuler un commit? Faire un reset de fichiers modifiés?

Il parle de la commande git revert j'imagine ? (donc ni l'un ni l'autre mais plutôt créer un commit qui annule les changements apportés par un autre)

squalyl (./83) :
pour git ligne de commande uniquement, ca fait tout de maniere efficace et c'est dispo partout, même sur une machine ou tu n'as qu'un acces SSH

Oui mais bon, c'est le genre d'arguments de ceux qui utilisent vim : très peu pour moi

je dis pas ca pour te convaincre, mais t'as demandé des témoignages, alors te plains pas.

Je me plains pas, je plaisante hein

J'ai une utilisation très basique de Git, donc Tortoise Git sous Windows, et Gitk/Gitgui sous Linux.
J'utilise toujours github comme repo master, et il permet facilement de voir les commits qu'on a fait, et de récupérer un soft à un commit donné.

J'utilise également une combinaison ligne de commande / git gui / gitk, selon ce qui est le plus efficace et/ou le plus clair. gitk est bien pour visualiser et un peu manipuler l'historique, git gui est bien pour éditer les messages de commit, et le reste se fait bien en ligne de commande. Même en remote - X11 forwarding avec SSH à travers Internet public - git gui et gitk sont rapides.