Git
Pour les (pas si) nuls

Générique
Moi @malk_zameth
Chez @linagora
Licence CC-BY-SA 3.0
Trouvez slideshare.net/malk_zameth/git-
pres pour-les-pas-si-nuls
● The Friendly Manual
Sources ● Pro Git
● kernel.
org/pub/software/scm/git/docs/
gitworkflows.html
● rogerdudler.github.com/git-

Partie I: Intro

Qu'est-ce?

Contrôle de version (VCS)
Mais c'est quoi "contrôle de version"?

Gestion de l'information
dans le temps
c-a-d.?

Mémoire de ce qu'on a
fait
Un grand archive de copies donc?

Grand archive organisant
automatiquement
Je lui delegue la memoire de ce que mes fichiers on
été.

Distribué
Je controle mes versions en local et à distance (nul
maître)

Synchro fichier
remplaçant RSync

Transfert fichier
remplaçant ftp

Pourquoi utiliser un VCS?
Je gagne quoi moi?

Ne pas perdre le passé
Comme le "de-faire" et "re-faire" de mon editeur.
Mais pour toujours.

Visualiser le changement
Voire comment un fichier a changé, ce qu'a été fait.

Arreter de faire la même
chose a la main
le massacre des .old
les copies de dossier sous-le-coude

Avoir plusieurs versions
de vos idées qui co-
existent
c'est le cas dans votre tête déjà, mettez sur fichier!

Pourquoi utiliser un DVCS?
Quel gain d'un Git/Hg/Bz sur un SVN ?

“Aucun homme n'est une
île, un tout, complet en
soi”
Jhon Donne

Faciliter la collaboration
Je partage directement avec toi ce que nous avons en
commum.

Plus de commits en
pratique
Je peux commiter sans impacter personne, sans que ça
se voit, je peux editer/delester/regrouper mes
commits avant de publier : donc je le fait plus
souvent.

Decouple VCS de l'accès à
l'infra
Je commite dans l'avion, dans le train, pendant que
mon serveur est hors service.

Decouple VCS de
l'Existance de l'infra
Je peux utiliser sans jamais avoir un serveur quelque
part. Où avant qu'il soit prêt.

Pourquoi utiliser Git?
plutôt qu'un autre DVCS ?

Puissance
Plein (il faut admettre: trop), de fonctionalités.

Vitesse
Git et Hg sont les deux allucinants et personne les bat.

Simplicité
Ne pas confondre avec "faible courbe d'aprentissage".
C'est l'invèrse du jeu d'échecs.

Sécurisé
On peut utiliser/obliger les clefs SSH pour ecrire sur un
depot et/ou lire.

Devenu lingua franca
En 2009 persone m'aurait convaincu que j'écrirais ça un
jour

GitHub
Car le reseau social est une bonne idéee aussi pour le
travail.

Où utiliser Git?

Sur chaque fichier qui
sera édité.
Toujours.
Pas d'exceptions.

Quand utiliser git?

À chaque édition.
Toujours.
Pas d'exceptions.

Qui doit utiliser Git?

Cette présentation vise
deux publiques.

Tout être humain voulant
"chercher bonheur".
Vous éditez des fichiers? Continuons donc!

Tout être humain voulant
"gêrer des projets"
Vous produisez des fichiers en équipe? Continuons
donc!

Comment utiliser Git?

Partie II: Git tout seul
dans sa machine sans
connection
Oui ça vaut largement déjà le coup!

Il faut un client git
Trois parfums

Vous êtes dev?
Vous avez donc déjà un Environnement de Dev?

Intégrez Git a votre
Environnement!
Eclipse: Egit
Emacs: Magit
Vim: vim-fugitive
Sublime Text 2: sublime-text-2-git

Pas Dev; pas peur du
terminal?

La ligne de commande est
votre amie.
git tout court donc, dans toute sa puissance.

Et si j'ai peur du terminal?

Dans cette présentation je
vous prends par la main
et peut être après vous n'aurez plus peur.

Et si après j'ai toujours
peur du terminal?

git-cola
ou bien gitg, giggle, gitk+git-gui etc.

Pas à pas
pour apprendre git, il vaut mieux utiliser un peu

Créez un repertoire de
test
la où vous voulez, disons:
mkdir -p ~/git-test; cd ~/git-test

Créez un fichier de votre
choix
votre oeuvre litteraire a vous, un programme, disons:
echo "mon merveilleux fichier" > test.txt

git init
on dit a git "Interesse toi a ce répértoire et ces sous-
répértoires"

Nous avons maintenant un
.git
ls .git donne quoi?

HEAD
Libellé comme un autre.
point "le plus a jour", le "present" le "dernier commit".

git status
quel est ma situation actuelle?

Mon fichier n'est pas
encore pris en compte par
git!

git commit
J'ai fait des modifications/ajouts et veux que ils soient
pris en compte.

Erreur!
git connais pas le fichier.

Commit a deux étapes

d'abord on un indexe des
changements
on apelle ça "stage":
J'ai fait des changements, garde les dans le
colimateur, il a d'autres fortement associés que je dois
finir.

git add <nom du fichier>
disons git add test.txt.
notez que le message de git status change.

puis:
git commit
J'ai fini un sous ensemble de modifications qui sont
liés, je veux donner a eux une description.

On peut faire plusieurs
stage sur le même fichier

Et si le concept même de
stage ne me sert a rien?

git commit -a
ne m'embete pas avec le stage et commite mes
changements

A vous de jugez
il n'y a pas de "meilleure" manière, le stage est un outil
optionnel a utiliser ou a oublier.

Que contient le passé de
mon projet?

git log
les gros chiffres incomprehensibles? identifiants
uniques!

Messages de commit: fil
d'Arianne vers le passé

Qu'ai je fait moi dans ce
passé?

git log --author

Qu'a été fait depuis hier?

git log --since "yesterday"

memorisez le moins
possible

Notez les commandes qui
vous sont utiles
qui vous utilisez vraiment

donnez des noms a ces
commandes
de noms à vous, personnels que votre cerveau
souviendra

git config alias.<nom>
<commande>
git config alias.st status
git config alias.lg "log --pretty=oneline --abbrev-
commit --graph --decorate"
l'option --global les mets dans votre fichier de conf à
vous

Voir le passé

git show <version>:<nom
du fichier>
git show HEAD~3:test.txt

Voire les differences
entre les fichiers actuels
et HEAD

git diff

Entre l'actuel est un point
du passé

git diff <version>
git diff head~3

Entre deux points du
passé

git diff <version>..
<version>
git diff HEAD~3..HEAD~4

Comment Ré-écrire
l'histoire?

Je veux oublier des
changements

git reset <version>
Ne Jamais faire sur quelque chose qu'on publie. On ne
réecrit pas de l'histoire déjà racconté!

Je veux regrouper des
changements

git rebase -i <version>
Aussi a ne faire que si on a pas publié l'info.

Je oublier des
changements en indiquant
bien cela comme une
action

git revert <version a
oublier>

Petit commits frequents :
plus de souplesse et
pouvoir
on peut mieux choisir quoi reverter dans le futur
on peut toujours regrouper des petits commits dans un
seul plus grand (squash)

les numero de version
unique sont indigestes
Je veux donner un nom a une version spécifique

git tag <nom de la
version>
git tag 1.0
git tag publiee_dans_la_newsletter_octobre_2012

Je veux travailler avec
plusieurs visions du même
document
au même temps

les branches

git branch <branche>
fait la creation de la branche, a partir de HEAD
Ne va PAS a la branche

git checkout <branche>
change de branche, va la branche choisie

cela prête à confusion
On peut un jur creer une branche et oublier de
changer vers elle, faire des bêtises!

git checkout -b <branche>
fait la creation de la branche et immediatement
change de branche (faites en un alias, utilisez toujours
comme ça)

Consolider des branches
en une seule

git merge <branche a
merger sur l'actuelle>

pas envie de garder la
branche?

git branch -d <branche a
effacer>
on a pas besoin de griller des neurones a inventer de
tres bons nos pour des branches temporaires qu'on
effacera juste après

On a toujours une
branche
celle par defaut s'apelle master

Utilisez de branches!

Utilisez-les souvent!
avant de demarrer chaque nouvelle direction dans les
fichier du projet; chaque nouvelle idée; chaque
nouvelle demande.

Pourquoi?

Jongle entre une version
connue et celle en cours
très vite

idées et experimentations
dans un coin prévu.

gestion de version
sur les idées
que je peux, finalement, abandoner sans rien toucher
de mon historique

J'évite une infinité de
problèmes.
99% des fois que j'aide quelqu'un avec un "problème"
sur git: le problème n'aurait jamais existé si la
personne au depart de son changement avait crée une
branche!

Partie III : Git avec des
remotes
"serveurs distants"

prendre une copie d'un
depot distant
elle deviendra locale, une reference au depot distant
sera faite sur le nom par defaut origin

git clone <url du depot>
git clone https://github.com/malk/git-playback.git

ajouter un remote
pour les même projet on peut avoir beaucoup
genre un du client, un pour chaque collaborateur, etc.

git remote add <nom>
<url>
git remote add mmozuras https://github.
com/mmozuras/git-playback.git

On a nos remotes

prendre les changements
distants
copies à coté, mes fichiers ne changent pas

git fetch <remote>
<branche>
git fetch mmozuras master

Incorporer des
changements distants
déjà récupérés par un fetch

On sait déjà faire ça!
c'est une branche comme une autre!

On fait un merge!

git merge origin/master
je merge la branche master dans origin ( origin/master
) dans ma branche actuelle (je choisit l'actuelle avec
un checkout)

On ne merge que la
version déjà "fetché"
si on oublie le fetch on merge une version peut etre
déjà vieille

Confusion possible
comment éviter?

git pull <remote>
<branche>
git pull origin master
fait un fetch puis un merge: plus d'oubli.

Incorporer changements
locaux dans branche
distante
Si nous avons les permissions!

git push <remote>
<branche>
git push --tags origin master
l'option tags fait un push des tags créees aussi

Avant tout push
● Un petit git status
○ Suis-je au bon endroit? sinon checkout.
○ Il manque quelquechose a comitter? on ne push que
HEAD!
● Je fait un pull de la branche distante
● J'incorpore tout, événtuel, changement
● resout tout, éventuel, conflit: les
commiter.
● C'est bon je peux "pusher".
Suivez cette checklist
ça vous évitera des soucis!

Partie IV : Gestion de
projet
On doit produire de choses ensemble: évitons le chaos

Workflow

Processus de travail
Comment j'enchaine les diverses étapes de travail pour
produire.

Plusieurs VCS contrainent
ou forcent un workflow

Git permet une infinité
un aperçu kernel.
org/pub/software/scm/git/docs/gitworkflows.html

Dont plusieurs
incompatibles!

Si vous ne choisissez pas
un workflow pour vous

Vous avez un sans se
rendre compte,
naturellement
Ou peut être plusieurs!

Si vous ne choisissez pas
un pour votre équipe

Vous avez surement déjà
plusieurs!
J'espere qu'ils soient tous compatibles! La chance!

Cela peut engendrer dès
problèmes

Trouvez donc un
workflow!
Deux bonnes heures bien investies!
Je peux vous aider au pire.

Definissez les phases de
vie de votre production
Création? Consolidation? mise en prod? hotfix? quoi
d'autre?
Tout ça ça deviens de branches.

Definissez les intercations
entre ces phases
et transformez-les en alias/script git avec des noms
qu'ont un sens pour votre équipe.

Et vous aurez un workflow
mon point de départ favori:
http://nvie.com/posts/a-successful-git-branching-
model/

Quel commit a inséré ce
bug?

git bisect
on declare des versions comme ayant ou pas le bug (on
teste a chaque fois) et par dichotomie ils nous aide a
retrouver la version qu'a inseré le bug

Qui a inseré cette ligne
dans le fichier?

git blame
Donne auteur par ligne (--L pour limiter les lignes)

Où a-t-on écrit tel truc?
Entre mes fichiers au sein d'un projet?

git grep
comme grep, mais dans l'arbre de fichiers controlé par
git

Voire l'effet des commits
de quelqu'un comme un
slideshow de son travail

git playback
https://github.com/mmozuras/git-playback
génère un fichier html avec un tel slideshow

Aprendre git a resoudre
un conflit d'une manière
comme on a déjà fait
avant
l'apprendre a suivre nos habitudes et donc économiser
du temps.

git ReReRe
faut d'abord activer
git config --global rerere.enabled 1
après ça la commande marche

ouvrir un serveur http
tournant une page en
navigation de
l'arborescence d'un depot
git

git instaweb
(j'avais dit: trop ;)

Devenir un pro du git