Réchèr
Dresseur de pythons / Grand marabout
2016-12-32
ConcreteWorld. - afterwork d'humagogie #2
Lors du visionnage public de cette présentation, les gens se sont endormis et/ou sont devenus fous.
Je décline toute responsabilité.
Conserver un historique de ses fichiers (quel que soit leur type).
Savoir qui a modifié quoi et quand.
Savoir où est la dernière version d'un fichier
Fichier d'install : https://git-scm.com/
Fonctionne sous Windows, Mac, ...
Licence libre : GNU GPL (Comme Linux)
Git fonctionne en ligne de commande uniquement.
Des interfaces graphiques facilitent son utilisation.
SourceTree
TortoiseGit
etc.
.
Le repository contient au départ une seule branche, appelée master.
Pas besoin de se soucier de git durant son travail.
Une modification sur un fichier peut être dans 3 états :
Unstaged : non prise en compte
Staged : prête à être historisée
Committed : historisée
Dans le message de description, la première ligne résume très rapidement le commit, les lignes suivantes (facultatives) donnent des détails.
Pas la peine de lister les fichiers modifiés ou de décrire au caractère près les modifications effectuées. On peut retrouver ces informations automatiquement.
Un commit peut modifier plusieurs fichiers, mais il ne doit faire "qu'une seule chose".
Même fonctionnement.
Mais l'affichage des différences est inexploitable.
L'action checkout permet de se repositionner sur un ancien commit et de remettre les fichiers dans l'état où ils étaient.
Tout est dans le répertoire .git.
Seules les différences d'un commit à l'autre sont stockées. Ce qui permet d'économiser de la place.
Il s'agit du mode après avoir effectué un checkout sur un ancien commit.
Le repository sert uniquement au stockage.
On ne peut pas travailler directement dessus (pas de commits).
Le clonage crée un lien entre le repository original et sa copie.
On pourra ensuite les synchroniser entre eux, avec les actions push et pull.
Lorsqu'on travaille à plusieurs sur un même repository, chacun doit créer ses branches.
On ne fait pas de commit dans la branche master.
Une branch = un pointeur sur un commit particulier, permettant de faire évoluer le contenu différement.
Lors d'un checkout sur une branche :
Push = envoyer les commits de ses branches au repository central.
Pull = récupérer les branches du repository central.
Le pull crée des nouvelles branches dans le repository local. Mais ce sont des branches "distantes".
Lors d'un pull, la branche locale courante avance jusqu'à sa branche distante.
Merge = rassembler deux branches pour cumuler leurs commits.
Ça peut se passer bien ou mal.
Si plusieurs personnes travaillent sur la même branche, le risque est présent à chaque pull.
Avec les branches, ce risque est transféré sur les merges.
Conflit = modification d'un même fichier, au même endroit, dans deux branches différentes.
Pour résoudre un conflit, il faut décider du contenu final du fichier.
Le merge est effectué lorsque tous les conflits sont résolus.
Tag = une étiquette sur un commit.
Ils permettent de repérer les versions livrées, celles en cours de test, ...
Un commit doit être vu comme une action anodine. Son absence de bug n'a pas à être garantie.
Un tag est moins anodin. C'est une preuve de l'exécution de tests de validation.
Le repository central est sur un site qui le rend disponible à tous :
GitHub, GitLab, FramaGit, ...
Méthode :
Lors du choix d'un logiciel, il est important de s'assurer qu'il comporte des moyens d'échange simple et atomique avec l'extérieur :
ligne de commande, api web, fichiers d'import/export, ...
Vous ne vous servirez pas forcément de ces moyens d'échange.
Mais vous avez besoin qu'ils existent.
D'autres personnes vont utiliser ces moyens pour développer des outils qui pourrons vous être utiles.