Git Tutal

Git
Slides disponibles ici : http://delmaire.iiens.net/git

De Loïc Delmaire alias Skelz0r
@loicdelmaire / loic@blackbird.co

Objectifs (1/2)

  • Avoir des backups
  • Avoir un contrôle total sur les sources de votre projet
  • Pouvoir travailler à plusieurs de manière efficace
  • Pondre des sites webs efficacement et rapidement

Objectifs (2/2)

À la fin du cours, vous aurez codé un bot à plusieurs (aussi complet que le Balembot ! Trop cool!)

PROBLEM?
Utile hein ? :]
(© #balemboy)
OKI?

Petit interlude pour le projet

À chaque fois que vous verrez l'encadré suivant :

echo "COUCOU JE SUIS UN ENCADRÉ"
Il faudra taper le contenu de l'encadré en console

Gagnons du temps

ssh nom20XX@perso.iiens.net
source /home/users/2010/delmaire2010/git-tutal-install.sh

Cette ligne permet d'installer ruby sur votre perso
et d'autres trucs intéressants ;)

Plan du tutal

  1. Pourquoi Git ? Un pas!
  2. Vos premiers Un pas! avec Git
  3. Gestion des branches Un arbre!
  4. Gestion des remotes
  5. Aller plus loiiiiiiiiiin Une note!

I. Pourquoi Git ?

  1. Pourquoi versionnes-t-on nos sources ?
  2. Les différentes solutions
  3. Et git dans tout ça ?

Pourquoi versionne-t'on nos sources : les problématiques à résoudre

Comment en arrive-t'on à créer des outils de versionnement ?

  • Faire des backups régulièr(e)s
  • Développer de nouvelles fonctionnalitées
  • Faire contribuer d'autres personnes

Les deux grandes familles de SCM (Source Code Management)

  • Les SCM centralisés : toutes les sources sont centralisées sur un seul serveur, appelé dépôt.
  • Les SCM distribués : chaque copie fait office de dépôt.

Quelques logiciels connus

CVS
CVS (1990)
Subversion
Subversion (2000)
Mercurial
Mercurial (2005)
Bazaar
Bazaar (2005)

Une liste exhaustive sur wikipedia

Et Git dans tout ça ?

  • Développé pour maintenir le noyau Linux (2005) : rapidité et robustesse
  • Très efficace pour la gestion des branches
  • Caractère distribué du logiciel
  • Puissance des algorithmes et un bon gros tas (PHAT) de commandes utiles \o
Linus Torvald Linus Torvald, créateur du noyau Linux et de git

II. Vos premiers pas avec Git

  1. " Par quoi qu'on commenceeeee ? "
  2. Les commandes de base
  3. Premier enregistrement \o/
  4. Les différentes manières d'annuler des changements

Par quoi qu'on commenceeeee ?

  • git init : Initialise le versionnement de vos sources
  • git clone chemin : Permet de récupérer les sources d'un projet.

Du coup, pour le bot :

git clone https://github.com/Skizzk/GitTutalBot.git

Disons à Git qui on est :)

Histoire d'identifier les personnes travaillant sur un projet, git garde en mémoire certains identifiants :

git config --global user.name "Jean Kulain-Mhouton"
git config --global user.email "jean.kulain-mhouton@blackbird.co"

Les commandes de base

Git maintient à jour un index des fichiers : pour cela, toutes les manipulations s'effectuent via git :

  • git add * : ajoute tous les fichiers
  • git mv LOL OK : bouge le fichier LOL en OKI
  • git rm non.wav : supprime le fichier non.wav

Suivre l'évolution de nos sources

La commande permettant de suivre l'évolution de notre index est git status

Par exemple, sur notre projet, on obtient ceci :

$ git status
# On branch master
nothing to commit, working directory clean

... oki ...

WTF?
Joli l'index hein ?
$ git status
# On branch master
nothing to commit, working directory clean

Regadons ça de plus près quand même ..

Regardons plus en profondeur tout ça

Il y a 3 parties intéressantes dans un git status :

  • Les fichiers non-trackés
  • Les fichiers trackés et modifiés
  • Les nouveaux fichiers trackés (ou modifiés)

Sur le rendu d'avant, il n'y a aucun des trois () :
modifions un peu les sources du projet !

Les fichiers non-trackés

Un nouveau fichier est forcément un fichier non tracké!

touch seneque
On obtient :
# On branch master
# Untracked files:
# (use "git add ..." to include in what will be committed)
#
# seneque
nothing added to commit but untracked files present (use "git add" to track)

Les fichiers trackés et modifiés

echo "LOL" >> README.md
On obtient :
# On branch master
# Changes not staged for commit:
# (use "git add ..." to update what will be committed)
# (use "git checkout -- ..." to discard changes in working directory)
#
# modified: README.md
#
# Untracked files:
# (use "git add ..." to include in what will be committed)
#
# seneque
no changes added to commit (use "git add" and/or "git commit -a")

Les nouveaux fichiers trackés (ou modifiés)

touch tralala && git add tralala && git mv MOVEME DONTTOUCH
On obtient :
# On branch master
# Changes to be committed:
# (use "git reset HEAD ..." to unstage)
#
# renamed: MOVEME -> DONTTOUCH
# new file: tralala
#
# Changes not staged for commit:
# (use "git add ..." to update what will be committed)
# (use "git checkout -- ..." to discard changes in working directory)
#
# modified: README.md
#
# Untracked files:
# (use "git add ..." to include in what will be committed)
#
# seneque

Les différences avec la dernière validation

C'est bien beau de voir les fichiers qui ont changé, mais quid de ces modifications ?

git diff

On obtient :

diff --git a/README.md b/README.md
index bc199a5..1f9e612 100644
--- a/README.md
+++ b/README.md
@@ -1,4 +1,5 @@
GitTutalSlave
=============

-Slave for git tutorial
\ No newline at end of file
+Slave for git tutorial
+LOL

C'est l'heure du ... RE-RE-RE-RECORD!

Après avoir effectué des changements dans notre code, du style :

  • ajouté une fonctionnalité ;
  • fixé un bug ;
  • corrigé de la typo (LOL) ;

On peut enregistrer nos modifications à l'aide de la commande:
git commit

Les différentes façons d'effectuer notre commit

Un commit est toujours accompagné d'un message.
Voici différentes façons d'effectuer notre commit :

  • git commit : Ouvre un éditeur pour écrire le message
  • git commit -a : Ajoute tous les fichiers trackés dans le commit, et ouvre un éditeur
  • git commit -m "SCUMBAG GICLE" : Commit avec le message "SCUMBAG GICLE"

Quelques protips Deal with it pour commiter sans soucis

  • Vérifiez toujours les fichiers que vous validez (git status et git diff sont vos amis)
  • Commitez du code qui fonctionne (sinon vous allez payer des croissants!)

Du coup, validons nos magnifiques changements :

git commit -m "FIX typo (LOL)"

L'historique des commits

Pour consulter l'historique des enregistrements effectuées,
on utilise git log

git log
git log -p # Affiche l'historique avec les diff des fichiers
git log --name-only # Affiche l'historique avec les fichiers concernés
Un zôli schéma: Git log

Annuler des changements : les fichiers

Il existe plusieurs façons d'annuler des changements. Pour un fichier :

  • git checkout file : Restore le fichier à la dernière version valide
    echo "LOL" > README.md
    git status
    git checkout README.md
    git status

Annuler des changements : les commits (1/2)

On peut annuler des changements sur des commits entier :

  • git reset HEAD^ : Annule le dernier commit, sans modifier les fichiers
    echo "LOL" > README.md
    git status
    git checkout README.md
    git status

HEAD^ ...?

SRLY LÀ?

DAFUQ?

Petit explication du HEAD

Pour faire simple :

  • HEAD représente la dernière version valide de vos sources

  • HEAD^ représente l'avant dernière version valide
  • HEAD^^ représente l'avant-avant dernière version valide
  • Un écriture plus compréhensible : HEAD~3, pour remonter 3 commits en arrière.
Hey! C'est encore un zôli schéma DES TÊTES

Annuler des changements : les commits (2/2)

  • git reset --hard HEAD^ : Supprime le dernier commit, ainsi que les modifications
  • git commit --amend : Permet de modifier le dernier commit

Avant de continuer

Faisons un peu de ménache!

git reset --hard HEAD^

Histoire de supprimer le dernier commit .. douteux ;)

ERASE THEM ALL

La gestion des branches

  1. Intérêts et explications des branches
  2. Création des branches
  3. Manipulation des branches : le merge

Qu'est-ce qu'une branche ?

Un dessin c'est mieux, m'voyez ..

  • Une branche permet de développer en parallèle du code.
  • La branche principale (ie par défaut) est la master
  • Dans git, la gestion des branches est optimisée pour être très rapide!

Oki, cool .. à quoi ça sert ?

Les intérêts sont multiples :)

  • A développer de nouvelles fonctionnalités
  • A fixer des bugs
  • A générer de la documentation
  • A effectuer des changements majeurs dans le code
  • Et bien plus encore ! (limite, imagination, toussa quoi ..)

Création de branches

Pour créer une branche rien de plus simple :

git branch nom_de_la_branche

Pour lister les branches :

git branch

Pour se déplacer sur une branche :

git checkout nom_de_la_branche
git branch

Pour supprimer une branche :

git branch -d nom_de_la_branche

Stop bullshits now !

TIME2WORK!

Rendez-vous sur http://git-tutal.blackbird.co pour choisir une fonctionnalité à coder !

Manipulation des branches : le merge

Lorsque l'on a fini notre travail sur une branche, on veut la fusionner avec la branche principale.

Ceci est possible grace à un merge

La commande a effectuée depuis une branche b1, pour la merger avec une branche b2 : git merge b2

Un petit schéma ?

Admettons que nous soyons sur la branche master (M), et que l'on veuille merger la branche feature (F):

Avant le merge :
Avant le merge
Après le merge :
Avant le merge

Gestion des remotes

  1. Une remote ? Kezako ?
  2. Mise à jour des sources via les remotes

Une remote ? Kezako ?

Une remote
De rien :)

SRLY, une remote, c'est quoi ?

  • Une remote est un dépôt
  • Votre dépôt est donc une remote!
  • Le dépôt que vous avez cloné est aussi une remote : il s'agit de la remote origin (GIN)
git remote -v

Mise à jour des sources via les remotes

  • git pull : Mise à jour de ses sources locales
  • git push : Mise du dépôt origin avec la branche courante
Remotes ftw!

Un petit exemple pratique sur Github

Rendez-vous sur Github !
Inscrivez-vous ou connectez-vous, et crééz un nouveau repo

git remote add github adresse
git push github master

Aller plus loin

Merci d'avoir écouté :)

Des questions ?