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