Discussion :

[GuilhemYates]

Bonjour à tous, en plus de questions, je vais commencer par un petit coup de gueule

Je suis actuellement en formation développeur web, je suis sur un projet où l'on doit utiliser Github, les commit, push et tout le jargon etc que je comprends mais j'essaie péniblement de comprendre leurs fonctionnements et utilités.
J'essaie de lier Github à VSCode, jusque là ça va mais après, dès que je commence à faire de nouveaux documents, il me demande de faire une validation sur un fichier qui s'appelle COMMIT_EDITMSG où je dois écrire des trucs... ou pas (j'en sais rien) et au final, après des manipulations plus ou moins au pif, ça finit par me dire pleins de truc comme quoi j'ai rien fait, sûrement dû au fait que je n'ai rien compris en réalité (cette longue phrase qui mène à rien montre un peu que je sais pas où je vais et que je pète des câbles à essayer de comprendre ). J'ai désinstallé (totalement) puis réinstallé VSCode en pensant avoir zappé quelque chose, j'y ai mis toutes les extensions qu'il faut, j'ai essayé avec Gitkraken mais j'ai toujours le même problème, je n'arrive pas à bien lier tout ça, ou du moins, je ne comprends comment sauvegarder et tout synchroniser. J'ai l'impression de buter sur quelque chose de tellement simple que je finis par me compliquer les choses pour rien et finir par dire "Ah oui ok c'est comme ça et clic c'est résolu. Mon écran a de la chance d'être cher car j'ai ma main qui ne veut pas taper que sur le clavier

Bref, j'y comprends strictement rien, j'ai visionné et lu plus d'une vingtaine de tuto sans succès, je suis allé sur des forums où la plupart des réponses est: "pourtant c'est simple, regarde sur internet, il y a plein de tuto" très constructif comme réponse Ou sinon, il n'y pas de réponse. La plupart des recherches Google donnent sur des gens qui font plus la promotion de leur site plutôt que de répondre à la question qui est pourtant en gros titre de leur page. Même, ici, j'ai fait les 51 pages du Forum Débuter, je n'ai rien trouvé sur Github. Je croyais que Github était important vu le nombre de gens qui m'en parlent. Mais comme tout sujet important dans la vie, nous faisons que les ignorer ou au mieux on les survole sans aller dans le fond et je pense que je vais faire de même.

Ma première question: Quand/si on arrive à lier Github à VSCode, lorsqu'on écrit son code sur VSCode, est-ce que ça enregistre tout seul (ou presque) sur Github?
Sachant que je ne compte pas du tout travailler en équipe, intégrer une agence ou une entreprise après la formation. J'ai déjà commencé à faire des sites pour des petites entreprises, et que la plupart des clients en on strictement rien à faire de la manière dont je fais leurs sites web tant qu'ils en ont un: Est-ce utile que je m'intéresse à Github ou autre plateforme de ce genre?
À par le fait de travailler sur des gros projets au sein d'une équipe, quels sont les avantages d'utiliser Github?

Merci à ceux qui auront tout lu sans porter de jugement et à ceux qui me répondront. C'est un métier qui me passionne mais j'ai beaucoup de mal à apprendre quelque chose dont je ne comprends pas l'utilité.
J'aimerais dans la mesure du possible, avoir un tuto (récent, pas un tuto qui date de la création de Windows XP que j'aimais beaucoup) un tuto expliquant pas à pas les démarches à faire sans me mettre un lien que j'aurai déjà vu svp.
J'aimerais juste réussir à écrire mon code sur VSCode et qu'il synchronise automatique sur Github.

En attendant vos réponses, je vous souhaite une bonne soirée!

PS: Désolé pour les fautes d'orthographe.

[mathieu]

un système de gestion de versions a plusieurs utilités même quand on travaille seul.
si par exemple au début du projet on fait un code qui calcule 1 + 1 et qui affiche 2, on est content, on note cette partie comme faite et on passe à la suite. et après 3 semaines de travail, on se rend compte que la 1re partie affiche 1 + 1 = 3. avec git, il est alors possible de revenir en arrière avec le projet complet pour voir quelle modification a fait qu'on passe de 2 à 3.
ensuite git permet de créer des branches. on aura par exemple la branche de préparation de la sortie de la version 2 officielle et sur une autre branche, on peux en même temps tester des fonctionnalités qui seront sur la version 4 ... ou peut-être pas, on peut créer autant de branches dont on a besoin.

et ensuite quand on travaille à plusieurs sur le même projet, on a l'avantage de pouvoir travailler chacun sur une branche différente. vous pouvez voir un exemple de ce qu'il peut se passer avec le schéma de cette page :
https://nvie.com/posts/a-successful-...anching-model/
à la suite de ce schéma, vous verrez plusieurs exemples de code mais je ne sais pas si cela vous sera utile si c'est votre éditeur qui s'occupe de gérer cela.

en ce qui concerne le fichier COMMIT_EDITMSG, c'est l'endroit où vous allez décrire la modification qui a été faite. si on prend par exemple la modification de 3 fichiers là, le message qui a été écrit est "Avoid POP3 client..." :
https://github.com/PHPMailer/PHPMail...6875aefd69d846
si vous n'ajoutez pas de message dans ce fichier, l'envoi (le commit) est annulé.

[GuilhemYates]

Merci Mathieu, ça m'a bien éclairé sur le système de gestion de versions. Du coup, faut que je comprenne comment bien l'utiliser. Est-ce que vous pouvez m'expliquer comment lier mon Github à VSCode pas à pas svp?

en ce qui concerne le fichier COMMIT_EDITMSG, c'est l'endroit où vous allez décrire la modification qui a été faite. si on prend par exemple la modification de 3 fichiers là, le message qui a été écrit est "Avoid POP3 client..." :
https://github.com/PHPMailer/PHPMail...6875aefd69d846
si vous n'ajoutez pas de message dans ce fichier, l'envoi (le commit) est annulé.

Comment ajouter un message dans ce fichier? Car j'ai beau écrire quelque chose, rien ne se passe. Ai-je loupé un code pour pouvoir écrire un message?

[mathieu]

Est-ce que vous pouvez m'expliquer comment lier mon Github à VSCode pas à pas svp?

je n'ai jamais utilisé cet éditeur et d'habitude j'utilise git en ligne de commande donc je ne peux pas vous aider pour ce point.

Comment ajouter un message dans ce fichier? Car j'ai beau écrire quelque chose, rien ne se passe.

ce qu'il se passe habituellement est que vous écrivez votre message, vous enregistrez le fichier et c'est au moment de fermer la fenêtre que l'opération continue et que le commit est envoyé.

[GuilhemYates]

D'accord, en tout cas merci de votre aide. Je vais attendre de voir s'il y a d'autres internautes qui peuvent m'aider

ce qu'il se passe habituellement est que vous écrivez votre message, vous enregistrez le fichier et c'est au moment de fermer la fenêtre que l'opération continue et que le commit est envoyé.

C'est ce que j'essai de faire, mais ça ne rien enregistrer et du coup le commit n'est pas envoyer. Je vais ressayé jusqu'à trouver mon erreur. Merci encore

[NoSmoking]

Bonjour,
peut-être trouveras tu des réponses à tes questionnements dans la

FAQ Git : retrouvez les meilleures réponses à vos questions pour apprendre Git, de niveau débutant à expert

[Obsidian]

Bonjour et bienvenue,
J'arrive un peu après la bataille, pardon pour cela mais, du coup, pourrais-tu nous donner toi-même quelques informations te concernant pour que l'on puisse t'orienter au mieux ?

— Avec quel système d'exploitation travailles-tu (Windows, Linux, autre…) et éventuellement avec quel framework ?
— As-tu déjà fait du développement auparavant (autre que web) ou débutes-tu totalement ?
— As-tu déjà utilisé un logiciel de versioning autre que Git ? C'est important en soi, car cela va déterminer le type de réponse à t'apporter.

Je suis actuellement en formation développeur web, je suis sur un projet où l'on doit utiliser Github, les commit, push et tout le jargon etc que je comprends mais j'essaie péniblement de comprendre leurs fonctionnements et utilités. J'essaie de lier Github à VSCode,

On te rassure, c'est normal. ;-)

D'abord il faut distinguer git et github. Le premier est le logiciel de versioning en lui-même et est probablement l'un des meilleurs jamais conçus, même si c'est difficile de s'en rendre compte de prime abord. L'autre est une forge logicielle, c'est-à-dire une plateforme d'accueil en ligne servant à héberger un projet et le partager publiquement, pour collaborer ou simplement mettre facilement des sources à disposition des développeurs, ou même des personnes qui veulent récupérer directement la dernière version publiée, quitte à la compiler elles-mêmes. Elle est indépendante du projet Git lui-même et elle n'est pas non plus la seule (il existe Sourceforge, Gitlab, Bitbucket…)

Par contre, une forge logicielle n'est pas en soi, un « disque réseau » comme on en trouve sur le Cloud pour éviter de se trimbaler une clé USB ou un disque dur externe. Certains s'en servent abusivement à cela, mais dans le principe, elle sert bien à mettre en ligne un projet collaboratif de la même façon qu'un hébergeur web te permet de mettre un site web en ligne (même si, effectivement et dans ce dernier cas, cela revient effectivement à déposer ses fichiers dans un répertoire).

Donc tu n'es pas du tout obligé d'utiliser « Github » en soi pour faire du développement web. Si on te l'a fait ouvrir, c'est probablement pour pouvoir récupérer facilement ton travail depuis chez toi sans avoir besoin de te connecter aux serveurs de ton centre de formation.

Ensuite, Git a ceci d'intrigant qu'il paraît totalement cryptique de prime abord, jusqu'à ce que l'on saisisse les deux ou trois concepts clés qui soutiennent tout l'édifice, moment à partir duquel tout devient absolument limpide et parfois trivial. C'est assez étonnant quand on en fait l'expérience pour la première fois mais, effectivement, il vaut mieux être pris par la main par quelqu'un qui maîtrise la chose quand on fait ses premiers pas avec.

Par contre, du coup, même si c'est une interface graphique adoptée par quasiment tout le monde, il n'est probablement pas idéal d'aborder la chose directement via VSCode+Git+Github. D'abord parce que ça forme une couche d'abstraction qui va donner un côté « boîte noire » à la chose et ensuite parce que les plugins concernés vont rajouter leurs propres fonctionnalités avant même d'avoir commencé. Et enfin, parce qu'il va falloir résoudre les problèmes techniques qu'il peuvent engendrer, chose dont tu as l'air de faire justement l'expérience.

jusque là ça va mais après, dès que je commence à faire de nouveaux documents, il me demande de faire une validation sur un fichier qui s'appelle COMMIT_EDITMSG où je dois écrire des trucs... ou pas (j'en sais rien) et au final, après des manipulations plus ou moins au pif, ça finit par me dire pleins de truc comme quoi j'ai rien fait, sûrement dû au fait que je n'ai rien compris en réalité (cette longue phrase qui mène à rien montre un peu que je sais pas où je vais et que je pète des câbles à essayer de comprendre ).

Bon, ça, ça peut venir de trois choses, qui sont normales s'il n'y a pas de problème annexe. Chaque commit est accompagné au minimum d'un titre et, en principe, d'un message expliquant ce qu'on y trouve et ce qu'apporte la modification qu'il introduit. C'est ce message que tu rédiges au moment où tu commites et qui est temporairement enregistré dans le fameux fichier. Il faut également savoir que Git, en lui-même, t'autorise à utiliser n'importe quel éditeur pour le rédiger. Sous Linux en ligne de commande, c'est souvent vim ou nano. Par conséquent, le seul moyen pour Git de savoir si tu as bien validé la chose est d'examiner le contenu de ce fichier une fois que l'éditeur a rendu la main. De là :

— Soit le fichier est vide, auquel cas Git considère que c'est toi qui a quitté l'éditeur sans sauver et donc, annule l'opération (donc pas de commit) ;
— Soit le commit a bien eu lieu et Git te dit qu'il « ne reste plus rien » à enregistrer parce que tu viens en fait de le faire. Il changera d'avis quand tu introduiras de nouvelles modifications dans ton code ;
— Soit tu as justement demandé à effectuer un commit alors qu'il y a aucun modification notable dans ton dépôt. Dans ce cas, Git refuse de le faire (par défaut) car on n'enregistre pas de commit vide. Mais normalement, dans ce cas de figure, tu ne devrais même pas arriver jusqu'à l'éditeur de texte.

J'ai désinstallé (totalement) puis réinstallé VSCode en pensant avoir zappé quelque chose, j'y ai mis toutes les extensions qu'il faut, j'ai essayé avec Gitkraken mais j'ai toujours le même problème, je n'arrive pas à bien lier tout ça, ou du moins, je ne comprends comment sauvegarder et tout synchroniser. J'ai l'impression de buter sur quelque chose de tellement simple que je finis par me compliquer les choses pour rien et finir par dire "Ah oui ok c'est comme ça et clic c'est résolu. Mon écran a de la chance d'être cher car j'ai ma main qui ne veut pas taper que sur le clavier

Je croyais que Github était important vu le nombre de gens qui m'en parlent. Mais comme tout sujet important dans la vie, nous faisons que les ignorer ou au mieux on les survole sans aller dans le fond et je pense que je vais faire de même.

C'est surtout qu'il faut être sûr d'avoir bien saisi à quoi elle sert, et c'est ensuite dû au fait que c'est la plus populaire du moment (de la même façon que Youtube reste la plateforme vidéo la plus populaire même s'il existe DailyMotion et d'autres plateformes). Enfin, elle l'était jusqu'à ce qu'elle soit rachetée par Microsoft en 2018. Depuis, elle reste très utilisée mais certaines conditions d'utilisation la rendent problématique pour certains grands projets libres.

Ma première question: Quand/si on arrive à lier Github à VSCode, lorsqu'on écrit son code sur VSCode, est-ce que ça enregistre tout seul (ou presque) sur Github?

Tout seul, non.
Presque tout seul, oui.

Je n'utilise pas VSCode donc c'est difficile de te donner une indication exacte, mais c'est fait pour être facile. Donc cela doit se résumer à cliquer un bouton quelque part. En fait, la fonction concernée va simplement déclencher l'appel à « git push », telle qu'on l'utiliserait en ligne de commande, et c'est lui qui va faire le travail.

Ceci va effectivement synchroniser tes dépôts Git local et distant, mais il ne faut pas le voir comme une synchronisation de disque : c'est une vraie publication.

Sachant que je ne compte pas du tout travailler en équipe, intégrer une agence ou une entreprise après la formation. J'ai déjà commencé à faire des sites pour des petites entreprises, et que la plupart des clients en on strictement rien à faire de la manière dont je fais leurs sites web tant qu'ils en ont un: Est-ce utile que je m'intéresse à Github ou autre plateforme de ce genre? À par le fait de travailler sur des gros projets au sein d'une équipe, quels sont les avantages d'utiliser Github?

La réponse est « oui » car en ce qui concerne le versioning proprement dit, la manière de travailler est la même que tu travailles seul ou en équipe. En plus, ceci te permettra de partager facilement ton travail quand tu voudras le faire. Ça te permettra également de participer occasionnellement à des projets libres déjà en place (par exemple, envoyer un patch pour corriger le framework que tu utilises le plus) et, enfin, ça te permettra aussi de transmettre facilement ton projet à quelqu'un si souhaites passer à autre chose.

Pour Github en particulier, ce n'est pas nécessaire. Tu peux très bien travailler en local avec Git et initialiser un dépôt dans le sous-répertoire de ton choix. Il fonctionnera alors exactement de la même façon que si tu l'avais cloné depuis un projet Github ou n'importe quelle autre forge. Maintenant, si tu fais du web et que c'est récent, tu es probablement plus à l'aise avec les interfaces graphiques et l'avantage d'une forge toute faite, c'est qu'elle dispose d'une interface complète pour te permettre d'initialiser un projet tout neuf en te prenant par la main.

Si tu souhaites bénéficier d'une forge+interface mais sans avoir à la mettre en ligne, tu peux aussi regarder du côté de Gitlab, qui sert à la même chose, mais qui désigne aussi bien le service en ligne que le logiciel qui le fait tourner (un peu comme Wikipédia). Tu en installes une instance chez toi et tu peux travailler avec sans avoir besoin d'être connecté. C'est ce que l'on fait au boulot et dans la plupart des grandes structures.

Merci à ceux qui auront tout lu sans porter de jugement et à ceux qui me répondront. C'est un métier qui me passionne mais j'ai beaucoup de mal à apprendre quelque chose dont je ne comprends pas l'utilité.

C'est tout-à-fait normal et c'est tout à ton honneur. À vrai dire, on pourrait penser ce que c'est le cas de tous les corps de métier mais ça devient vital en informatique, et c'est pour cela que ça rebute toute une frange de la population, en particulier les gens qui sont plus à l'aise avec les méthodes « scolaires » traditionnelles.

J'aimerais dans la mesure du possible, avoir un tuto (récent, pas un tuto qui date de la création de Windows XP que j'aimais beaucoup) un tuto expliquant pas à pas les démarches à faire sans me mettre un lien que j'aurai déjà vu svp.

La documentation officielle en ligne de Git a une page consacrée à ça : https://git-scm.com/book/fr/v2/Annex...al-Studio-Code
Et cette page renvoie directement sur le site e Visual Studio Code : https://code.visualstudio.com/docs/s...ntrol/overview

J'aimerais juste réussir à écrire mon code sur VSCode et qu'il synchronise automatique sur Github.
En attendant vos réponses, je vous souhaite une bonne soirée!

Comme expliqué au dessus, une fois qu'on a compris la chose, un simple clic devrait suffire, mais il est important de comprendre qu'il s'agit bien d'un suivi de version documenté et pas d'un simple backup.

PS: Désolé pour les fautes d'orthographe.

(Il n'y en avait pas beaucoup mais j'ai corrigé celles que j'ai pu trouver ).

[GuilhemYates]

Woaw! Grand merci pour cette réponse agréable à lire! Même après la bataille, des informations supplémentaire restent toujours utiles et ainsi on peut gagner la guerre
De plus, t'on explication est simple et complète
Alors, avant de répondre, j'ai trouvé la solution à mon problème. Mais bon... ça fonctionne sans vraiment comprendre exactement comment ça fonctionne Mais vu que les projets de ma formation utilisent Github, je vais me cantonner à ça pour le moment, je verrai d'ici quelques mois les autres façons de faire. (Merci pour les fautes d'orthographes )

— Avec quel système d'exploitation travailles-tu (Windows, Linux, autre…) et éventuellement avec quel framework ?

Je suis sur Windows 10 et j'utilise essentiellement Visual Studio Code.

— As-tu déjà fait du développement auparavant (autre que web) ou débutes-tu totalement ?

Oui mais non. Disons que j'ai appris en autodidacte quelques base il y a quelques années, mais cela reste flou donc partons du principe que je débute totalement.

— As-tu déjà utilisé un logiciel de versioning autre que Git ? C'est important en soi, car cela va déterminer le type de réponse à t'apporter.

Non.

Donc tu n'es pas du tout obligé d'utiliser « Github » en soi pour faire du développement web. Si on te l'a fait ouvrir, c'est probablement pour pouvoir récupérer facilement ton travail depuis chez toi sans avoir besoin de te connecter aux serveurs de ton centre de formation.

Non, ils veulent juste qu'on sache utiliser une forge logiciel pour faire des commit.

C'est tout-à-fait normal et c'est tout à ton honneur. À vrai dire, on pourrait penser ce que c'est le cas de tous les corps de métier mais ça devient vital en informatique, et c'est pour cela que ça rebute toute une frange de la population, en particulier les gens qui sont plus à l'aise avec les méthodes « scolaires » traditionnelles.

La plupart du temps je cherche les solutions, informations, etc de moi-même mais pour certaines choses comme ici, une méthodes "scolaire" traditionnelles est, à mon avis, plus adapter.

Encore merci et je pense qu'après ta réponse je vais pouvoir mettre "résolu"

[Obsidian]

Oui mais non. Disons que j'ai appris en autodidacte quelques base il y a quelques années, mais cela reste flou donc partons du principe que je débute totalement.
[…]
Non, ils veulent juste qu'on sache utiliser une forge logiciel pour faire des commit.
[…]
La plupart du temps je cherche les solutions, informations, etc. de moi-même mais pour certaines choses comme ici, une méthode "scolaire" traditionnelle est, à mon avis, plus adaptée.

Dans ce cas, tu l'as probablement déjà découvert par toi-même, mais dans le doute, autant reprendre depuis le début.

L'objectif principal d'un logiciel de versioning n'est pas en soi la sauvegarde incrémentale d'un projet important, ni même de permettre le travail collaboratif, mais bien de gérer facilement les différentes versions d'un même projet et, entre chacune d'elles, la manière dont il évolue. En fait, si tu t'es déjà retrouvé dans ce genre de situation, c'est-à-dire à faire une ou plusieurs copies du dossier de ton projet pour en arrêter l'état, pour avoir une idée exacte de ce qui est en production quelque part tout en poursuivant le développement en parallèle ou pour conserver du contenu obsolète mais que tu voudrais éviter de perdre parce qu'il a demandé beaucoup de travail, alors c'est le signe qu'il te faut un logiciel de versioning pour gérer tout cela à ta place.

De même, dans ce dernier cas, il arrive souvent que l'on mette de grands blocs en commentaires dans un code source en commentaire avec la date, toujours pour la même raison : désactiver une routine obsolète sans la perdre. C'est vrai avec tous les langages de programmation, donc cela inclut ceux qui concernent le web tels que le Javascript ou le PHP. C'est un peu moins fréquent avec le HTML parce que c'est un poil plus délicat à mettre en place, que le bloc reste visible par le client et qu'étant donné la chose, c'est souvent plus simple de copier la page à côté, mais le problème reste le même.

De fait, toute l'idée d'un logiciel de versioning — dans un premier temps — est de te permettre de déclarer et consigner toutes les modifications que tu portes aux fichiers d'un dépôt donné. Le moment où tu vas faire ces déclarations ne dépend que de toi. Il n'y a aura pas d'enregistrement automatique entre deux déclarations, et celles-ci pourront être assez éloignées comme très rapprochées, tout dépend de l'importance des modifications que tu auras apportées à un moment donné. Quand on débute avec ce genre d'outils, on commite généralement en fin de journée pour enregistrer son travail mais quand on en a l'habitude, il est fréquent de faire des commits de sous-ensembles précis toutes les 15 à 20 minutes, par exemple.

Chaque commit va faire référence au précédent et former et ainsi former un historique de ton développement, étape par étape. Chaque étape constituant donc une « révision » de ton projet.

Lors de chaque commit, soit tu demandes au logiciel d'identifier et sélectionner automatiquement tous les fichiers qui ont été modifiés par rapport à la dernière révision, soit tu sélectionnes uniquement les fichiers qui t'intéressent, soit encore (avec Git), tu choisis carrément les modifications qui t'intéressent au sein d'un même fichier et tu les regroupes par thème, chacune formant l'objet d'un commit dédié. Lorsque c'est fait, au moment de commiter, tu documentes ces modifications soit par un simple titre (formé par la première ligne du fichier texte ouvert par l'éditeur), soit en développant en quelques lignes (de 10 à 100 environ), la raison d'être de ces modifications. Nul besoin d'intégrer la liste des fichiers ciblés dans ce message : le logiciel en tient la trace pour toi.

À partir du moment où ton premier commit est enregistré (le premier d'une longue lignée…), tu as alors accès à l'historique de ton dépôt : tu peux visualiser dans l'ordre chronologique inverse (le plus récent d'abord), la liste de tous les commits de ton dépôt avec, sur chaque ligne, la date, l'auteur et le titre (d'où l'importance de soigner ce dernier).

Par la suite, il t'est possible de revenir à une version donnée : avec la commande « checkout <revision> », le logiciel va d'abord vérifier s'il n'y a pas de nouvelles modifications en suspens qui n'ont pas encore été enregistrées. Si c'est le cas, il te demandera de le faire d'abord. Ensuite, tous les fichiers de ton dépôt qui sont suivis (= qui ont fait l'objet d'un commit au moins une fois) vont être soit effacés s'il n'existaient pas encore (ou plus) à la date de la révision, soit voir leur contenu remplacé par celui qui était en vigueur au moment du commit. Les fichiers non suivis, eux, restent intouchés. Ceci va donc te permettre de remettre ton dépôt dans l'état exact où il était à une époque donnée, puis te permettre de revenir à la dernière version en date aussi facilement dans un sens que dans l'autre !

Quand tu as suffisamment de commits, il est également possible de poser un ou plusieurs tags (étiquettes) sur les commits qui t'intéressent. Tu peux te servir de ces tags pour organiser ton travail comme il te chante, mais leur utilité principale sert justement à marquer les versions officielles de ton projet. Par exemple, lorsque tu estimes avoir rempli la totalité du cahier des charges et que tu mets ton code en production chez un client, tu vas nommer cette release « v1.0.0 » par exemple, et tu vas poser un tag portant ce nom sur le commit concerné. Ceci te permettra de retrouver facilement la version exacte déployée quelque part. C'est utile également si tu dois entamer des travaux assez audacieux par la suite (comprendre : tout casser et réécrire). En outre, ces noms de tags valent noms de révision.

On comprend dès lors qu'il te suffit de faire « git checkout v1.0.0 » pour retrouver instantanément la version 1.0.0 officielle, puis « git checkout master » (ou le nom de la branche sur laquelle tu travailles) pour revenir à l'état normal et poursuivre ton développement. Et ce n'est pas propre à Git. Tous les logiciels de versioning, à ma connaissance, proposent cette fonction.

Tu peux aussi demander à afficher le contenu d'un commit à l'écran. Là encore, il est fortement conseillé de soigner le contenu du titre et du message pour que toi ou une personne tierce puisse bien comprendre de quoi il en retourne. Une fois informé, tu peux visualiser tous les changements introduits à une date donnée et savoir dans quelle mesure telle ou telle fonction a été implémentée.

Il t'est également possible de comparer deux révisions, complètement arbitrairement. Il suffit de faire un git diff rev1 rev2 pour que Git compare individuellement tous les fichiers impliqués et te présente sous forme de patch toutes les différences qui permettent de passer de rev1 à rev2 même si l'historique qui a mené de la première à la seconde peut être très long. C'est pratique quand on a deux versions très différentes d'un logiciel bien sûr, mais également quand on réorganise ses commits (notion sur laquelle on reviendra dans un autre post) : quand tu as reconstruit toute une branche, c'est utile de pouvoir vérifier si le résultat final est identique à l'octet près à l'image de départ pour être sûr de ne rien oublier.

Enfin, pour enchaîner sur ce dernier point, il t'est possible de créer des « branches ». Celles-ci vont te permettre de forker facilement, c'est-à-dire de partir d'une version donnée pour diverger et produire quelque chose qui soit indépendant de la branche principale, quitte à refusionner ensuite cette branche avec elle, ou pas. Cela va être utile pour trois choses principales :
— spécialiser une version pour un environnement ou un client donné (quitte à terminer le développement dessus arrivé à un certain point) ;
— développer une fonctionnalité lourde ou longue et qui ne devra être intégré au produit qu'une fois terminée tout en laissant la possibilité de produire des bugfixes ou des fonctionnalités mineures sur la branche principale ;
— développer en équipe. Ça permet de reconstruire sa branche au besoin, de revenir en arrière, etc. sans empiéter sur les publications de ses collèges, et d'intégrer le tout une fois prêt.


Voila pour les grands thèmes.

Il faut savoir que les logiciels de versioning existent grosso-modo depuis les années 1980 (à l'exception de SCCS qui daterait de 1972) et que pendant très longtemps, c'est CVS qui a fait référence. Il y en a eu bien d'autres, notamment SVN très utilisé dans le grand public, mais aussi Darcs, Fossil, Bazaar, Monotone, Bitkeeper… jusqu'à l'arrivée quasi-simultanée de Git et Mercurial en 2005 qui ont écrasé tout le reste. Mercurial est sorti 15 jours seulement après Git, visiblement pour en faire une version moins cryptique. Les choix qui ont été faits, malheureusement, le rendait plus simple de prime abord mais conduisaient rapidement dans une impasse. Quelques gros projets l'utilisent toujours, mais la plupart des gens (y compris d'anciens utilisateurs de Mercurial) ont fini par se tourner vers Git.

Avec tout cela, tu devrais avoir suffisamment d'éléments pour comparer cela avec le travail que tu produis toi-même en ce moment et, de proche en proche, réaliser que cela va répondre à pas mal de tes besoins qui vont surgir prochainement, les uns après les autres. Tu pourras alors chercher facilement comment Git les aborde et ce sera la meilleure façon d'appréhender l'outil.

Bon courage.