Les outils de gestion de code qui se respectent

[quote=“lordabdul, post:158, topic: 55844”][/quote]

Petit hors sujet: je vois un process Perforce sur ton screenshot. C’est bien? Je suppose que quand tu fais du game t’as pas trop le choix comme SCM pour la gestion des binaires.

P4Force de son petit nom est un derivé de SVN fait pour les binaires. Il lock les files pour gerer le versionning correctement, ca a donc des petits inconvenients.

Ca fait son taf, mais si t’as pas besoin de binaires versionnés, passe sur Git :wink:

(à savoir : tu peux mixer les 2, t’as un partie pour les binaires et une partie fichiers texte géré sous Git)

[quote=« SkullyFM, post:1, topic: 56429 »][/quote]

Oui c’est clair que j’ai pas le choix, c’est ce que ma boite utilise. Comme le dit Donjohn, si t’as pas de binaires, utilise Git/Mercurial/etc, c’est beaucoup mieux a mon avis (et reellement gratuit/open-source… P4 est closed-source, et gratuit seulement si t’as pas beaucoup d’utilisateurs).

Ca marche mieux que la plupart des autres solutions quand t’as un project vraiment tres lourd (un jeu AAA c’est facilement 400Gb de donnees dans ton source control, et evidemment principalement du binaire genre textures/musiques/animations/etc.). Mais ca marche pas quand meme incroyablement bien, surtout quand t’as beaucoup de branches. Ces dernieres annees, P4 a essaye de rajouter des nouvelles fonctionnalites pour etre plus competitif avec Git, genre des branches plus legeres (« streams »), mais de toute evidence sans prendre le temps d’etre sur qu’il y avait pas de bugs… du coup par ici on l’appelle « Perfail », ou « Poorforce », selon les jours :slight_smile:

Bref, si c’est pour du projet perso, je conseillerais plutot Git/Mercurial si y’a pas beaucoup de binaires, et Git + git-annex / Mercurial + largefiles ou meme un bon vieux SVN si t’as beaucoup de binaires.

PS: je deconseille de separer code et data a moins d’avoir du temps a consacrer aux problemes que ca engendre… par exemple quand une update du code necessite une update du format de donnees. C’est le bordel pour garder tout ca synchro. C’est faisable, hein, mais j’ai vu ce que ca demande en investissement pour que ca marche correctement, et c’est pas negligeable, a moins bien sur de bosser encore une fois sur un projet pas trop gros/complique…

gnniii ne pas répondre en embrayant sur les CI et autres tools d’intégrations de code… c’est mon job de mettre ce genre de choses en place, donc faut que je me freine : c’est pas le thread

[quote=« Donjohn, post:2, topic: 56429 »][/quote]

A propos de Git et de fichiers non textuels de base : sais tu s’il existe des plugins ou des libs pour Git permettant de faire des git diff et surtout des git merge de fichiers xml ? C’est-à-dire proprement en tenant compte des balises ?

Pour un projet basé uniquement ou presque sur des fichiers xml, on ne peut pas utiliser de branches car c’est impossible de merger : en cas de fix on recopie le contenu total d’une branche et on met le fix dans la branche et on le reporte par la suite dans master.

Tout le reste des projets ou presque sont des lignes de codes, donc Git convient super bien pour le reste. :slight_smile:

Ce n’est plus les utilitaires méconnus, mais les utilitaires obscurs :smiley:

Nouveau thread créé. Welcome! 

Appelez P4/Perforce P4Force, j’ai bien WTF :stuck_out_tongue:

[quote=« SkullyFM, post:7, topic: 56429 »][/quote]

Merci SkullyFM.  Tu peux te lâcher Donjohn maintenant :slight_smile:

haha j’ai déjà un mail du genre à écrire pour un client :smiley:

Donc mon combo de boulot c’est :
Git + TortoiseGit (oui je suis sous Windows :D)
PHPStorm pour les sources
WinSCP + KittyPutty (un fork à jour niveau sécu de putty)
et pour Apache/PHP/Mailer : j’ai monté une VM locale grâce à Vagrant (c’est de la bombe ce truc)
en debug, j’ai Xdebug à la demande via PHPStorm

Au boulot, j’ai mis en place Git depuis février dernier, car avant… ils avaient rien : sisi je vous le jure… mode transfert de fichiers en clé USB :x
Du coup, ça demande quand même que les gens comprennent le principe du repo local/distant, des branches, et surtout…des merges. Je ne fais que régler des soucis de merge mal branlés : « ouinnnn j’ai perdu des fichiers… ». Ils sont jeunes chez nous, pas forcement hyper formés (un ingé coute cher :wink: et donc sont pas hyper à l’aise avec toutes les notions de versionning, sans compter sur les soit disant connaissances de svn qui ont rien à voir avec git. Mais ils sont débrouillard et motivés donc c’est agréable.
Si vous avez des outils mieux que tortoise, je suis preneur, c’est super utile pour les n00bs mais du coup ça laisse passer plein de conneries aussi. Le mode ligne de commande git demande une trop longue phase d’apprentissage quand vous avez de la prod en mode rush à assurer (je suis dans une boite de comm" où le mode rush est la norme).

Sinon, merger des xml ça existe mais pas en mode « git ». Git n’analyse pas les textes, ils ne fait que remplacer /supprimer des « lignes », d’où les conflit quand il doit traiter 2 fois la même ligne. Hors en XML tu as besoin d’inserer/deplacer/concatener des « nodes ». L’algo de traitement est pas du tout le même.
Par contre, tu peux te coder ton algo et versionner les sorties. Tu exécutes l’algo à chaque push de tes xml. Pour cela tu branches un serveur d’intégration continue au milieu. Son but est de déclencher des scripts lorsque tes repos git ou autres reçoivent un commit.

Les clients graphiques sont une aberration pour moi. Rush ou pas Rush, il faut prendre le temps d’apprendre ca, point.

Au final, une personne qui aura pris le temps d’appendre a s’en servir correctement en ligne de commande (aller, au bout d’une journée, une personnes pas débile sera capable de l’utiliser) lui permettra de : 

  • ne pas perdre du temps quand le truc graphique plante et “houla, j’suis perduuuuu”
  • comprendre ce qu’il se passe vraiment quand on fait un commit/push/rebase/etc…
  • gagner un sacré paquet de temps.

Tu prêches un convaincu. Sauf que j’ai pas le temps de formation et d’accompagnement à ma disposition. Si je l’avais, je te jure que je ferais bcp plus de reviews de code, d’aide sur git/storm etc… mais c’est le temps qui me manque. Du coup je cherche des outils moins ouvert que Tortoise mais facile à apprendre.

N’oubliez pas une chose… Ya une GRANDE difference entre un dev avec 10ans+ d’xp et un jeune de 20ans, avec aucun diplôme, qui sait juste faire du html/css au SMIC pour sortir en chaine les newsletters des clients… Il apprend pas git rapidement, il lui manque des notions pour piger facilement et rapidement ce que fait le --fast-forward par ex (et pourtant il est important ce param…). Et ce sont ces 2 mots clés qui sont mes contraintes actuelles : facile et rapide.

[quote=“lordabdul, post:3, topic: 56429”][/quote]

Je comptais m’en servir en fait pour des projets perso/amateur sous Unreal Engine 4 ou Unity. Comme je ne me vois pas séparer le code des assets dans ce type de projets j’ai l’impression que c’est Perforce obligatoirement. Bref, je galère un peu à trouver un workflow correct.

Ensuite c’est assez compliqué de trouver un outil de Projet Management/Gestion de bugs qui supporte Perforce. J’ai trouvé Jira, Mingle, Hansoft et FigBugz mais j’ai l’impression que c’est un peu de la bidouille.

Sinon effectivement il reste SVN… C’est vraiment efficace pour les assets?
[quote=“Donjohn, post:10, topic: 56429”][/quote]

Sourcetree a la rigueur

[quote=“Donjohn, post:10, topic: 56429”][/quote]

PhpStorm ne gère pas Git ?
De mon côté je fais toutes mes opérations Git via IntelliJ (plus un peu de ligne de commande pour les opérations un peu complexes) et je trouve l’intégration faite par IntelliJ tout à fait correcte.

En effet Git ça ne s’apprend pas en une journée.

[Edit] Et pour la formation à Git, un pote m’a filé ce site. Pas encore lu mais ça a l’air mignon tout plein.

Au boulot on est passé de SVN à Git pour le développement front-end. On a essayé d’utiliser Gitflow et de lier ça à Jira comme les vrais. Ben après un mois c’est devenu un bordel pas possible avec des branches dans tous les sens et plus vraiment moyen de savoir quelle était la dernière version. Ca a apporté plus de problèmes que de solutions. Du coup depuis on bosse tous comme des porcs dans la branche master. Je trouve Git vraiment trop confu et pas explicite quand on n’a besoin que d’un versionning de base.

Enfin, sinon, c’est quoi ce thread. Ya pas vraiment debat.

Tu geres et t’as pas de binaire, Git comme un vrai.
Tu geres et t’as des binaires, P4 comme un con.
Tu geres pas et t’as pas de binaires, SmartGit ou SourceTree
Tu geres pas et t’as des binaires, P4. (Ou SVN si en plus t’es pauvre)

Apres, si t’aimes l’aventure, Hg c’est cool aussi. Et ca match a peu pres toute les cases.

Pour être simple et efficace :
2 branches : master et dev
sur master : interdiction de commit (ca se config avec les droits des users entre autre), merge/push/tag only.
tu dev tout sur la branche dev en créant des branches dev-bidule1, dev-bidule2 à chaque développement. Quand t’as finit, tu la merge avec dev. Tu testes dev avec toute les branches mergés (un serveur genre Jenkins doit s’en occuper). Quand t’es content de dev, testé, recetté etc… tu merge dev avec master et tu deploies master et tu tag versionX. Faut aussi apprendre aux gens à ne pas pousser toutes les branches… ça évite de polluer le repo central.
Du coup dans ton Reflog t’as une branche master clean et tagguée à chaque livraison. C’est l’orga la plus « simple » qu’on ait trouvé et qui permet de garder des repo assez clean.

Je vous entends parler d’assets. Ne pas les confondre avec du code compilé. L’interet de Perfoce est de versionner des changements fréquents (à chaque push ;)) de binaries. Sinon aucun intérêt.
Si vous avez des binaires dans git, c’est pas grave, c’est même normal assez souvent. Par contre, si vous les modifiez souvent, le seul inconvénient à rester sous git est la place pris par le repo sur le HDD… L’interet de Perforce est de ne pas stocker l’intégralité du binaire à chaque version. Ce que fait git par contre vu qu’il ne sait pas les traiter. Donc tout depend de la frequence à laquelle vous allez changer ces binaires. Si ce sont juste des assets… git suffit largement.

Edit : Ana-l> ya pas débat, mais ont peut ptet expliquer pk :wink:
sinon je connaissais pas SmartGit… thx, je regarde ça

L’autre interet de passer à git c’est la gestion des « vendors ». Vu que toutes les libs front-end/back-end en web sont stockées sur Github, c’est complétement idiot d’avoir 2 système locaux pour gérer tes sources, git pour les vendors et svn/mercurial pour ton code; ca n’a pas de sens. Tu passes dont tout en git

(ensuite tu install même ton propre packagist pour héberger tes propres vendors et tu commences à bien kiffer ton taf mais c’est une autre histoire :P)

Webstorm ici, Git avec une branche master, une branche develop et rulez. Et on pète les genoux de ceux qui pètent les branches, aussi.

Pour avoir travaillé avec des tas d’outils de gestion de sources le meilleur et de loin c’est Git. Mais il est aussi trop complexe pour des équipes peu averties ou pas assez rigoureuses et on peut vite faire beaucoup de conneries, et la courbe d’apprentissage est assez raide. Sans revenir à Subversion (ou pire, CVS) avec tous leurs défauts, je conseille par conséquent quasiment toujours de mettre en place Mercurial comme SCM. C’est un outil connu, même s’il n’a pas fait autant de buzz que Git, plus simple, tout en gardant l’avantage énorme d’être décentralisée.

https://mercurial.selenic.com/

Sinon pour gérer les dépôts de sources j’ai mis pas mal de temps à trouver un truc bien. Venu de l’univers Java j’ai trouvé SCM-Manager qui tourne aisément sur un TomCat et fait très bien le boulot, en particulier sur le plan de la sécurité une fois qu’il est connecté à un LDAP/Active Directory.

https://www.scm-manager.org/

[quote=“SkullyFM, post:13, topic: 56429”][/quote]

Je plussoie mille fois SourceTree comme bien meilleure que TortoiseGit.