Salut,
Tous les jours !
Voici un petit argumentaire que j'avais fait à Manhattan lors d'un échange par mail :
Je te donne une seule raison qui moi me le fait utiliser sur tous mes projets : le déploiement.
En effet, quand tu n'utilises pas git et que tu veux déployer ton site ou tes modifications, tu le fais via FTP et tu uploades des fichiers mais tu ne sais pas toujours quels fichiers tu as modifié depuis la dernière fois, non ?
Avec git, je n'utilise jamais FTP (sauf pour 2-3 fichiers de config que je sors du versionning) et je ne me pose jamais la question de savoir quels fichiers je dois uploader.
Je fais mes modifs dans tous les fichiers que je veux, je commit (valide) mes modifs de manière atomique (des petites modifications) et quand je veux mettre en ligne (ou sur un serveur de versionnement distant) je pousse les modifs commitées. Ensuite avec un système de hooks intégrés dans git, je peux effectuer les actions désirées, dans mon cas me placer dans mon dossier de prod distant et "tirer" (pull) mes fichiers versionnés et uniquement ceux-ci (et même que les lignes modifiées...).
2ème raison, on ne sait pas toujours si on va être seul à bosser sur un projet pour toujours...
une 3ème pour la route : tu es en train de développer une nouvelle fonctionnalité sur un site qui touche 5 fichiers, ton code est instable et tu ne peux donc pas uploader ces fichiers en prod. Ton client t'appelle, il y a un bug qu'il faut résoudre tout de suite et pas de bol ce bug se trouve dans un des fichier instable
Comment tu fais ? Avec git, tu "mets de côté" tes modifs en cours, c'est-à-dire que tu reviens à la dernière version stable de tes fichiers, tu fais ton "hotfix", puis tu "réincorpores" tes modifs en gardant ton hotfix...
une 4ème : ce dernier cas peut être facilement géré aussi avec le système de branches de git. Comme des espaces-temps parallèles, les branches portent ton application à différents états. Tu as une branche principale stable que tu mets en prod, elle n'est jamais instable et quand tu veux faire une nouvelle feature, tu crées une nouvelle branche qui dupliques ton code à cet instant, tu fais tes modifs et quand c'est stable et uniquement, tu fusionnes cette branche sur la principale.
Enfin bon pour PLEIN de raisons git est quasi indispensable pour s'intégrer dans ton workflow et pas seulement en équipe. Je ne parle pas non plus des retours en arrière, des modifs partielles, du partage simple du code et aussi ça va conditionner ta manière de coder, tu seras plus atomique et concentré sur une petite partie fonctionnelle.
Tu peux regarder git" rel="noopener" >les vidéos de Grafikart sur git, c'est un bon aperçu.
Voilà
Modifié par MatthieuR (20 May 2016 - 09:32)
Tous les jours !
Voici un petit argumentaire que j'avais fait à Manhattan lors d'un échange par mail :
Je te donne une seule raison qui moi me le fait utiliser sur tous mes projets : le déploiement.
En effet, quand tu n'utilises pas git et que tu veux déployer ton site ou tes modifications, tu le fais via FTP et tu uploades des fichiers mais tu ne sais pas toujours quels fichiers tu as modifié depuis la dernière fois, non ?
Avec git, je n'utilise jamais FTP (sauf pour 2-3 fichiers de config que je sors du versionning) et je ne me pose jamais la question de savoir quels fichiers je dois uploader.
Je fais mes modifs dans tous les fichiers que je veux, je commit (valide) mes modifs de manière atomique (des petites modifications) et quand je veux mettre en ligne (ou sur un serveur de versionnement distant) je pousse les modifs commitées. Ensuite avec un système de hooks intégrés dans git, je peux effectuer les actions désirées, dans mon cas me placer dans mon dossier de prod distant et "tirer" (pull) mes fichiers versionnés et uniquement ceux-ci (et même que les lignes modifiées...).
2ème raison, on ne sait pas toujours si on va être seul à bosser sur un projet pour toujours...
une 3ème pour la route : tu es en train de développer une nouvelle fonctionnalité sur un site qui touche 5 fichiers, ton code est instable et tu ne peux donc pas uploader ces fichiers en prod. Ton client t'appelle, il y a un bug qu'il faut résoudre tout de suite et pas de bol ce bug se trouve dans un des fichier instable
Comment tu fais ? Avec git, tu "mets de côté" tes modifs en cours, c'est-à-dire que tu reviens à la dernière version stable de tes fichiers, tu fais ton "hotfix", puis tu "réincorpores" tes modifs en gardant ton hotfix...une 4ème : ce dernier cas peut être facilement géré aussi avec le système de branches de git. Comme des espaces-temps parallèles, les branches portent ton application à différents états. Tu as une branche principale stable que tu mets en prod, elle n'est jamais instable et quand tu veux faire une nouvelle feature, tu crées une nouvelle branche qui dupliques ton code à cet instant, tu fais tes modifs et quand c'est stable et uniquement, tu fusionnes cette branche sur la principale.
Enfin bon pour PLEIN de raisons git est quasi indispensable pour s'intégrer dans ton workflow et pas seulement en équipe. Je ne parle pas non plus des retours en arrière, des modifs partielles, du partage simple du code et aussi ça va conditionner ta manière de coder, tu seras plus atomique et concentré sur une petite partie fonctionnelle.
Tu peux regarder git" rel="noopener" >les vidéos de Grafikart sur git, c'est un bon aperçu.
Voilà
Modifié par MatthieuR (20 May 2016 - 09:32)
Les arguments de Matthieu pour l'utilisation de git sont tout à fait exacts.
Il convient toutefois de noter que ces principes demeurent valables pour les autres gestionnaires de source actuellement disponibles (SVN et consorts).
git et ces outils sont intégrés dans les principaux EDI (Eclipse, etc.), soit de façon native, soit via des extensions (plugins).
Il peut être utile de les comparer, avant de retenir celui qui colle le mieux aux besoins. git a le vent en poupe, mais il n'est pas seul dans ma course.
Il convient toutefois de noter que ces principes demeurent valables pour les autres gestionnaires de source actuellement disponibles (SVN et consorts).
git et ces outils sont intégrés dans les principaux EDI (Eclipse, etc.), soit de façon native, soit via des extensions (plugins).
Il peut être utile de les comparer, avant de retenir celui qui colle le mieux aux besoins. git a le vent en poupe, mais il n'est pas seul dans ma course.
MatthieuR a écrit :
Je te donne une seule raison qui moi me le fait utiliser sur tous mes projets : le déploiement.
En effet, quand tu n'utilises pas git et que tu veux déployer ton site ou tes modifications, tu le fais via FTP et tu uploades des fichiers mais tu ne sais pas toujours quels fichiers tu as modifié depuis la dernière fois, non ?
C'est vrai que ce doit être génial, et j'ai souvent souhaité l'utiliser, mais cette configuration exige au minimum un accès SSH pour le serveur. Chez OVH il y a des accès SSH sur les mutualisés à partir de la version pro.
Zelena a écrit :Ce matin j'ignorais totalement la signification de ce terme.
Je sais bien que c'est hors-sujet mais 'git' en anglais britannique, c'est pas sympa du tout...
Du coup ce commentaire m'a toqué et je suis donc aller en chercher le sens. Pour la petite histoire, enfin je vous dis ça mais je suis peut-être le seul qui ne le savais pas, mais git a été créé par le même créateur que Linux.
Cette personne sembla avoir si fort peu d'estime pour elle-même qu'elle a choisie de nommer ses projets par des traits de caractères qui lui son propre.
Nous sommes loin de l'image de l'Homme sur son piédestal.
Le système Linux a été renommé avant distribution mais il portait lui aussi un nom tout aussi péjoratif ; une espèce d'anagramme de son nom.
Je vous invite à vous renseigner sur le mot-clé git vous risquez fort d'en apprendre de l'intéressant mais aussi du surprenant.
Vous l'aurez compris je ne suis pas familier avec le git. Au départ je pensais qu'il s'agissait d'un phénomène de mode. Quelle surprise quand j'ai découvert que cela existait déjà dans une forme précaire avant les années 90. Même si ce concept n'a connu son essor qu'au XXIème siècle.
Je ne suis pas réfractaire au concept et j'ai essayé comme tout bon croyant.
Verdict : Je n'ai rien compris. Déjà le git, il n'y en a pas un mais tout un chapelet, difficile de faire un choix. Heureusement mes contraintes matériels ont pas mal étayer le liste mais tout de même. Disons que pour l'instant j'en ai essayé deux et que je n'ai même pas sus produire un truc (ha si, le master
).De ce que j'en ai vu, il semble s'agir d'un outil formidable. Toutefois son utilisation nécessite un réel apprentissage donc un investissement temps très conséquent. Je pense qu'il n'est pas trop que de dire même qu'une formation est nécessaire afin d'avoir d'une part la maitrise de l'outil et apprendre à gérer les interactions avec les participants.
Une bleusaille comme qui débarque dans une boite avec un tel outil, je ne vous raconte pas le carnage que j'y fais.
Hô mais je ne désespère pas, je me suis mis sous le coude Tortoise. A force de l'asticoter je devrais bien en tirer quelque-chose, non ?
Et vous, qu'est-ce qui vous a mis le pied à l'étrier ? Vous avez galéré, mis beaucoup de temps ou au contraire vous avez tout de suite pigé le truc ?
Modifié par Greg_Lumiere (20 May 2016 - 17:23)
Olivier C a écrit :
C'est vrai que ce doit être génial, et j'ai souvent souhaité l'utiliser, mais cette configuration exige au minimum un accès SSH pour le serveur. Chez OVH il y a des accès SSH sur les mutualisés à partir de la version pro.
En même temps, un mutu Pro chez OVH, le mini pour un accès SSH, ça coûte 7,19€TTC/mois
, je pense que c'est quand même raisonnable pour avoir un peu la main sur un serveur, d'autant que je suis quasi sûr que git est déjà installé...Sinon, tu peux avoir un VPS correct chez PulseHeberg à 3€TTC/mois, ça ne coûte plus rien, je n'en reviens toujours pas... Et là tu as la main complète dessus, tu installes ce que tu veux !
Greg_Lumiere a écrit :
Déjà le git, il n'y en a pas un mais tout un chapelet, difficile de faire un choix.
En fait il n'y a qu'un seul git, c'est un logiciel et heureusement car les commandes ne seraient jamais les mêmes. Il existe cependant des interfaces, des surcouches visuelles qui utilisent git et tentent de le rendre peut-être plus accessible, mais il n'y a qu'un seul git
A mon avis Greg_Lumiere, il faut en avoir l'utilité ....
Moi je crée des dossiers T1, T2, T3 ... pour avoir une trace de mon code pendant l'évolution. Version, gigolo du dimanche
Samedi dernier, je me suis fait avoir, planté le code car dérangé toute l'après midi. J'ai trouvé mon erreur le soir, mais il faut faire des copies de sauvegarde pour revenir en arrière au cas ou ...
MatthieuR, est pro, donc il a pas la même optique que le rigolo que je suis.
On boxe pas dans la même catégorie 
J'ai lancé se sujet pour avoir une idée de son utilisation. Je reste à ma place, je ne me prend pas pour ce que je ne suis pas. Il faut savoir rester humble face aux grands maîtres qu'il y a sur le forum
Moi je crée des dossiers T1, T2, T3 ... pour avoir une trace de mon code pendant l'évolution. Version, gigolo du dimanche
Samedi dernier, je me suis fait avoir, planté le code car dérangé toute l'après midi. J'ai trouvé mon erreur le soir, mais il faut faire des copies de sauvegarde pour revenir en arrière au cas ou ...
MatthieuR, est pro, donc il a pas la même optique que le rigolo que je suis.
On boxe pas dans la même catégorie J'ai lancé se sujet pour avoir une idée de son utilisation. Je reste à ma place, je ne me prend pas pour ce que je ne suis pas. Il faut savoir rester humble face aux grands maîtres qu'il y a sur le forum
Tintin75 a écrit :
A mon avis Greg_Lumiere, il faut en avoir l'utilité ....
Moi je crée des dossiers T1, T2, T3 ... pour avoir une trace de mon code pendant l'évolution. Version, gigolo du dimanche
Samedi dernier, je me suis fait avoir, planté le code car dérangé toute l'après midi. J'ai trouvé mon erreur le soir, mais il faut faire des copies de sauvegarde pour revenir en arrière au cas ou ...
MatthieuR, est pro, donc il a pas la même optique que le rigolo que je suis.
J'ai lancé se sujet pour avoir une idée de son utilisation. Je reste à ma place, je ne me prend pas pour ce que je ne suis pas. Il faut savoir rester humble face aux grands maîtres qu'il y a sur le forum
A priori, je suis un pro (du moins ma boîte me paye-t-elle en cette qualité
), et nous utilisons au quotidien les gestionnaires de source adéquats (TFS pour C#, SVN pour Java, peut-être git prochainement).Et pourtant... je sauvegarde chaque soir l'intégralité de mon projet du moment dans un sous répertoire séquentiel (XXX_01, XXX_02, etc.).
Tout gestionnaire de source crée dans l'arborescence qu'il gère des sous dossiers / fichiers contenant les informations qui lui sont nécessaires pour le suivi des versions et, parfois, ben il perd les pédales et se plante (essentiellement lorsque des ressources ont été supprimées).
Rien de paranoïaque là dedans, cela m'est arrivé...
A ce moment là, on est alors bien content de récupérer la version N dudit projet, toute propre et non polluée par des éléments exogènes créés par le gestionnaire de source en question.
Pour le générateur HTML en cours de développement perso, je procède sans git, SVN ou autre, et chaque image prise instant T est systématiquement transférée dans mon espace cloud chez mon FAI.
Ceci n'est pas un dogme absolu, juste ma façon de faire
Greg_Lumiere a écrit :
Pardon, je me suis mal exprimé.
Effectivement les commandes sont les mêmes par contre il y a moulte interfaces et autres modules. Moi qui pensait qu'il n'existait que github, imagine.
En fait github n'est qu'une plateforme qui héberge des projets portés par git, ça n'est pas git, comme gitlab ou bien Bitbucket, c'est du stockage distant de projets git, et donc potentiellement un bon moyen de partager son code (public ou privé).
sepecat a écrit :
A ce moment là, on est alors bien content de récupérer la version N dudit projet, toute propre et non polluée par des éléments exogènes créés par le gestionnaire de source en question.
Ce qui est cool avec git c'est qu'il ne modifie pas du tout tes fichiers (pas comme SVN ou subversion...).
Pour ma part, l'ensemble de mes projets sont également sauvegardés sur un NAS, et synchronysés avec Dropbox. Egalement, à chaque "push" sur le serveur de prod, un hook déploie aussi le projet sur Bitbucket.
Ça permet de prévenir tout problème lié à git.
Tintin75 a écrit :
Comme, je dit on ne fait jamais assez de sauvegarde. Il y a le cloud gratuit, si on veut stocker de la data quelques part.
Avant d'utiliser un système de version je me servais d'Automator sous Mac OS X afin de faire une sauvegarde automatique et journalière de mon travail.
JE ne peux que plussoyer les principaux avis déjà évoqués. Pour moi, même pour mes projets perso, les deux killer features sont :
* Une fois un hook adéquat mis en place, plus besoin de se connecter en FTP pour uploader ses fichiers à la mano. Je crois que le coup des fichiers old-index.php ou zzz-index.php, on l'a tous fait à ses débuts; avec git, fini les dossiers bordéliques qui ont des noms pareils.
* La solution ultime au coup du bug à corriger tout de suite dans un fichier dans lequel tu es en train d'implémenter des nouvelles fonctionnalités. Ca m'est vraiment arrivé et j'ai été littéralement coincé avec SVN car il ne gère pas les branches, donc opte vraiment pour git et pas SVN.
En ce qui me concerne, sur mon plus gros projet perso, j'ai même développé la version un peu plus évoluée du hook. Quand on push sur master, ça met à jour le site de prod; quand on push sur une branche qui s'appelle devquelquechose, ça met à jour le site de test.
On peut même encore faire mieux si on veut, lancer automatiquement des tests unitaires et refuser l'envoi si ça ne passe pas; vu que je n'ai encore jamais fait de très gros projets en groupes de plus de 2 ou 3 personnes, je n'ai jamais cherché à le faire; mais je sais qu'on peut sans avoir forcément à passer par un truc encore plus complexe genre jenkins.
En bonus ça m'a permis d'arrêter carrément le serveur FTP. Ce n'est pas forcément négligeable, il y a quand même pas mal de pirates qui essaient d'attaquer les serveurs en passant par le FTP. ET pour les rares fichiers de config qui ne doivent pas être versionnés, p.ex. parameters.yml dans les projets symfony, SFTP est suffisant.
Cela dit, c'est juste, c'est un outil complexe, il faut du temps pour l'assimiler; moi-même je ne suis pas un expert et loin de l'être, j'ai encore du mal avec rebase par exemple, car n'ayant encore jamais travaillé dans des équipes dépassant 2 ou 3 personne, je ne l'utilise que très très rarement.
Pour apprendre, j'ai trouvé que le livre officiel en version traduite était très bien; je n'ai plus la'dresse mais il est en libre accès. Il part des bases de l'utilisation de git jusqu'aux commandes les plus spéciales, en passant par l'installation sur son serveur.
Ce qui m'a le plus enquiquiné dans mes débuts avec git, c'est la gestion des sauts de ligne quand on code sous windows et que le serveur tourne sous linux. SVN est permissif avec ça donc on ne s'aperçoit de rien. git est strict et j'ai passé des heures à piger comment il fallait faire pour éviter les « modifications fantômes » qui m'ont obligé plusieurs fois à réinitialiser totalement mes répertoires git. Ca a été casse-pieds à mourir et d'autant plus quand c'est les github qu'on doit effacer puis refaire.
Alors si c'est votre cas, avant même de commencer à utiliser, réglez le paramètre core.autocrlf à true sous windows et input sous linux, sinon vous aurez rapidement des ennuis.
Une chose est sûre, avec git, plus vrai que jamais, je crois que la maxime « l'essayer c'est l'adopter » s'applique. En tout cas maintenant que j'y ai goûté, je n'aimerais plus revenir à SVN ou me passer totalement de gestionnaire de version.
Ah oui, au passage, bitbucket permet de créer des projets privés gratuitement, alors qu'avec github il faut payer pour créer des projets privés. ET je trouve que même le plus petit forfait est cher pour ce que c'est, si je me souviens bien c'est 10€ pour 5 répertoires privés.
Ca ne me paraît pas cher en valeur absolue, mais quand on peut avoir deux VPS ou un KS pour ces mêmes 10€, j'ai l'impression que c'est un peu abuser.
Si le problème c'est l'hébergement, il y a très certainement moyen de passer par des webhook.
* Une fois un hook adéquat mis en place, plus besoin de se connecter en FTP pour uploader ses fichiers à la mano. Je crois que le coup des fichiers old-index.php ou zzz-index.php, on l'a tous fait à ses débuts; avec git, fini les dossiers bordéliques qui ont des noms pareils.
* La solution ultime au coup du bug à corriger tout de suite dans un fichier dans lequel tu es en train d'implémenter des nouvelles fonctionnalités. Ca m'est vraiment arrivé et j'ai été littéralement coincé avec SVN car il ne gère pas les branches, donc opte vraiment pour git et pas SVN.
En ce qui me concerne, sur mon plus gros projet perso, j'ai même développé la version un peu plus évoluée du hook. Quand on push sur master, ça met à jour le site de prod; quand on push sur une branche qui s'appelle devquelquechose, ça met à jour le site de test.
On peut même encore faire mieux si on veut, lancer automatiquement des tests unitaires et refuser l'envoi si ça ne passe pas; vu que je n'ai encore jamais fait de très gros projets en groupes de plus de 2 ou 3 personnes, je n'ai jamais cherché à le faire; mais je sais qu'on peut sans avoir forcément à passer par un truc encore plus complexe genre jenkins.
En bonus ça m'a permis d'arrêter carrément le serveur FTP. Ce n'est pas forcément négligeable, il y a quand même pas mal de pirates qui essaient d'attaquer les serveurs en passant par le FTP. ET pour les rares fichiers de config qui ne doivent pas être versionnés, p.ex. parameters.yml dans les projets symfony, SFTP est suffisant.
Cela dit, c'est juste, c'est un outil complexe, il faut du temps pour l'assimiler; moi-même je ne suis pas un expert et loin de l'être, j'ai encore du mal avec rebase par exemple, car n'ayant encore jamais travaillé dans des équipes dépassant 2 ou 3 personne, je ne l'utilise que très très rarement.
Pour apprendre, j'ai trouvé que le livre officiel en version traduite était très bien; je n'ai plus la'dresse mais il est en libre accès. Il part des bases de l'utilisation de git jusqu'aux commandes les plus spéciales, en passant par l'installation sur son serveur.
Ce qui m'a le plus enquiquiné dans mes débuts avec git, c'est la gestion des sauts de ligne quand on code sous windows et que le serveur tourne sous linux. SVN est permissif avec ça donc on ne s'aperçoit de rien. git est strict et j'ai passé des heures à piger comment il fallait faire pour éviter les « modifications fantômes » qui m'ont obligé plusieurs fois à réinitialiser totalement mes répertoires git. Ca a été casse-pieds à mourir et d'autant plus quand c'est les github qu'on doit effacer puis refaire.
Alors si c'est votre cas, avant même de commencer à utiliser, réglez le paramètre core.autocrlf à true sous windows et input sous linux, sinon vous aurez rapidement des ennuis.
Une chose est sûre, avec git, plus vrai que jamais, je crois que la maxime « l'essayer c'est l'adopter » s'applique. En tout cas maintenant que j'y ai goûté, je n'aimerais plus revenir à SVN ou me passer totalement de gestionnaire de version.
Ah oui, au passage, bitbucket permet de créer des projets privés gratuitement, alors qu'avec github il faut payer pour créer des projets privés. ET je trouve que même le plus petit forfait est cher pour ce que c'est, si je me souviens bien c'est 10€ pour 5 répertoires privés.
Ca ne me paraît pas cher en valeur absolue, mais quand on peut avoir deux VPS ou un KS pour ces mêmes 10€, j'ai l'impression que c'est un peu abuser.
a écrit :
C'est vrai que ce doit être génial, et j'ai souvent souhaité l'utiliser, mais cette configuration exige au minimum un accès SSH pour le serveur. Chez OVH il y a des accès SSH sur les mutualisés à partir de la version pro.
Si le problème c'est l'hébergement, il y a très certainement moyen de passer par des webhook.