out through the winter throat

out through the winter throat le blog de Anahkiasen.

Le Version control

“If you’re not on Github, you’re essentially unable to participate in the rich open-source community that has arisen around front-end development technologies.”

Quand je dis que ma manière de travailler a changé je ne parle pas seulement du résultat final de mon travail mais du processus en lui-même, le workflow. En quelques mots c’est tout ce qui, de l’idée originelle, conduit au résultat final — les étapes suivies, les logiciels et langages utilisés, les pratiques mises en œuvre… bref vous saisissez l’idée. Chacun a sa méthode, chacun a rodé ses étapes, et il est toujours utile de lire et d’étudier la manière dont les autres travaillent.
Beaucoup de choses ont changées depuis que je me suis mis au webdesign, j’ai beaucoup fait évoluer ma méthode personnelle, mais s’il y a une chose que je tiens à mettre en avant en particulier aujourd’hui c’est l’importance du versioning et de sites comme Github.

Le version control en gros c’est l’acte de scinder son travail en versions (et oui). Le terme est assez large, il peut aller du simple fait de créer des versions de son projet (v1, v2) au fait de marquer chaque changement au code comme un point d’encrage en tant que tel, via des technologies comme svn ou git. Je ne vais pas (trop) m’étendre sur ces deux technologies parce qu’il y aurait trop à dire, mais comme le site de Git a il y a peu fait peau neuve je me permets de vous glisser un lien.
Cette article est plus sur le principe du versioning que sur les fondamentaux techniques. Si vraiment vous ne voyez pas de quoi je parle, et ne voyez pas de raisons de lire cette article, faites-le quand même. Le versioning s’applique tant à la programmation qu’au travail graphique – garder un historique de ses images et de son travail en général est un atout énorme, et même si je parlerai principalement de mon cas et de code ici, il y a de grandes chances que cela s’applique à vous aussi.

Dans la poignée de webdesigners que je suis de près, j’étais à une époque tombé sur un article de Rebecca Murphey qui disait « If you’re not on Github, you’re essentially unable to participate in the rich open-source community that has arisen around front-end development technologies. » (Si vous n’êtes pas sur Github, vous êtes fondamentalement incapable de participer à cette riche communauté open-source qui s’est formée autour des technologies du développement front-end [1]). C’est une phrase qui m’a beaucoup marqué, surtout parce qu’à l’époque je ne la comprenais absolument pas.

[1] Rebecca fait ici référence à des technologies comme le HTML5, le CSS3, Javascript, Ruby, PHP, et j’en passe. Le front-end se définit comme tout ce qui se trouve entre l’utilisateur et le back-end (le code moteur), l’interface en quelque sorte.

Historique

Pendant longtemps j’ai laissé ça de côté - parce que je ne voyais pas trop à quoi il était fait allusion, et parce qu’avouons-le, pour qui n’y a jamais touché Git et SVN sont des mondes qui donnent mal à la tête. Faits de branches, de commits, de pull request, de merge et de revisions, et j’en passe. Chaque technologie y va de son petit terme à elle, parfois même pour parler de choses identiques, et quand arrive l’heure de se lancer on peut mettre un long moment avant de saisir réellement ce dont il s’agit.

Dans mon cas j’ai décidé de m’y frotter quand ma petite ébauche de framework a commencé à faire ses preuves, et qu’il devînt de plus en plus complexe de gérer différentes itérations du moteur sur plusieurs projets. De répercuter les bugfixes et améliorations, de savoir où chaque projet en était et ce qui avait changé depuis la dernière fois. Du coup à l’époque je me suis lancé dans SVN, un peu arbitrairement – j’ai placé mon moteur sur un hébergement SVN en ligne (à savoir Beanstalk) pour me faciliter la tâche. Et après quelques coups d’essais j’arrivais à gérer plusieurs versions du moteur sur plusieurs projets — déployer des modifications sur chacun sans me prendre la tête, gérer facilement conflits et historiques, etc.

J’ai toujours considéré que quand on apprend une technologie nouvelle il n’y a de meilleur maître que la pratique. Sans se lancer complètement à l’aveugle non plus, le fait de tenter de mettre en œuvre ses connaissances dans un petit projet, parfois même au fur et à mesure de l’apprentissage, aide beaucoup à comprendre l’ensemble. Ça m’avait aidé à l’époque du HTML, puis du PHP, et ainsi de suite jusqu’à aujourd’hui.
Pour moi, Cerberus - le nom de mon framework - était ma manière de tâter le terrain de manière concrète. Séparer mes modifications en versions et ainsi savoir où en était tel ou tel projet. J’avoue bien sûr que, travaillant seul, il m’est bien plus simple d’expérimenter avec les technologies du web que pour beaucoup de gens.

À mesure que je me familiarisais et rattrapais mon retard avec la scène du webdesign, que j’employais et suivais de nouveaux projets et technologies, j’ai appris à connaître GitHub. Pour ceux qui ne connaissent pas, c’est un site basé sur le principe des repositories : des sortes de “répertoires” symbolisant des projets. Tout s’articule autour des interactions possibles entre eux : les gérer, les héberger, discuter autour d’eux; laisser les utilisateurs disséquer, réparer voire améliorer votre code.
C’est la base de l’open-source : votre code est à la vue de tous, les utilisateurs peuvent venir commenter ou interagir sur chaque ligne. C’est un concept qui peut paraître terrifiant à première vue mais qui révèle bien vite plus de points positifs que négatifs.

Le version control pour tout, partout, tout le temps

Vous l’aurez compris, le principe est de créer une sorte de ligne de temps de votre code. Où chaque modification est distincte des autres, ce qui ouvre tout un monde de possibilités, la plus utile étant sans conteste celle de ramener à tout moment votre code à un instant T. Qui n’a jamais fait une grosse modification sur son code pour ensuite se rendre compte même après tests qu’elle cassait quelque chose d’inattendu ?

De là une fois qu’on y a goûté il est difficile de faire marche arrière, et bien vite je me suis retrouvé à héberger, non plus simplement le code moteur de mes sites sur Github, mais mes projets eux-mêmes.
Ça me donne entre autres une facilité de transport. En ce sens où l’état des fichiers sur le disque n’importe désormais plus - finies les galères avec Dropbox de conflits de fichiers, d’erreurs de copie, et j’en passe. Les commits (modifications faites au projet) sont enregistrés en ligne et je peux décider de télécharger de n’importe où n’importe quelle version de mon projet, de sa naissance à la fin. C’est un outil miraculeux, surtout lorsque l’on travaille à plusieurs ou sur plusieurs postes : chacun peut améliorer un code dans son coin, tout en ayant toujours la dernière version sur son poste. Et si conflit il y a, les fonctionnalités de merge (fusion) de git et svn sont assez malignes pour gérer tout ça. Imaginons par exemple que deux personnes travaillent sur un même fichier et envoient leurs changements en même temps, pour peu que ces changements soient à des endroits distincts du fichier, tout sera habilement combiné en arrière-plan.

On en devient vite accro, de la technologie elle-même certes mais de la communauté autour aussi. Pour tout vous dire, même cet article a été écrit en Markdown (un langage de formatage) sur Gist, la plateforme d’échange de bouts de texte et de code de Github, qui permet elle aussi de créer une instance du fichier à chaque modification, de discuter autour. Bref de faire tout ce qu’on peut en temps normal.

Être au plus près du travail des autres

L’autre point fort comme je l’ai dit c’est la facilité d’interaction et la proximité des développeurs. Quand je repense à il y a quelques années, je pense que jamais je ne me serais imaginé participer de si près au développement des projets qui me sont chers. Lointain est désormais le monde des boîtes à suggestions où on envoyait des emails désespérés en priant pour être pris en compte. La plupart des gros projets sont désormais sur Github. Même PHP - le langage lui-même - est depuis peu passé au Git.
Désormais quand il manque quelque chose dans un projet que j’aime, je ne reste plus les bras croisés - je fork le projet (fait de créer une version séparée), fais mes modifications, et fais un simple pull request pour que mes modifications soient ajoutées automatiquement au projet si le développeur les trouve à son goût. Tout ça parfois en quelques heures – jamais les choses n’avaient été aussi vite.

A contrario quand désormais je tombe sur des projets intéressants qui n’utilisent aucun système public de version control, je ressens toujours une certaine impuissance. Trouvé un bug dans le code ? Envoyez un email et attendez. Envie de suggérer une amélioration ? Passez par les (parfois inexistants) forums et croisez les doigts pour que quelqu’un les lise.
De manière moindre ça me fait aussi un peu ça quand je tombe sur des ancêtres (Sourceforce) ou concurrents (Google Code, qui utilise SVN) de Github.

Oser faire le premier pas

Si vous n’avez jamais touché ni à Github ni à Google Code, essayez. Tout le monde a au moins un projet qui gagnerait à utiliser ces technologies. Et rappelez vous que dans version control il y a control.
De nos jours les pages de démarrage de Github se sont faites moins effrayantes, vous serez guidé pas par pas et tout devrait bien se passer.
Si git et svn restent des technologies qui favorisent la ligne de commande, sachez par ailleurs que de nombreuses interfaces existent, de Mac à Linux. Une bonne poignée est répertoriée sur la page GUI du site git, à l’exception de Github for Windows qui vient d’être lancé.

Si vous êtes un débutant, Github for Mac et Github for Windows (dans un très léché style Metro) sauront se prouver intuitives et vous accompagner dans vos premiers pas.
Si vous êtes plus expérimenté et avez besoin d’accéder à des fonctions plus poussées, Smartgit sur Windows et SourceTree (gratuit) ou Tower (payant) sur Mac seront là pour vous. Au niveau du svn je n’ai testé que Versions sur Mac mais en ai été très satistait.

Ces logiciels répondent tous à une peur de la ligne de commande qui éloigne beaucoup de gens de ces technologies, et c’est une perte grave car se couper d’une communauté aussi passionnée, rassemblée autour de l’open-source et des possibilités offertes, c’est effectivement se priver d’énormément de choses.

Conclusion

Quelques mois plus tard je comprends enfin la phrase de Rebecca et s’il n’y a qu’une chose que je puisse dire c’est que je ne pourrais être plus d’accord.
Les simples technologies citées dans l’article précédent : LESS, SASS, Compass, CoffeeScript, ou d’autres comme jQuery, Ruby on Rails — toutes sont sur Github, ouvertes à discussion, à amélioration.
J’ai récemment vu le développeur d’un plugin pour Compass me laisser les clés du projet car je le développais plus activement que lui.

Le web et les technologies qui l’entourent n’ont jamais avancé aussi vite. Là où avant le HTML et le CSS par exemple étaient des technologies fixes mises à jour toutes les X années, sont désormais devenus des langages mouvants. Des standards en constante évolution par la communauté (ça sera le sujet d’un prochain article).
Si vous voulez commencer à garder le rythme, mon meilleur conseil est de suivre ce qui vous passionne au plus près, à la source. Mon meilleur conseil, c’est de commencer par .

Note

Mon prochain article se portera sur le Responsive Design. De ses premières ébauches à la (re)découverte des Media Queries, jusqu’à son actuelle forme où les designs adaptatifs ont dans la plupart des cas supplantés les versions mobiles et consorts.

Je discute aussi beaucoup avec des développeurs étrangers et dans l’optique de mieux m’ouvrir à tous j’ouvrirai bientôt un blog compagnon à celui-ci où des versions anglaises de mes articles sur le webdesign seront postées. Ne vous étonnez-donc pas si je lie alors chaque article vers un blog externe, celui-ci reste mon blog principal.

Tags: , , , , ,

35 commentaires pour “Le Version control”

  1. divide dit :

    Ton article tombe à pic, j’ai passé 2 ans sur mon projet à faire du “versionning” à coup de .zip, mais j’envisage sérieusement de passer à un vrai versionning Git. Du coup j’en profite pour poser quelques questions:
    1. C’est possible de faire du Git uniquement en local, sans un framework Git envahissant, et de copier-coller facilement cette base de donnée sur un autre ordi si je change de config ?
    2. Mon IDE (Qt Creator) intègre une gestion Git. J’ai quand meme besoin d’un serveur Git en parallèle ?
    3. C’est possible de faire du Git sur mon ftp OVH privé ? Si non, il y a des services gratuit et privés qui proposent ce genre de service ?

    Merci !

  2. skaven dit :

    git par SSH si tu as déjà un hébergeur.
    sinon, des boites comme github, codehq,.. te fournissent un serveur git + outils dédiés à pas très cher.
    Tu peux faire ton git local et pusher vers le master de temps en temps.

  3. epsylon dit :

    http://sixrevisions.com/resources/git-tutorials-beginners/

    De mon expérience, Pro Git est très bien, le git community book est très bien et git magic est très bien aussi.

  4. ng-aniki dit :

    Si vous bossez avec d’enormes fichiers binaires (Pas du code quoi), je vous conseille de vous tourner plutôt vers SVN qui possède une fonction pour lock les fichiers. Histoire que d’autres ne travaillent pas dessus en même temps que vous. (Sinon bonjour les heures a bosser pour rien)

    Je n’ai jamais compris pourquoi cette fonction n’est pas disponible sur git d’ailleurs.

  5. firekorn dit :

    Alors ce que tu dit c’est cool mais personnellement j’aimerai avoir un outil de versionning en locale pour mes projets sans avoir à les publier à travers le monde entier et sans avoir à payer car pour des petits projets (qui ne sont pas forcément de la prog sa peut être des doc word) qui n’aboutiront pas forcément pour certain sa me gêne de mettre de l’argent.

    Donc actuellement j’adorerais avoir un outil me permettant un gestion et une organisation simple de mes versions de fichier mais je n’en ai trouver aucun et partir sur des système online sa ne m’intéresse pas particulièrement.

  6. ecaheti dit :

    Quand je suis arrivé à mon taf pour faire du dev en C, je remplaçais un presta qui m’a installé sur mon PC un serveur SVN + TortoiseSVN. Il m’a dit “tu va voir ça gère la fougère”.
    J’ai commencé à l’utiliser seul, surtout comme base d’archivage de mon boulot, en faisant un commit de “temps en temps”. Aujourd’hui il m’arrive de faire plusieurs commit par jour, je gère plutôt pas trop mal les histoires de branche, et surtout j’ai un collègue qui est arrivé après moi pour taffer sur le même projet, et SVN nous a rendu de sacré service.
    Un autre soft pour le projet était développer par des collègues au Canada, qui, ne pouvant accéder à mon serveur sur mon PC, on créé un compte privé sur Github.
    Si notre système de gestion de conf est un peu disparate (en rajoutant ceux qui utilisent encore les zip), il est devenu indispensable.
    (et pour ceux qui pense que je suis un inconscient d’avoir mon serveur directement sur mon PC, ma base est zippée / sauvegardée sur les serveurs de données de la boite tout les jours par une routine auto).

    Aujourd’hui quand je me lance dans un dev perso, je le fous sur Github parce que c’est pas trop compliqué, que mes sources sont dispo que je sois au taf ou chez moi, et TortoiseGIT permet de faire le taf de base. Cependant je testerai Git for Windows incessamment sous peu.

  7. Dyblast dit :

    firekorn a dit :
    Alors ce que tu dit c’est cool mais personnellement j’aimerai avoir un outil de versionning en locale pour mes projets sans avoir à les publier à travers le monde entier et sans avoir à payer car pour des petits projets

    Utilise git. C’est décentralisé, tu peux faire tes commits localement sans jamais les envoyer vers un serveur. Tu peux faire un gros zip de ton git et le déployer sur une autre machine sans trop de problème.

  8. Anahkiasen dit :

    Je n’ai peut être pas assez souligné la distinction il est vrai, je tenterai d’éditer l’article dès que j’ai un peu de temps. Git et svn sont des technologies de version control, elles ne sous-entendent aucun environnement particulier et peuvent être utilisés en local. Github est un site proposant d’héberger un serveur déjà tout prêt pour communiquer avec git, en plus d’héberger les fichiers. Et non, Github n’est pas payant et même si les fichiers sont en ligne c’est tout à fait compatible avec un environnement local.

  9. firekorn dit :

    Alors peut être fais essayer mais d’après ce que j’avais vu sur leur site j’ai eu du mal a trouvé cette possibilité (et il est vrai que je ne suis pas fan des lignes de commande qui me rebute assez facilement)

    N’étant pas un programmateur, j’adorerai un système tout prêt avec une installe en mode “suivant” 5 fois et sa fonctionne mais j’avoue que pour avoir déjà utiliser ce genre d’outil c’est sacrément pratique peur importe ce sur quoi on bosse!

    Edit : Après avoir regarder un peu plus en profondeur leur site en effet l’ensemble à l’air assez instinctif mais malgré les quelque fois ou je suis tombé sur git je n’ai jamais vue cette possibilité (manque de recherche de ma part ou manque de lisibilité de leur côté?? surement les deux)

    Donc en cours d’installation!! Et leur tutoriel pour windows est très clair dommage que l’on ne puissent pas le voir sans avoir créer un compte au préalable.

  10. Anahkiasen dit :

    Tu trouveras l’inscription gratuit en suivant le gros bouton sur la page d’accueil puis Free Account : https://github.com/plans
    Quand à une installation facile suit le lien vers Github for Mac/Windows dans l’article, tous deux de très bons logiciels très simples à prendre en main.
    Avec ces logiciels tu n’auras jamais à toucher à la ligne de commande, promis.

  11. Mousse dit :

    Et Anahkiasen découvrit Git !

    J’espere que tu profite bien des branch, tags et autres features qui font de git un des meilleurs CVS existant ;)

  12. Anahkiasen dit :

    Oui bah toi balance un Twitter/Facebook/whatever ou autre moyen de communiquer. Sans déconner t’as traîné avec nous pendant des années, puis t’as disparu de la grille et du coup maintenant que j’ai besoin de toi et qu’on a des trucs à se dire t’es introuvable mécréant :D

  13. Def dit :

    Il y en a d’entres vous qui utilisent TFS ? Vous en pensez quoi ?

    J’ai changé de job il y a 2 ans et je suis passé de svn à tfs et j’ai l’impression d’avoir fait un bond de 10 ans en arrière.

  14. ecaheti dit :

    firekorn a dit :
    N’étant pas un programmateur

    Je ne vois absolument pas ce que la “Personne en charge de la programmation” d’une radio vient faire dans l’histoire…

    Pour en revenir au sujet, j’utilise Git et Svn sans jamais taper une ligne de commande, les différents outils sont suffisamment complet pour éviter ça.

  15. MyKiwi dit :

    firekorn a dit :
    Alors ce que tu dit c’est cool mais personnellement j’aimerai avoir un outil de versionning en locale pour mes projets sans avoir à les publier à travers le monde entier…

    Avec le client Github for windows, tu peux créer un repository (et tu as une option pour le mettre sur GitHub.com, ou non).

  16. Gama dit :

    Git c’est effectivement très, très bien pour des geekeries et c’est vraiment adapté à l’open source.

    Par contre, dès qu’il commence à y avoir des assets à gérer , et donc que les utilisateurs ne sont pas uniquement des programmeurs barbus, le Graal absolu, c’est Perforce. C’est pas open source mais gratuit pour moins de 20 utilisateurs et c’est un bonheur de bosser avec ça.

    En tout cas même si je tique un peu sur la forme de l’article je suis bien d’accord avec le fond : Je comprends même pas comment on peut encore bosser sans ce genre d’outil.
    D’ailleurs, divide, je suis vraiment surpris que t’aies achevé ton projet sans versioning…Ça doit rendre les expérimentations très lourdes à mettre en place.

  17. MrHelmut dit :

    Def a dit :
    Il y en a d’entres vous qui utilisent TFS ? Vous en pensez quoi ?
    J’ai changé de job il y a 2 ans et je suis passé de svn à tfs et j’ai l’impression d’avoir fait un bond de 10 ans en arrière.

    Perso, je placerais TFS au même niveau que SVN. J’ai tendance à préférer TFS, étant un aficionados de Visual Studio. TFS permet aussi de faire des commits juste pour soi, pour mettre de côté une working copy (le shelving).
    Après, TFS a surtout des features pour la gestion de projet, mais d’un point de vu développement / versionning, c’est kif kif avec SVN.
    Inconvéniant de TFS : payant et nécessite une configuration full windows / IIS.
    SVN, c’est le minimum syndical, et Git, c’est la rolls.

    On me parle aussi souvent de mercurial, mais je n’y ai jamais jeté un oeil.

  18. Mousse dit :

    Ah non, tu fais chier bordel ! Je sur steam tout les soirs en ce moment !

    Sinon, @capitainemousse sur twaitteur !

  19. Regnareb dit :

    Gama > J’avais lu un (ton ?) article sur perforce et m’avait beaucoup encouragé, mais impossible de l’installer… je n’ai trouvé aucune ressources simple et clair pour le faire même pas de doc. J’ai finit par abandonner malgré les avantages que ça apportait, surtout en tant que non programmeur.
    Au final je traîne toujours sur mon Dropbox.

  20. Anahkiasen dit :

    Mousse a dit :
    Ah non, tu fais chier bordel ! Je sur steam tout les soirs en ce moment !
    Sinon, @capitainemousse sur twaitteur !

    Oui mais Steam c’est moi qui y suis plus maintenant :-°

  21. Mousse dit :

    C’est bien ce que je dis: tu fais chier bordel !

    Je t’ai envoyé un mail à ta vieille adresse contact, je sais pas si elle est encore valable …

  22. channie dit :

    (Gama a raison)

  23. SPhoenix dit :

    Sinon, y’a DropBox.

    :D

  24. Anahkiasen dit :

    À plus petite échelle je confirme que Dropbox - maintenant qu’il permet de garder un historique d’un fichier pendant 30 jours, même après sa suppression - peut grandement servir. Bon après ça reste à vraiment plus petite échelle, et à part l’historique tu fais pas grand chose d’autre.

  25. Mousse dit :

    Dropbox pour les projets, c’est pas vraiment pratique :

    - Pas de gestion des commits
    - Versionning moyen (ça bug sur certain type de fichier ou des “version” disparaissent)
    - C’est plus cher que de mettre un place un VKS avec un SVN/GIT/Whatever (SVN + USVN = 30 min pour tout faire fonctionner sans problème)
    - Connection impossible avec un bugtracker ou d’autres service (Maven par exemple)
    - …

    Je ne crache pas sur le service, je l’utilise (tout les éléments que j’ai besoin sur mes ordis/tablettes sont dessus) mais ce n’est vraiment pas fait pour les projets pro.

    Pour revenir sur TFS, je l’ai utilisé pendant 1 ans et j’en étais plutôt content, je le trouve même plus flexible que SVN (Y’a un bugtacker de base quoi o/).
    Mais git restera incontestablement le meilleur pour moi.

    Ah, et pour les assets sur Perforce : Git Submodule ;)

  26. Regnareb dit :

    Sur quels fichiers Dropbox bug-t-il ? Ça me parait impossible, du moment que le fichier change, Dropbox l’upload. A moins que l’upload ne se soit pas fait entre deux version, ce qui est normal vu le fonctionnement du soft, je pense que c’est tout simplement ce qui a du t’arriver.

    Tu peux développer pour Git Submodule ? C’est un truc a utiliser sur Git pour bien gérer les assets ? Ou bien à utiliser avec Perforce ?

  27. Anahkiasen dit :

    Git Submodule ça permet en gros, quand tu utilises un autre projet git dans ton projet, plutôt que de copier les fichiers et d’avoir à les mettre à jour à chaque fois, de simplement faire un “lien”. Ce lien représente l’autre projet, tu peux régler pour qu’il soit toujours à la dernière version ou lier une version précise de ce projet. C’est super, super, super utile.

  28. Mousse dit :

    Regnareb: avec certain type de binaire mac, j’ai eu des soucis de “perte” de version. Ça à été corrigé depuis, mais c’est une des raison qui fais que Dropbox ne serra jamais vraiment destiné à un public de devs

    Submodule = projet inclus dans un projet. Tu peux faire ça à l’infinit, faire un submodule d’une branch, d’un tag, d’une millestone … bref, t’as aucune limite.

    C’est une des méthode que j’utilise pour gérer les assets et les dependencies dans mes projets et ça me permet de dissocier les éléments de celui-ci. Comme ça, l’inté n’a pas accés à tout les éléments du projets.

    Avec ça, tu ajoute le fait que Git soit complètement décentralisé et t’obtient juste le monde parfais pour le dev o/

    bref, comme dit Anah’, c’est SUPER, SUPER, SUPER, SUPER, SUPER et, j’allais l’oublier, SUPER utile !

  29. Regnareb dit :

    Pour Submodule ça reste assez flou pour ma part, mais ne me parait pas correspondre pour un projet non-dev mais uniquement artistique constitué juste d’assets, au contraire de Perforce (ou Dropbox à petite échelle), mais je me trompe peut-être, et si c’est le cas, dites le que je me force à tâter ça de plus près.

  30. Mousse dit :

    Tout dépends de ce que tu cherche mais si tu cherche à vouloir séparer les ressources, submodules est conseillé.

  31. firekorn dit :

    Même pour du graphisme ou toute forme d’art je pense que github sous windows est largement bien mieux que dropbox avec la même accessibilité aux niveaux d’un cloud.

    Et pour le peu d’utilisation que j’en ai fait pour de la création musicale aucun souci actuellement!

  32. Regnareb dit :

    Pour mieux situer mon cas, je fais de la 3D, donc je me tape des centaines de fichiers divers et variés dans un paquet de différents dossier., c’est vraiment gérable ?
    Sur Dropbox je n’ai rien à gérer, je fais ctrl+s dans mon logiciel et basta. Si je trouve un problème dans mon fichier par la suite, il suffit de remettre une version légèrement plus ancienne et c’est terminé. Git pourrait vraiment m’apporter quelque chose dans ce cas-là ?

  33. channie dit :

    Regnareb> Git ne t’apportera rien pour ton cas précis.

  34. Mousse dit :

    Regnareb : tout dépend de ton utilisation.

    Si t’as besoin de “sauvegarder” des version précises, un CVS t’apportera les commits et tout le toutim. Sinon, dropbox

  35. Regnareb dit :

    C’est ce qu’il me semblait, merci pour les réponses.

Laisser un commentaire

Si vous avez un compte sur WeFrag, connectez-vous pour publier un commentaire.

Vous pouvez, entre autres, utiliser les tags XHTML suivant :
<a href="" title="">...</a>,<b>...</b>,<blockquote cite="">...</blockquote>,<code>...</code>,<i>...</i>