This project is maintained by mariezufferey
activer la couleur dans git (aide la visibilité des messages dans la console)
git config --global color.diff auto
git config --global color.status auto
git config --global color.branch auto
configuration globale
git config --global user.name "marzuf"
git config --global user.email 'zuffereymarie0@gmail.com'
éditer le fichier de configuration
vim ~/.gitconfig
mkdir plusoumoins
cd plusoumoins
initialiser dépôt git
git init
git clone <...>.git
le dossier .git créé contient l’historique des modifications des fichiers et la configuration git pour ce projet au final la racine du dossier d’un projet contient la dernière version des fichiers du projet + le dossier .git où sont stockés l’historique et les fichiers de configuration
utiliser l’option –bare dans git clone ou git init -> ne créer qu’un fichier .git (sans les fichiers source, puisque ceux-ci ne sont pas modifiés sur le serveur)
pour indiquer les fichiers récemment modifiés:
git status
cycle “normal” de travail: modifier le code source -> tester les modifications -> valider les modifications avec un commit -> modifier le code source -> …
les commits sont là pour valider l’avancement d’un projet
pour voir ce qui a changé dans un fichier depuis le dernier commit:
git diff
-> les lignes ajoutées sont précédées d’un “+”; celles supprimées précédées d’un “-“ affiche les modifications de tous les fichiers pour voir les modifications d’un fichier en particulier:
git diff <nom_du_fichier>
il faut explicitement préciser les fichiers à “commiter”; 3 façons de le faire
1) ajouter les fichiers à commiter puis commiter
git add <nom_du_fichier1> <nom_du_fichier2>
git commit
-> est indispensable pour commiter des fichiers nouvellement créés
2) commiter tous les fichiers listés dans git status
git commit -a
-> utile pour commiter tous les fichiers d’un coup
3) indiquer lors du commit les fichiers à commiter
git commit nom_du_fichier1 nom_du_fichier2
-> utile pour commiter spécifiquement certains fichiers
après git commit -> l’éditeur s’ouvre et il faut saisir dans l’éditeur un message de commit le commit est local; l’envoi sur le serveur se fait séparément
=> ce sont l’historique des commits lorsqu’un commit a été effectué, se voit dans
git log
chaque commit est numéroté avec un long chiffre hexadécimal permettant de l’identifier
pour voir le détail des lignes ajoutées/retirées à chaque commit:
git log -p
pour un résumé plus court des commits
git log --stat
pour modifier le dernier message de commit (par ex. à cause d’une faut d’orthographe)
git commit --amend
l’éditeur s’ouvre et le message peut être modifié ! ne peut pas être modifié si le commit a été transmis à d’autres personnes
pour annuer le dernier commit (soft)
git reset HEAD^
-> annule le dernier commit et revient à l’avant-dernier -> seul le commit est retiré de git; les fichiers restent modifiés ! pour indiquer à quel commit revenir:
pour annuler le dernier commit (hard) -> annule le commit !et! les changements dans les fichiers:
git reset --hard HEAD^
-> annule le commit ET perd tous les changements !
pour annuler les modifications d’un fichier avant un commit (si plusieurs fichiers ont été modifiés mais que le commit n’a pas encore été envoyé, pour restaurer un fichier tel qu’il était au dernier commit):
git checkout <nomfichier>
-> le fichier revient le même tel qu’il était lors du dernier commit
annuler/supprimer un fichier avant un commit (par ex. un fichier ajouter avec git add, mais qu’on se rend compte qu’il ne faut pas le commiter, donc pour annuler le git add):
git reset HEAD -- <nom_du_fichier_a_supprimer>
-> retire le fichier qui avait été ajouté pour être commité
télécharger les modifications effectuées par d’autres personnes
git pull
2 cas de figure: 1) si aucune modification n’a été effectuée en local depuis le dernier pull, la mise à jour est simple (fast-forward) 2) si on a fait des commits en même temps, les changements sont fusionnés aux nôtres automatiquement si la même zone de code a été modifiée en même temps, git indique qu’il y a un conflit; git indique les noms des fichiers; il faut rechercher les lignes contenant les symboles “««««««««” qui délimitent nos changements et ceux des autres personnes et garder uniquement les changements nécessaires; puis faire un commit pour enregistrer tout cela.
recommandé de consulter le log local afin de vérifier ce qu’on s’apprête à envoyer
git log -p
pour passer à l’envoi
git push
le changement vers le serveur doit être de type fast-forward car le serveur ne peut pas gérer les conflits -> personne ne doit avoir fait un push avant nous depuis notre dernier pull (le mieux est de s’assurer d’être à jour en faisant un pull avant le push)
il est recommandé de faire des commits régulièrement mais pas des push (pas plus d’1x/jour en général) éviter de faire des push après chaque commit: on perd la facilité à annuler/modifier un commit
! un push est irréversible !
un commit erroné envoyé sur le serveur peut être annulé en créant un nouveau commit qui effectue l’inverse des modifications (un commit envoyé ne peut pas être supprimé, on ne peut que créer des nouveaux !) les lignes ajoutées seront supprimées et inversément
git revert <chiffre_hexa>
-> va annuler le commit avec l’ID
moyens de travailler en parallèle sur d’autres fonctionnalités (par ex. tester une copie du code source avec les idées plus folles et vérifier si cela fonctionne avant de les intégrer au véritable code source)
dans git, toutes les modifications faites au fil du temps par défaut considérées comme appartenant à la branche principale appelée “master”
si on veut tester quelque chose de spécial qu’on est pas sûr que cela va marcher et qu’on ne veut pas que le projet intègre ces changements dans l’immédiat -> créer une branche pour y travailler en parallèle
on peut faire des commits sur cette branche en particulier, cela n’empêche pas de continuer à travailler et faire des commits sur la branche master
si l’idée s’avère concluante à la fin, on peut fusionner tous les commits de la branche créée à la branche principale
git est unique dans sa capacité à gérer les branches (sans copies de fichiers); crée une branche virtuelle dans laquelle il retient tous les changements en parallèle; au moment de fusionner avec la branche master, vérifie que les modifications n’entrent pas en conflits avec les commits effectués en parallèle
gestion facilitée des branches par git encourage à créer des branches pour toutes les modifications qui pourraient prendre du temps avant d’être terminées
des sous-branches peuvent être créées à partir d’une branche
si les changements testés ne s’avèrent pas concluants par exemple, une (sous-)branche peut être supprimée sans qu’aucun commit intermédiaire ne soit finalement incorporé à la branche principale
pour voir toutes les branches:
git branch
l’étoile indique sur quelle branche on se trouve actuellement
question à se poser pour savoir si créer une branche: ma modification sera-t-elle rapide ? simple ? en combien de commits ? -> créer une branche pour chaque modification qui risque d’être un peu longue (au pire, on crée une branche “pour pas grand-chose”
créer une nouvelle branche ma_nouvelle_branche
git branch ma_nouvelle_branche
(pour le moment la branche est locale, non publiée)
pour voir la branche
git branch
pour le moment, on est toujours sur la branche master
pour aller sur la nouvelle branche:
git checkout ma_nouvelle_branche
! checkout a donc un double usage: i) pour restaurer un fichier tel qu’il était lors du dernier commit; ii) pour changer de branche
lors d’un changement de branche, on ne change pas de dossier sur le disque dur, mais git change les fichiers pour qu’ils reflètent l’état de la branche dans laquelle on se rend (les branches de git sont comme des dossiers virtuels) (on reste dans le même dossier, mais git modifie les fichiers qui ont changé entre la branche où l’on était et celle où on se rend) ainsi, si on fait un git log sur la branche ma_nouvelle_branche, les commits faits sur la branche master n’apparaissent pas
pour revenir sur la branche master
git checkout master
à la fin, on voudra sûrement fusionner une branche sur laquelle on a travaillé avec la master avec git, on peut fusionner n’importe quelle branche avec n’importe quelle autre branche (le plus courant reste de fusionner une branche de test dans une branche master) se rendre dans la branche maste, puis intégrer le travail fait dans l’autre branche
git checkout master
git merge ma_nouvelle_branche
(tous les commits faits dans ma_nouvelle_branche se retrouve maintenant dans la branche master) (on a pu travailler en parallèle, et maintenant seulement le travail s’applique sur la branche master)
la branche ne servant plus à rien, on peut la supprimer
git branch -d ma_nouvelle_branche
git vérifie que le travail dans ma_nouvelle_branche a bien été fusionné dans master; sinon il avertit et interdit la suppression
pour supprimer une branche même si elle contient des changements non fusionnés ! attention: tout le travail sera perdu
git branch -D ma_nouvelle_branche
avant de pouvoir changer de branche, il faut effectuer un commit de tous les changements (i.e. un git status doit afficher qu’aucun fichier est en cours de modification) si on a des changements non commités et qu’on change de branche, les fichiers modifiés restent comme ils étaient dans la nouvelle branche pour éviter d’avoir à faire un commit au milieu d’un travail en cours:
git stash
-> les fichiers modifiés sont sauvegardés et mis de côté git status n’affiche plus aucun fichier (le working directory est propre) on peut alors changer de branche, faire des modifications, commiter, et revenir sur la branche
git stash
git checkout master
()modifier des fichiers)
git commit -a
git checkout mabranche
pour récupérer les changements mis de côté
git stash apply
(les fichiers sont restaurés et retrouvent l’état dans lequel ils étaient avant git stash)
il est possible de travailler à plusieurs sur une branche (comme pour master) pour lister toutes les branches que le serveur connait:
git branch -r
origin/HEAD origin/master
origin = nom du serveur depuis lequel le dépôt a été cloné (en théorie on peut suivre directement les branches de plusieurs personnes ; git étant un peu comme le peer-to-peer; mais on travaille plutôt avec des serveurs pour suivre les changements) HEAD est un peu particulier master indique la branche principale
si le serveur possède une autre branche, e.g. origin/une_branche et qu’on veut travailler dessus, il faut créer une copie de la branche sur notre ordinateur pour suivre (tracker) les changements sur le serveur
git branch --track <branchelocale> origin/<brancheserveur>
e.g.
git branch --track une_branche origin/une_branche
lorsqu’on fera un pull depuis la branche une_branche, les changements seront fusionnés dans la branche une_branche locale ! important de savoir depuis où on fait un pull ! un pull depuis la branche master met à jour notre branche master locale en fonction de ce qui a changé sur le serveur, il en va de même pour n’importe quelle autre branche
pour ajouter une branche sur le serveur pour y travailler à plusieurs:
git push origin origin:refs/heads/nom_nouvelle_branche
on peut ensuite créer une branche locale qui suit la branche serveur comme vu précédemment avec git branch –track
l’inverse est également possible: on peut créer une branche locale puis la copier sur le serveur pour ce faire:
pour supprimer une branche sur le serveur:
git push origin :heads/nom_branche_a_supprimer
les “remote tracking branches” (celles qui apparaissent lorsqu’on fait git branch -r) ne seront pas automatiquement supprimés chez les autres clients; il faut les supprimer manuellement avec la commande
git branch -r -d origin/nom_branche_a_supprimer
donner un alias à un commit précis pour le référencer sous ce nom
git tag NOMTAG IDCOMMIT
e.g.
git tag v1.3 34j332209e
(permet à d’autres personnes de récupérer une version plus facilement)
un tag n’est pas envoyé lors d’un push, il faut préciser l’option -tags:
git push -tags
ainsi tout le monde peut se référencer à ce commit par le nom de tag plutôt que le numéro id
pour supprimer un tag créé:
git tag -d NOMTAG
git connait tous les fichiers source d’un projet; il est facile de faire une recherche à l’intérieur e.g. trouver tous les noms de fichiers qui contiennent le mot “TODO” dedans:
git grep "TODO"
(possible d’utiliser les expressions régulières)
pour connaitre les numéros de ligne qui contiennent le mot recherché
git grep -n "TODO"
pour ignorer un fichier: créer un fichier .gitignore à la racine et indiquer le nom du fichier (en entrant un nom de fichier par ligne) aucun de ces fichiers n’apparaitra dans git status, même s’il est modifié, et n’apparait pas dans les commits (utile e.g. pour les fichiers temporaires qui n’ont rien à faire dans git) (dans les noms de fichier on peut utiliser “” comme joker, e.g. “.tmp” pour ignorer tous les fichiers temporaires)
cf. le cours Pro Git https://git-scm.com/book/en/v2