GIT vise à satisfaire 3 besoins distincts, et son utilisation peut être rentable même si on n'est pas concerné par les 3:
Les modifications sont non-destructives
L'historique permet de revenir en arrière si nécessaire
L'historique peut comporter des bifurcations, des lignes temporelles parallèles
Cette fonctionnalité fonctionne en mode local
La gestion de version protège contre les erreurs de codage, mais pas contre les incidents matériels (crash, vol, catastrophe)
La sauvegarde sur un serveur distant (ou plusieurs) vient en complément
La redondance est gérée
En plus les serveurs GIT offrent une visualisation de l'historique sur une interface web
le travail de chaque collaborateur est protégé, les contribution sont non-destructives
chaque collaborateur possède une copie locale du projet
Certains fournisseurs mettent à disposition un service gratuit de serveur GIT, par exemple :
l'ensemble peut être copié, deplacé, synchronisé (dropbox, drive), archivé de maniere classique (tar,zip)
le répertoire .git contient l'historique du projet sous forme codée et comprimée
le répertoire .git exclu bien sûr
on peut exclure de la gestion les répertoire et fichiers temporaires (listés dans le fichier .gitignore)
un repo peut être associé à plusieurs remotes
l'URL du remote indique le protocole utilisé (https ou ssh ou autre)
origin est l'identifiant donné au serveur par la commande git clone
un commit pointe sur au moins un commit précédent, son ancêtre
on peut désigner un commit par un hash abrégé (min 5 premiers digits), un tag ou une branche
(Note : to commit signifie "confier, remettre")
Un commit ne peut jamais être modifié, ni supprimé (sauf le plus récent de la branche)
les commandes git add et git commit -a garnissent le stage
la commande git status permet de voir ce qui est ou pas dans le stage
les tags servent à repérer les releases sous github
la branche active au moment de commettre un commit va accompagner ce commit, les autres branches restent à leur place
la commande git init crée une branche de départ nommée master
les commandes suivantes déplacent HEAD : git commit, git checkout,
git merge, git pull
on est en mode detached HEAD si HEAD pointe seulement sur un commit (pas de branch active)
alors si on fait un nouveau commit on crée une bifurcation anonyme
Les commandes suivantes servent à créer un repository local
Cette commande va configurer le répertoire courant comme repository
cela va se concrétiser par la création d'un répertoire .git
Exemple : git clone http://github.com/user_name/repo
Le repository va être créé sous forme d'un sous-répertoire du répertoire courant
Toutes les autres commandes fonctionnent à condition que le répertoire courant soit un repository GIT
Exemple : git help branch donne le manuel de la commande git branch
Cette commande permet de savoir quels éléments ont changé depuis le dernier commit, et s'ils sont sur le stage ou non.
Cette commande permet de vérifier le résultat de git add.
Liste chronologique, le commit le plus récent en premier
git log --oneline --all --graph donne une ligne par commit
Recommandé: alias gitlog='git log --oneline --all --graph' dans votre .bashrc
git diff compare le working-tree avec le dernier commit
git diff <older_commit> <newer_commit> compare deux commits
Ajouter un nouveau fichier ou répertoire sur le stage, en vue du prochain commit
Si on nomme un répertoire, tout son contenu est ajouté.
N.B. Dans beaucoup de commandes GIT, le caractère * est supporté comme wildcard, mais son interprétation (globbing)
est différente de celle du shell.
Exemple : git add '*.c'
ajoute tous les fichiers .c du working tree
Notez le rôle des quotes qui empêchent l'interprétation de * par le shell.
Le fichier est renommé ou déplacé en local, et aussi dans l'historique s'il est déjà suivi, en vue du prochain commit
N.B. si on déplace ou renomme un fichier avec une commande de l'OS, l'historique risque de perdre sa trace et ne
plus le suivre.
Le fichier est supprimé en local, et son suivi prend fin.
L'option --cached permet de mettre fin au suivi d'un fichier, sans le détruire localement
(c'est l'inverse de git add).
Exemple : git commit -am "je decris la modif"
l'option -a remet automatiquement sur le stage les éléments qui y étaient au commit précedent
l'option -m permet de mettre un commentaire dans la ligne de commande
(sans cette option, GIT ouvre automatiquement l'éditeur de texte local)
Cette commande prend un commit comme argument. Elle fait 2 choses :
Comme toutes les commandes qui prennent un commit comme argument, cette commande accepte aussi une branche ou un tag.
Attention: pour que cette reconstitution fonctionne correctement il faut que la base de donnée soit à jour
(qu'il n'existe aucun changement non commité), dans le cas contraire on peut avoir un refus.
Alors on peut utiliser la dangereuse option -f, ce qui implique qu'on accepte perdre les changements non-commités.
Le checkout peut aussi échouer en cas de disparition intempestive d'un ou plusieurs fichiers (ce qui est assimilé à un changement non commité),
alors on peut forcer la restitution des fichiers perdus en ajoutant leur nom à la ligne de commande, ou le joker '*'.
Cette commande prend un nom de fichier comme argument. Elle reconstitue le fichier tel qu'il était au moment du dernier commit, même s'il a disparu
Attention: tout comme l'option -f, cette commande implique qu'on accepte perdre les changements non-commités.
Variantes:
Le tag est une étiquette qui est appliquée au dernier commit
Exemple : git tag 'V 2.011a'
Exemple :
git branch alpha
git checkout alpha
La première commande a mis une étiquette 'alpha' sur le dernier commit, la seconde a fait pointer HEAD sur
la branche alpha (sans changer de commit). Les prochains commits constitueront la branche 'alpha'.
(l'ancienne branche reste sur place, jusqu'à ce qu'on lui fasse un checkout)
Exemple : git merge alpha va incorporer le contenu de la branche alpha dans
la branche courante
Si tout va bien cela crée un nouveau commit qui a 2 ancêtres.
Sinon, en cas de conflit, l'opération est suspendue et l'utilisateur est alors invité a éditer
manuellement chaque fichier en situation conflictuelle, puis à faire un commit qui va conclure le merge
La configuration éditable réside dans 2 fichiers :
liste toutes les valeurs actives (globales et locales)
L'option --global agit sur la configuration globale, sinon c'est local.
Exemples :
git config --global user.name <mon_nom>
git config --global user.email <mon_email>
N.B. si vous utilisez github ou un service similaire, mettez le même nom et le même email
que dans votre compte github, surtout si vous contribuez sur le compte d'un autre.
Exemple :
git remote add origin https://github.com/my_name/my_repo
Exemples :
git push met à jour la branche courante
git push -u origin my_branch requis si on a changé de branche
git push --all met à jour toutes les branches
git push --tags met à jour les tags, seulement les tags
N.B. le serveur exige une authentification pour vous autoriser à modifier le repository distant.
Si vous n'êtes pas propriétaire du repo distant, il faut que vous soyez enregistré comme collaborateur de ce repo.
Les éléments d'authentification (credentials) peuvent être mémorisé sur votre poste de travail, d'une manière qui diffère selon
le système d'exploitation.
Si le repo distant a été modifié depuis votre dernier push ou pull (par quelqu'un d'autre ou par vous-même sur un autre poste de travail),
le serveur va refuser le push et vous demander d'effectuer d'abord un git pull qui va inclure un
merge. Alors vous pourrez réiterer votre git push .
Si le repo distant a été modifié depuis votre dernier push ou pull (par quelqu'un d'autre ou par vous-même sur un autre poste de travail), la commande git pull va devoir effectuer un merge, qui peut réussir immédiatement ou nécessiter une intervention manuelle, tout comme le merge local.