12Fermer14
Kevin KoflerLe 06/12/2012 à 00:37
Lionel Debroux (./11) :
Pour Git: très vite, je n'ai plus pu me passer du rebase et de la réécriture des commits. C'est grâce à ça que dans un précédent emploi, j'ai pu faire une série bisectable (tout compile et tous les tests passent, à chaque patch de la série) de plus de 20 patches, portant des features d'un fork d'une ancienne version du trunk (plus de 400 commits SVN en tout), vers une nouvelle version du trunk (qui avait eu de gros changements architecturaux par rapport à l'ancienne version) et qui continuait à évoluer pendant que je travaillais.

Dans TIGCC, j'ai fait ce genre de travail à plusieurs reprises avec rien de plus que patch et diff (et le CVS ne contient que le patch résultant).
Dans mon emploi actuel, un de mes collègues et moi utilisons quasi-quotidiennement la réécriture des commits (distants, même si c'est déconseillé) pour synchroniser des versions de test entre machines. Ensuite, quand on a fait et testé plusieurs commits (y compris parfois des one-liners pour corriger des bugs idiots, du genre vérification de pointeur != nullptr - on code en effet en C++11), on pousse une version nettoyée vers le trunk SVN.

Je ne vois pas le problème d'avouer qu'on a fait une erreur et de pousser un commit qui la corrige.
Godzil (./12) :
gitk est bien, mais par contre il y a pas mal d'outils equivalent qui existe en natif pour chaque OS

qgit = gitk en plus moderne. smile

Sinon, il y a git-cola qui est très pratique pour servir d'UI complet.