{"word_count": 1146, "character_count": 7429}
Oui, oui ! Les codes sources sont sauvegardés, partagés, historisés : c'est hyper pratique ! Alors quand on accueille une nouvelle personne dans l'équipe, on lui raconte plein de choses sur comment ça marche et tout et tout et si elle ne connaît pas Git, voilà les pistes qu'on lui donne...Quelques liens utiles pour s'y retrouverOu du moins, quelques liens que je trouve utiles. Si vous découvrez d'autres sites "clairs", ça m'intéresse ! :-)http://ndpsoftware.com/git-cheatsheet.html#loc=local_repo; (mon préféré : cliquez, savourez !)https://rogerdudler.github.io/git-guide/ (à faire dérouler vers le bas, plein de choses)https://github.github.com/training-kit/downloads/github-git-cheat-sheet.pdf (attention, github donc parfois des infos spécifiques)https://git-scm.com/docs (la doc officielle, ya k'ça d'vrai !)https://gitlab.in2p3.fr/grasland/formation-git : une formation git, gitté sur gitlab, merci Hadrien Grasland. NB. Dans un mail envoyé par Hadrien à la liste devlog@services.cnrs.fr, il écrit : « Vous en trouverez donc le source et les rendus prêts à l'emploi, sous licence CC BY-SA, sur le dépôt GitLab suivant : https://gitlab.in2p3.fr/grasland/formation-git . », pourtant son dépôt ne contient pas de licence [et donc on n'aurait le droit de ne rien faire, ni réutilisation, ni partage, ni modif...]. Mon conseil : lui envoyer un petit mail pour confirmer les choses ;-)Pour votre plaisir, je suis allée un peu plus loin..Bah oui ! Parce que vous n'êtes pas à côté de moi à pouvoir me poser des questions et tout et tout...Comment j'installe ça ?Vous êtes sous Linux ? Alors, c'est simplissime ! sudo apt-get install git ou toute commande équivalente selon votre version de linux et c'est fait ! Vous pouvez aussi installer gitk ou gitg qui proposent une "interface graphique" (enfin... ne vous attendez pas non plus à un appart avec vue sur Belledonne ...)Vous êtes sous Windows ou Mac ?  Des échanges qui ont eu lieu sur la liste de diffusion devlog@services.cnrs.fr début juillet (d'autres avaient eu lieu en juin 2018) et je vous propose ici un résumé (des échanges de juillet 2019 uniquement). Je n'ai donc rien inventé, et remercie les participants aux échanges ! Rien d'exhaustif, juste les "conseils" de la communauté et du gratuit ! Pour fouiller plus loin, si rien ne vous satisfait, fouillez sur le site officiel de git : https://git-scm.com/downloads/guisWindows/Mac/Linux : un multiplateforme peut-être utile afin que tout le monde ait la même interface. En voici quelques-uns :Git Cola sont  multiplateforme aussiGitKraken "permet de faire plein de choses (même compliquées) juste avec la souris : rebase, checkout, cherry pick, revert, ... Et si on se trompe, on peut faire des undo !". Cela dit, il a une partie payante... à voir donc selon les besoins. De plus, il semble qu'il faille se créer un compte GitKraken ou bien s'authentifier avec GitHub...Mac/Windows :Sourcetree, GitHub Desktop ou encore ForkWindows :TortoiseGit "répond bien aux besoins de non informaticiens et s'intègre bien à l'explorateur de fichier"Autre solution : installer un sous-système Linux. Je connais absolument pas, mais peut-être que ça vaut le coup de fouiller. Voici un lien avec des infos probablement utiles : https://docs.microsoft.com/fr-fr/windows/wsl/install-win10Une autre solution encore est celle d'utiliser l'éventuelle extension de votre logiciel de développement. À voir selon ce que vous utilisez... Eclipse (dont le plugin basique mais efficace egit), Visual Studio Code, Atom ou que sais-je encore. Cela dit, a priori, passer par un outil dédié semble plus sage car étant plus spécialisez, ces logiciels sont plus faciles à utiliser et évitent de commettre des erreurs (oubli de commiter certains fichiers, par exemple...)Et je choisi quoi comme hébergement ?Ne faites pas comme celui-que-je-ne-nommerai-pas qui utilise bien Git, mais en local : bien qu'il fasse une sauvegarde régulière de son disque, question partage avec les collègues ou la communauté, c'est moyen !Des solutions d'hébergement, il y en a plusieurs, pleins même :github, le plus connu ;gitlab, son équivalent libre ;les git institutionnels bien sûr !chez Huma-Num,chez Renater,et par chez nous, à Grenoble, GRICAD héberge aussi un serveur Git. Bref, on a l'embarras du choix.Si je peux me permettre de lancer un ou deux conseils :passer par un hébergement institutionnel, c'est plus pro et valorisant pour nos tutelles et le monde de la recherche en particulier... mais c'est aussi "s'ostraciser et être moins visible...". Le débat est ouvert ! ;-)choisir un hébergement proche de votre lieu de travail (ou bien du barycentre des participants) (se renseigner sur la localisation du Data Center), c'est aussi faire un choix écolo, car le transfert de données, ça coûte !choisir un Data Center dont la PUE (Power Usage Effectiveness) est faible peut (doit !) aussi jouer dans la balancepasser par gitlab, c'est faire le choix d'un logiciel libre !Mais au fait, ça sert à quoi ?Je ne me lance pas dans une définition ou des propos exhaustifs, mais concrètement :c'est un super pas vers le partage, la mise à disposition ;ça permet le déploiement simple sur plusieurs machines (git clone mon ami) ;dès que l'on dépose sur un git, on est aussi amené à se poser des questions de licence, de qui a accès ou pas ;ça motive aussi à faire des choses plus propres... ou pas.c'est un outil rassurant car l'historique complet des modifications est sauvegardé ;cela peut aider à la reproductibilité ;cela permet de mieux réutiliser son propre travail...... et aider au débuggage ;cela permet de s'organiser grâce au système de tickets.Pour les plus débutants...Les commandes de bases sont add, commit, push, pull et status. Voici une méthode de travail que j'utilise pour travailler sereinement (elle n'implique que moi) :débuter toute séance de travail par un pull : ainsi on récupère tout ce qui aurait pu changer depuis la dernière séance de travail. Vous pouvez aussi faire un petit status histoire d'observer s'il ne reste pas des modifications ça et là qu'il faudrait traiterséquencer le travail et se donnant un objectif précis, une tâche. Après chaque tâche, faire un commit de ses modifications. Au cours d'une tâche, ne modifier que les fichiers nécessairesfinir chaque séance par un push et éventuellement à nouveau un statusSi vous utilisez git de façon très séquentielle et que vous avez la chance de ne pas avoir de conflit d’édition, ce sont les seules commandes à utiliser.Un petit exemple ?Le voici, en supposant que la tâche soit "changer la couleur d'arrière plan sur les pages corpus" et soit signalée dans le ticket n°2 :&#62; git pull #je récupère la dernière version# Faire ses modif', je suppose ici sur les fichiers style.css et corpus.twig.html&#62; git commit -m "Fix #2 - Background color update" style.css corpus.twig.html# Là, non seulement, j'indique un message pour qu'on s'y retrouve mieux (facilite les futures recherches et la compréhension du code, mais en plus je cite le ticket en utilisant #2 ET j'indique qu'avec mon commit celui-ci est résolu en utilisant le mot-clef "fix". Le ticket est automatiquement fermé. Pratique, non ?&#62; git status # simplement pour vérifier que l'on a bien commiter toutes nos modif'&#62; git push #hop, c'est déposé sur le serveur !Pour les plus avancés...À propos de Git merge et rebase : https://delicious-insights.com/fr/articles/bien-utiliser-git-merge-et-rebase/ 