Git : Présentation d’un Programme de Versioning Pratique

Publié le

Aujourd’hui sur le blog de Webdesign, une présentation de Git et quelques ressources pour bien démarrer

Je me rends compte que je ne vous ai pas encore parlé de Git sur le Blogduwebdesign, alors que je l’utilise quotidiennement. Cet article est la pour réparer cette erreur. Git, comme son nom ne l’indique pas, est un logiciel de gestion de versions. Vous connaissez peut être svn, bazaar, …, et bien il remplit les mêmes fonctions (mais en mieux ^^).

Si vous ne connaissez pas, je vous explique le concept avec trois situations.

Comment fonctionne GIT ?

Revenir en arrière sur une modification

Avez vous déjà perdu un fichier par inadvertance, ou souhaité pouvoir revenir en arrière, juste avant les dernières modifications faites ? Cela est possible avec Git.

Git va vous permettre, une fois installé dans un dossier, d’enregistrer les modifications faites sur vos fichiers sous la forme de commit. Vous choisissez les fichiers dont vous voulez inclure les modifications, vous mettez un petit message de commentaire, et vous enregistrez le commit. Vous pourrez ensuite revenir à l’état du fichier avant le commit, puis le ré appliquer. Une sorte de ctrl-z /ctrl-y en somme.

Faire des tests sans dupliquer son dossier

Avez vous déjà eu envie de tester quelque chose qui risquait de casser votre projet, tout en souhaitant le faire dans le dossier principal, sans avoir besoin de copier coller le dossier complet ? Git peut faire ça aussi.

Git permet de créer des branches dans votre fichier. Pour tester votre fonctionnalité, créez une branche. Si l’essai est concluant, vous pourrez appliquer certains ou tous les commit effectués dans la branche de test sur votre branche principale. Sinon, on supprime la branche et on en parle plus.

Collaborer

Avez vous déjà travaillé à deux sur un FTP, sur le même fichier, et écrasé les changements de votre collègue sans faire exprès ? Cela ne peut pas arriver avec Git.

Git vous permet de synchroniser l’état de votre projet entre plusieurs ordinateurs et serveurs. Vous pouvez donc travailler sur votre local, et pousser vos modifications sur le serveur une fois qu’elles sont testées et qu’elles marchent. Si quelqu’un a poussé ses propres modifications, il faudra « merger », c’est à dire mélanger les deux branches du projet. La plupart du temps l’opération est transparente.

(Notez que svn & co peuvent aussi aider dans ces situations, mais ils sont moins bien (trollolo))

Commencer avec Git

Alors, envie d’essayer ? La première chose à faire est de l’installer. Si vous êtes sur un *nix, je pense pouvoir dire sans souci que votre gestionnaire de paquet le connaît sous le nom de git. 

Pour la suite, je vous donne quelques ressources pour bien démarrer.

Suite aux demandes d’un tutoriel en français sur l’utilisation de Git, je me lance sur une série d’articles pour vous apprendre a utiliser et configurer git, installer et utiliser un serveur comme Gitosis, et quelques petites autres astuces.

Enfin, je ne traiterais ici que de la gestion de Git depuis la console. Il existe des interfaces, mais je me trouve toujours limité d’une façon ou une autre avec. Les commandes ne sont pas suffisamment nombreuses ou compliquées pour que l’utilisation en console ne soit pas préférée.

Utilisation de Git

Initialiser un repo Git

Pour ce tout premier exercice, nous allons créer un projet, que nous allons manager avec Git. Créons donc un dossier, puis positionnons nous dedans avec notre console. Pour cela, les gens sous linux ou mac devrons utiliser cd, et les gens sous Windows devront faire un clic-droit sur le dossier du projet et sélectionner git bash here.

Maintenant, nous allons initialiser git, avec la commande git init

Le résultat devrait être une ligne du genre Initialized empty repository in /your/path/here

Créer un fichier

Nous allons maintenant créer un fichier. Créeons donc un fichier README vide.

Nous allons pouvoir essayer notre première commande Git ! (Bon, nous avons bien utilisé init, mais elle ne compte pas trop). Essayons la commande git status

Nous pouvons voir en résultat le statut de notre dossier : Nous sommes sur la branche Master (la branche principale), et il y a un « Untracked file », c’est à dire un fichier non surveillé. Ce fichier n’est actuellement pas pris en compte par Git, nous allons donc l’ajouter. Pour cela, tapons git add README

Regardons à nouveau le statut de notre dossier :

Nous pouvons maintenant voir qu’il n’y a aucun fichier untracked, mais que des modifications sont en attente de commit : Nous avons créé un fichier, README.

Ajouter les fichiers modifiés et Comiter

Commitons donc les modifications apportées à notre projet. La commande utile ici est commit. Nous allons y ajouter le flag m, pour pouvoir mettre un petit message avec notre commit. Nous allons donc taper git commit -m « Creation du  readme »

Regardons le statut de notre dossier : Il n’y a plus rien à commiter.

Ouvrons notre README, et ajoutons y un peu de texte. Tapez dedans « Ceci est un projet pour essayer l’utilisation de git. »

Maintenant, le statut du dossier nous montre bien qu’un fichier a été modifié. Il ne nous reste plus qu’à l’ajouter au prochain commit, puis de commiter, comme la dernière fois. Pensez tout de même à mettre un autre message ^^.

Créer une branche sur Git

Git fonctionne avec un système de branches. Il est possible, quand l’on veut essayer quelque chose, de le séparer du reste dans une branche à part, pour que les modifications n’affectent pas le projet principal tant que nous ne l’avons pas décidé.

Pour voir toutes les branches de notre projet, la commande est git branch. Essayons !

Comme vous pouvez le voir, nous n’avons qu’une seule branche, « master ». Ajoutons donc une branche, que nous nommerons « testing », toujours avec la commande branch. Essayons git branch testing, puis regardons de nouveau nos branches.

Nous pouvons bien voir qu’une branche a été ajoutée, mais nous ne sommes pas dessus. Pour changer de branche, la commande est « checkout » suivi du nom d’une branche. Ici, git checkout testing

Si vous regardez la liste des branches, vous pouvez maintenant voir que l’astérisque (*) a changé de place. Nous sommes sur la branche testing.

Modifiez votre fichier README, puis commitez votre changement. Revenez sur la branche master, et regardez votre fichier. Vos modifications ne sont plus là, car elles ont été effectuées sur une autre branche !

Gérer les modifications sur Git

Modifiez encore une fois votre fichier README, mais sans commiter le résultat.

Maintenant, essayons d’imaginer que nous sommes sur un projet plus important, avec de nombreux fichiers. Nous avons fait plein de tests pour réussir à faire fonctionner la feature que nous voulions commiter, et nous y sommes enfin! Il ne nous reste plus qu’à faire un commit propre. Pour cela, nous regardons le statut de notre dossier, et voyons plusieurs fichiers modifiés. Nous nous rappelons de la plupart des modifications, mais certains fichiers (README par exemple) nous sont sorties de l’esprit.

Pour savoir ce que l’on a modifié depuis le dernier commit sur notre fichier README, la commande est diff. Essayons git diff README

Nous pouvons voir nos modifications. Une ligne a été enlevée, une autre ajoutée. (En réalité, j’ai simplement modifié une ligne, mais c’est comme ça que git gère les modifications de lignes).

Ma modification n’est pas bonne du tout, je ne compte pas la garder dans mon commit. Je vais donc faire revenir mon fichier README tel qu’il était au commit précédent. Pour cela, la commande est encore checkout.

Essayons git checkout README

Et voilà, mon fichier est redevenu correct, je vais pouvoir garder un dossier propre.

C’est bien de savoir gérer ses projets avec git, mais se limiter à ça serait triste. En effet, une des fonctionnalités centrale de git (et de tous versions manager) est de pouvoir travailler à plusieurs. Ce sera la leçon d’aujourd’hui.

La semaine dernière, nous avions vu comment manager son projet en séparant ses modifications en différents commits et branches. Nous avions obtenu un « projet » git simple, avec un simple fichier README, existant dans deux branches sous deux versions différentes. Nous allons réutiliser ça comme point de départ, pour apprendre 4 nouvelles commandes Git qui nous permettrons de travailler avec plusieurs dossiers, ou repositories (ou « repo » pour faire plus court).

Git – Travailler sur plusieurs repo

Git clone

Notre première commande nous permettra de dupliquer un repo. Elle se nomme, comme de juste, clone.

Positionnons nous (avec la console) dans le dossier dans lequel nous voulons créer notre nouveau dossier, et tapons la commande git clone /path/de/mon/premier/dossier nom_du_nouveau_dossier

Nous pouvons voir que notre dossier est bien cloné, que son historique est bien ici, et que le projet comprend une unique branche, master. Tiens, on avait pas plusieurs branches dans notre repo originel?

Bon, on avait donc plusieurs branches. Le truc, c’est que clone copie les branches, mais cache toutes les autres branches que master.git branche -a les révèle.

Pour travailler dessus, il faut qu’on annonce le demande explicitement, avec le flag b de checkout. La commande est git checkout -b branch_name branch/path

Et voilà, on a notre repo, et toutes les branches qui nous intéressent !

Git push et pull

Maintenant que nous avons nos deux repo, nous allons pouvoir travailler. Modifions le readme, et commitons. Nos deux repo sont maintenant différents. Pour synchroniser, nous avons deux choix. Il est possible de « pousser » les modifications du répertoire de destination au répertoire cible. Ou bien il est possible d’aller dans le répertoire cible et de « tirer » les modifications.

La commande pour pousser est push, suivi du repo cible et de la branche.

Attention : il est impossible de pousser sur la branche courante d’un repo. Faites bien attention, pour la prochaine étape, que le repo git-tutorial soit sur la branche master, vu que nous allons pousser sur testing.

Tapons donc git push origin testing.

Et voilà, notre branche distante est maintenant à jour ! Remettons nous sur la branche testing, puis remodifions le fichier README. Commitons, puis changeons d’endroit. Direction notre répertoire git-tutorial. De là, tapons git pull origin testing.

Ah, une erreur : la remote « origin » n’existe pas. Une remote est l’adresse d’un autre repo, et effectivement, nous ne l’avons pas créée. Nous allons le faire tout de suite avec la commande remote. Tappons git remote add origin /path/to/directory,puis réessayons le pull.

Voilà, Normalement ça passe et notre repo est a jour.

Si vous avez eu une erreur, c’est que votre repo n’est pas clean. Comprenez par là qu’il y a des changements non commités. Cela n’est bloquant que quand ces changements sont sur un des fichiers qui vas être modifié par le pull. Essayez donc de checkout ou de commit ces changements, puis réessayez.

Une dernière situation : et si les deux répertoires ont des modifications, comment fait-on pour synchroniser ? Pour commencer, modifiez les deux readme de manières différentes, en pensant bien à commiter. Les modifications doivent intervenir sur la même ligne, disons la première.

Pour synchroniser les deux repo, nous devons d’abord « merger » les deux repo sur un seul. Pour ça, il suffit de pull depuis un des deux repo. Les modifications apportées par les commit de l’autre repo seront appliquées sur le notre, et voilà. Si les fichiers modifiés sont différents, ou bien si les modifications d’un même fichier touchent des lignes différentes, le merge sera automatique, et rien ne vous sera demandé.

Par contre, ici, il vas y avoir un conflit, vu qu’on a modifié la première ligne de README sur les deux repo. Essayez de git pull origin master

Il y a bien un conflit. En cas d’oubli, nous pouvons le vérifier avec le statut du repo. Tapez git status, il y a un fichier dans « unmerged path ». Nous devons merger manuellement le fichier, puis le marque comme ok.

Pour ça, ouvrez le dans un éditeur de texte.

Notre version est dans « head », et l’autre est nommée par le commit qui l’a modifié. Il faut corriger le fichier, enregistrer, puis faire un git add sur le fichier incriminé pour que git sache que cette version est la bonne. Nous pouvons ensuite commiter le merge (notez que le message de validation renvoyé par la commande est merge et pas commit). Pour synchroniser l’autre repo, nous devons encore push nos modifications sur origin, comme tout à l’heure (pensez à faire attention à la version en cours de vos branches.

Voilà, nos deux repo sont a jour.

La semaine dernière, j’avais parlé de branches. Sachez qu’il est possible de merger deux branches avec la commande git merge. L’action se fait exactement de la même manière qu’en faisant un pull depuis une branche distante. Si tout va bien, le merge est automatique, sinon, il faut merger, avec la même technique que celle décrite précédemment.

Pour finir

Nous avons vu comment travailler avec deux dossiers, mais uniquement en local, ce qui n’est pas très utile pour collaborer dans la plupart des cas. Pour travailler à plusieurs, sachez que le chemin du repo d’en face peut très bien être distant, les informations passeront donc par ssh. Cette solution, bien que pratique car ne demandant pas d’installation, n’est pas ma préféré,car on se retrouve assez souvent avec des problèmes de droits quand on veut push, et qu’il faut faire attention a la branche courante. De plus, elle demande aux deux pc d’être allumés et connectés pour fonctionner.

Le mieux reste de passer par un server, que ce soit github, gitorious ou bien un gitosis hébergé sur un server personnel. Et ça tombe bien, ça sera la leçon de la semaine prochaine : Comment installer et configurer gitosis sur un server.

Pour aller plus loin, je vous conseille d’aller vous inscrire sur github et de lire leur documentation. En quelques minutes, vous aurez ouvert votre premier repo et pourrez push dessus.

Apprendre Git

Git pro

Git pro est un des livres de référence sur Git.  Il vous mènera vraiment très loin dans son utilisation. Sa version en ligne est gratuite, alors profitez en !

5 jeux pour apprendre Git

Git immersion

Un très bon tutoriel pour se familiariser avec git.

Le.git

Legit est un petit programme qui aliase quelques commandes un peu poilues de git en quelque chose de plus simple à retenir pour l’être humain moyen.

Héberger vos dépots Git

Il est possible de se passer complètement d’un serveur git, et de travailler uniquement avec divers repo, mais ce n’est pas très pratique dès que l’on travaille à plusieurs : si l’un des deux pc est éteint, on ne peut pas récupérer les données, on ne peut pas pousser sur la branche courante, ce genre de chose. De plus, la gestion des droits peut se retrouver assez problématique.

La solution simple est un serveur, qui va gérer les droits, et servir de dépôts toujours en ligne, et c’est ce que je vous propose ici.

Github

Vous devez tous connaître Github, maintenant. Dans le doute, petite présentation. Github est un site vous permettant d’héberger de manière gratuite vos dépôts open source. (Il existe des dépôts privés sur l’offre payante).

Plus que ça, il est agrémenté d’un aspect social très intéressant : suivez les projets qui vous intéressent, participez aux projets qui vous tiennent à coeur, remontez les bugs, et autre.

Il offre vraiment tout ce que l’on pourrait oser lui demander, voir même un peu plus : historique, code review, espace pour héberger un site présentant votre projet, recherche par langage des projets les plus intéressants du moment. Que vous soyez développeur ou intégrateur, il est nécessaire que vous connaissiez ce site !

Gitolite

Gitolite est un serveur git que l’on peut installer sur un serveur personnel, pour héberger ses propres dépôts. Très intéressant niveau fonctionnalités, pas très compliqué à installer et configurer, si vous avez besoin de répo privés en très grande quantité, c’est un bon choix.

le dépôt: https://github.com/sitaramc/gitolite

Gitlab

Gitlab est une interface graphique dédiée à Gitolite. Il permet de pouvoir explorer rapidement ses répo, sans avoir à les cloner pour faire une petite recherche dans le code. Très simple à installer et démarrer. 

Héberger et déployer son site

Heroku

Heroku est un hébergeur atypique possédant une offre d’hébergement gratuit. Sa particularité est qu’il fonctionne exclusivement avec Git. Pas de FTP ici, pas d’accès a phpmyadmin. Tout se passe avec Git: Créez votre dépôt avec une ligne de commande, puis poussez votre site sur le répository fourni. Voilà, votre site est en ligne ! Pas besoin de s’embêter avec un vhost, ou toutes ces choses.

Heroku accepte les applications rake, il peut donc vous permettre d’héberger une application sinatra ou rails.

Mina

Mina est un outil simplifiant le déploiement de vos sites : configurez l’adresse de votre serveur, le dossier, et les actions que vous voulez exécuter après avoir déployé (par exemple pour une application rails : migrate bundle redémarrer le serveur), et voilà. Il ne vous reste plus qu’à demander à mina de déployer votre site.

Pow

Pow est un outil parfait avec mina, car il permet de se passer de tout ce qui est vhost, configuration de serveur, tout ça. Il suffit d’ajouter son support dans mina, et nous nous retrouvons avec une structure aussi simple à déployer qu’avec Heroku. Ne fonctionne nativement que sous mac, mais il est possible de le faire fonctionner sous linux (jetez un coup d’oeil a la faq).

Octopress

Connaissez vous Jekyll ? C’est… disons un générateur de fichiers statique. Créez vos layouts, vos pages, et générez votre site.

Octoress est un blog basé sur Jekyll, qui se déploie avec Git. Ecrivez votre article en local (dans le train par exemple), puis quand vous voulez le publier, il suffit de pousser la modification avec git. Très simple à mettre en place, création de backup super simplifiée, très stable et demandant rien comme ressources (C’est du html après tout).

By Benjamin Sanchez

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *