Git introduction

1. Git
Pour les (pas si) nuls

2. 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-

3. Partie I: Intro

4. Qu'est-ce?

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

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

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

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

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

10. Synchro fichier
remplaçant RSync

11. Transfert fichier
remplaçant ftp

12. Pourquoi utiliser un VCS?
Je gagne quoi moi?

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

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

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

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

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

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

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

20. 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.

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

22. 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.

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

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

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

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

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

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

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

30. Où utiliser Git?

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

32. Quand utiliser git?

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

34. Qui doit utiliser Git?

35. Cette présentation vise
deux publiques.

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

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

38. Comment utiliser Git?

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

40. Il faut un client git
Trois parfums

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

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

43. Pas Dev; pas peur du
terminal?

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

45. Et si j'ai peur du terminal?

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

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

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

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

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

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

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

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

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

55. git status
quel est ma situation actuelle?

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

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

58. Erreur!
git connais pas le fichier.

59. Commit a deux étapes

60. 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.

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

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

63. On peut faire plusieurs
stage sur le même fichier

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

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

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

67. Que contient le passé de
mon projet?

68. git log
les gros chiffres incomprehensibles? identifiants
uniques!

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

70. Qu'ai je fait moi dans ce
passé?

71. git log --author

72. Qu'a été fait depuis hier?

73. git log --since "yesterday"

74. memorisez le moins
possible

75. Notez les commandes qui
vous sont utiles
qui vous utilisez vraiment

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

77. 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

78. Voir le passé

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

80. Voire les differences
entre les fichiers actuels
et HEAD

81. git diff

82. Entre l'actuel est un point
du passé

83. git diff <version>
git diff head~3

84. Entre deux points du
passé

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

86. Comment Ré-écrire
l'histoire?

87. Je veux oublier des
changements

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

89. Je veux regrouper des
changements

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

91. Je oublier des
changements en indiquant
bien cela comme une
action

92. git revert <version a
oublier>

93. 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)

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

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

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

97. les branches

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

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

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

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

102. Consolider des branches
en une seule

103. git merge <branche a
merger sur l'actuelle>

104. pas envie de garder la
branche?

105. 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

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

107. Utilisez de branches!

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

109. Pourquoi?

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

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

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

113. 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!

114. Partie III : Git avec des
remotes
"serveurs distants"

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

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

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

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

119. On a nos remotes

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

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

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

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

124. On fait un merge!

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

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

127. Confusion possible
comment éviter?

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

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

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

131. 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!

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

133. Workflow

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

135. Plusieurs VCS contrainent
ou forcent un workflow

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

137. Dont plusieurs
incompatibles!

138. Si vous ne choisissez pas
un workflow pour vous

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

140. Si vous ne choisissez pas
un pour votre équipe

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

142. Cela peut engendrer dès
problèmes

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

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

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

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

147. Quel commit a inséré ce
bug?

148. 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

149. Qui a inseré cette ligne
dans le fichier?

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

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

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

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

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

155. 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.

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

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

158. git instaweb
(j'avais dit: trop ;)

159. Devenir un pro du git