This project is maintained by mariezufferey
git config <>
peut être utilisée depuis n’importe quel répertoire
git config --global <>
indique que ce sont les valeurs par défaut pour tous les projets de l’ordinateur
le nom et l’adresse (git config –global user.name et git config –global user.email) sont utilisés pour attribuer les commits (tant que les commits n’ont pas été poussés vers un serveur, les informations restent locales)
créer un nouveau projet
git init
cloner un projet existant
git clone <>
-> crée un nouveau répertoire (portant le nom du repository présent sur le serveur) -> intialise un nouveau repository git -> ajoute un serveur distant appelé origin -> extrait les modifications de ce serveur distant (pour utiliser un autre nom de répertoire, un autre nom de dossier peut être passé à la commande git clone
git clone <adresse serveur> <nouveau nom>
le clone créé contient tout l’historique du repository, y.c. toutes les modifications partagées par toutes les autres copies
importance des commits: organisation et gestion de notre travail par git est axé sur les commits les commits sont un type de données git appelé objet (un type parmi d’autres d’objets) chaque information connue par git est stockée sous forme d’objet et chaque objet possède un nom unique dérivé de son contenu chaque commit représente un snapshot complet de l’état du projet à un moment donné git procède par additions: les commits sont toujours ajoutés
git status
permet de savoir l’état du projet
pour pouvoir commiter un fichier, celui-ci doit être suivi (distinction entre l’ajout et le commit) le commit enregistre les modifications apportées aux fichiers figurant dans la base de données de git
git add <>
prend un snapshot du fichier et l’enregistre dans le repository pour qu’il soit référençable ultérieurement dans un commit
pour commiter le fichier:
git commit --message "premier comit"
ou plus court:
git commit -m "premier commit"
avant de commiter, il faut ajouter avec git add -> indexation zone d’indexation = là où se trouvent les nouvelles versions, entre le moment où les fichiers sont mis à jour et le moment où ils sont commités; est locale sur notre ordinateur (ni synchronisée, ni partagée) 2 effets de l’indexation 1) git fournit un snapshot du fichier à sa base de données afin de pouvoir y référence lors du prochain commit 2) git démarre une ébauche locale du prochain commit en référençant tous les fichiers et répertoires contenus dans le dossier (un commit est autonome: ne réfèrence pas seulement ce qui a changé, mais tout ce qui compose l’état du projet)
supprimer des fichiers si on supprime un fichier de la copie de travail d’un projet, il faut la retirer du repository rappel: git est un système d’accumulation; git ne se soucie des changements que dans le contexte d’un commit
git rm mon_fichier
-> git crée un nouveau snapshot du projet sans mon_fichier et indexe cette version comme la prochaine à commiter il faut donc après procéder au commit
git commit -m "suppression mon_fichier"
si on renomme un fichier, git indiquera que le fichier avec le nom initial a été supprimé et qu’il y a un nouveau fichier avec le nouveau nom qui n’est pas suivi si on renomme mon_fichier en mon_nouveau_fichier, la commande
git mv mon_fichier mon_nouveau_fichier
ne fonctionnera pas (il aurait fallu l’utiliser avant de renommer le fichier) en ayant renommé le fichier, git reconnait deux changements non commités: une suppression (de mon_fichier) et un ajout (de mon_nouveau_fichier) pour mettre fin a suivi de mon_fichier
git rm mon_fichier
suivre le fichier sous son nouveau nom
git add mon_nouveau_fichier
le même résultat aurait pu être obtenu en utilisant git mv dès le départ
pour ajouter directement tout ce qui a changé dans notre copie locale:
git add --all
ou
git add -A
gestion de versions séqentielles: chaque commit inclut une référence à la précédente (commit parent)
une branche est une copie virtuelle du projet (un projet dans le projet) où on peut commiter librement des opérations de façon isolée par rapport au reste du repository, séparément de la branche master
chaque repository commence avec une branche principale (master); est une branche comme les autres si ce n’est son rôle de version primaire, stable du projet
lister toutes les branches du repository local
git branch
en coulisse, une branche n’est rien de plus qu’un surnom lisible pointant vers un commit particulier (branche est une pile de commits)
si on veut travailler sur une partie du projet qui prendra du temps et beaucoup de commits -> créer une nouvelle branche (branche thématique ou branche de travail) pour créer nouvelle branche
git branch nom_nouvelle_branche
(le commit en cours est utilisé comme point de départ; la nouvelle branche démarre avec à sa tête le commit qui était en tête de la branche master) (les deux branches n’ont aucun lien excepté qu’elles partagent ce commit) après l’exécution de cette commande, master reste la branche en cours
l’extraction d’une branche a 2 effets: 1) réinitialise la copie de travail qui devient le reflet du commit de tête de la branche 2) définit la branche choisie comme branche actuelle, de sorte que chaque nouveau commit sera ajouté à la branche en question
pour changer de branche
git checkout nom_nouvelle_branche
raccourci: création et changement de branche peut se faire en une commande
git checkout -b nom_nouvelle_branche
après cela la nouvelle branche devrait être visible en tapant
git branch
(l’astérisque indique la branche en cours)
même s’ils sont parfaitement identiques pour le moment (le commit de tête des deux branches - ainsi que tous les précédents - est le même), les deux objets sont distincts
après avoir extrait la branche nom_nouvelle_branche, tout ce qu’on fait appartient à cette branche thématique et ne figurera pas dans la branche master
git commit -am "mon commit"
pour combiner l’ajout automatique de tous les fichiers et préciser un message de commit (une seule option peut prendre un argument et doit être placée en dernier)
git crée le commit et déplace le pointeur de la branche en cours vers le commit qui vient d’être effectué (lorsqu’on ajoute un commit à une branche, le nouveau commit remplace le précédent en tête de la branche)
c’est sur le commit de tête de la branche que se base le prochain commit
si on travaille sur des branches en parallèle, toutes les modifications apportées sur une branche sont isolées de celles faites sur l’autre
en principe, le nom de la branche doit donner un description logique de sa raison d’être
une branche peut simplement être un lieu d’expérimentations jetables mais la plupart du temps on veut ensuite l’intégrer à la copie principale comme en principe master continue d’évoluer de son côté, il faudra synchroniser ces modifications avec celles de la branche -> fusionner les deux versions extraire la branche master dans la copie locale (branche extraite = la branche en cours) git checkout master insérer les modifications de l’autre branche dans la copie de master
git merge ma_branche
la version master contient maintenant tout ce qui s’y trouvait plus les modifications apportées dans la branche ma_branche
le résultat d’un merge est un commit (chaque commit représente un snapshot complet du projet)
un merge fast-forward est le type le plus simple et le plus facile après un merge fast-forward, les 2 branches pointent vers le même commit et deviennent à nouveau identiques à tous égards (à l’exception de leur nom) les fast-forward sont réservés aux cas où seule une des deux branches présente de nouveaux commits
dans les autres cas, git détermine quel doit être l’état combiné du projet, crée un snapshot représentant cette nouvelle version fusionnée puis ajoute un commit d’un type spécifique (merge commit) pour finir l’opération (git compare les fichiers modifiés dans les deux branches et s’il n’y a pas de modifications à la même ligne, peut les fusionner)
il est possible de demander à git de gérer et indexer la version fusionnée mais de ne pas la commiter avec
git merge -- no-commit nom_branche
(peut être utile si on veut ajouter un message de commit)
les merge commits présentent quelques caractéristiques particulières, par ex. ils peuvent avoir plus d’un seul parent
maintenir des branches avec une durée de vie courte avant de les fusionner à master réduit les risques de conflits de fusion et facilite le merge final
il est recommandé de fusionner les nouveaux commits apportés à master dans la branche afin de maintenir cette dernière à jour en rentrant (depuis notre branche)
git merge master
les conflits de fusion apparaissent le plus souvent quand 2 lignes d’un merge se superposent i.e. quand deux versions différentes tentent de modifier simultanément la même ligne d’un même fichier dans ces cas-là git demande de terminer nous-même le merge commit
en cas de conflit, les fichiers qui ont été modifiés et qui ne posent pas de problème sont automatiquement ajoutés à la zone d’indexation; pour ceux qui posent problème, il faut examiner les différences et sélectionner manuellement à cette fin, git remplit chaque fichier conflictuel d’annotations “marqueurs de conflit”; il faut les examiner unes à unes en substituant au text annoté la version à obtenir après le merge (conflits signalés par des lignes de chevrons)
une fois le fichier conflictuel modifié manuellement, il faut l’ajouter à la zone d’indexation (git add nom_fichier) et le commité (git commit -m “”) séparément le conflit pourrait être résolu en modifiant le fichier de façon à ce qu’il ne ressemble à aucune des versions conflictuelles la version du fichier qui est indexée au moment du dernier commit et celle qui “remporte” le merge
! accidentellement, un fichier plein de marqueurs de conflit pourrait être archivé !
en fusionnant régulièrement dans la branche master les conflits peuvent souvent être évités les fusions fréquentes permettent aux branches de rester à jour les unes par rapport aux autres et les rendent plus faciles à gérer en limitant les différences
un repository distant est une copie d’un projet git qui se trouve ailleurs contrairement aux branches qui sont pour l’essentiel des copies virtuelles du projet chaque repository distant correspond à une copie réelle et physique du repository les repositories distants ne sont que des instances du projet stockées dans un endroit accessible permettant d’y pousser ou d’en tirer des commits
les repositories côté serveur sont des repositories “vierges”: ils comprennent uniquement les données réelles du repository (versions précédentes, branches), sans aucune copie de travail (et donc sans zone d’indexation) un repository git vierge est déisgné en ajoutant .git à son nom (l’architecture interne est similaire au .git de notre répertoire local de travail) côté serveur le repository git contient tous les commits qui ont été poussés et son propre groupe de branches
! il n’existe pas forcément de relations directes entre les branches distantes et celles présentes en local il faudra être spécifique, e.g. pour pousser des modifications d’une branche locale vers la jumelle sur le serveur
git push nom_repository nom_branche
un repository est dit distant du moment qu’il est ailleurs; github est le service de repositories git le plus utilisé
pour utiliser un repository git distant comme origine de notre projet
git remote add origin <adresse.git>
NB: git remote comprend des sous-commandes, les commandes liées à la configuration des repositories distants (e.g. remote add, remote rm, etc.) sans sous-commande
git remote
présente une liste de tous les repositories distants ajoutés au projet
si un projet est cloné avec git clone, add origine est effectué automatiquement: les repositories clonés depuis un serveur distant sont toujours préconfigurés avec ce serveur comme origine
le repository distants principal s’appelle par défaut origin (peut être renommé, mais cela est déconseillé)
git prend en charge 3 protocoles réseau différents git, ssh et http
SSH ne fonctionne que pour les repositories privés car il n’offre aucun moyen d’autoriser à quelqu’un à accéder à des ressources sans authentification
HTTPS est plus souple; n’importe quel internaute peut être autorisé à récupérer des modifications sur le repository tout en limitant le push aux membres d’une équipe; en principe, est le protocole à favoriser
le protocole Git est rarement utilisé; ne permet que la lecture
contrairement aux branches ordinaires, les branches distantes se trouvent sur une autre machine une fois commitée une modification dans une branche de notre repository local, il faut utiliser git push pour soumettre la copie de la branche (et tous les commits ajoutés) au serveur
git push <repository_distant> <branche>
e.g.
git push origin nouvelle-page-accueil
pour rafraichir la copie locale d’une branche pour récupérer les dernières modifications, il faut utiliser git pull pour intégrer les modifications effectuées dans une branche distante:
git pull <repository_distant> <branche>
e.g.
git pull origin nouvelle-page-accueil
ce qu’il se passe lors d’un push/pull: git doit transférer un paquet d’objets (commits et fichiers suivis) depuis ou vers le serveur ensuite a lieu un merge (fast-forward si tout se passe bien); le merge fait implicitement partie d’un pull/push lors d’un pull, git copie la branche du serveur vers un emplacement de notre ordinateur (FETCH_HEAD) avant de tenter le merge (c’est une branche temporaire créée comme tampon afin de fusionner les modifications récupérées) autrement dit, pull/push sont les versions distantes du merge et les deux font la même chose (déplacer une branche d’un ordinateur à un autre puis la fusionner à une autre branche)
pour éviter les risques de conflits lors de la fusion, il est recommandé de récupérer régulièrement la branche master du serveur:
git pull origin master
résoudre les conflits lors d’un push: le processessus de résolution est le même que pour un git merge local une foit le conflit résolu, il faut indexer (git add nom_fichier), commiter (git commit -m “”) et pousser sur le serveur (git push) ces modifications
conflits lors d’un push: en règle général, les repositories git côté serveur n’ont pas de copie de travail, de zones d’indexation et d’utilisateurs pour résoudre les conflits -> ne peuvent pas faire une fusion de branche si le fast-forward ne fonctionne pas le conflit peut être résolu en récupérant les modifications depuis le serveur et en essayant de les pousser à nouveau (le fast-forward consiste à déplacer le pointeur HEAD d’une branche du commit où il se trouve actuellement vers l’un de ses descendants directs; quand on récupère des modifications, le résultat est un merge commit, qui se trouve être un descendant direct du commit de la tête actuelle et peut donc être traité par un fast-forward) -> pour éviter un rejet, en principe, toujours faire un pull avant un push pour être sûr que la copie locale est à jour
rien ne lie par défaut les copies locales et distantes d’une branche donnée, même si elles portent le même nom on peut indiquer à git que les versions locales et distantes d’une branche sont liées en précisant qu’une branche locale suit son homologue distante (push/pull pourra être lancé sans argument pour pousser/récupérer des modifications) pour établir une relation de suivi, il faut indiquer –set-upstream (-u) dans git push
git push -u nom_repository nom_branche
ceci n’est à faire qu’une fois par branche locale
git pull récupère les modifications d’une seule branche; git fetch récupère tout le contenu d’un repository distant en une opération
git fetch nom_repository
(récupère le snapshot de chaque branche d’un repository distant)
git garde une trace de l’état de chaque branche d’un repository distant à l’aide d’un système de branches en lecture seule sans espace de nommage, basé dans notre copie locale du repository après fetch, on obtient des copies de chaque branche du repository distant, y compris de celles qui n’ont aucun équivalent local dans notre copie ces copies hors ligne spéciales peuvent parfois compliquer les choses, mais comme elles sont en lecture seule, ne servent qu’à représenter une copie de ce qui se trouve sur le serveur (git n’utilise le réseau que pour déplacer les commits)
comment ajouter un commit à la branche de quelqu’un d’autre ? d’abord, récupérer des copies de toutes les branches actuellement sur le serveur:
git fetch origin
(toutes les branches du serveur sont maintenant à notre disposition, même hors ligne)
git branche ne liste que les branches qui se trouvent sur notre copie locale; pour lister également toutes les branches connues se trouvant sur des repositories distants:
git branch --remote
-> toutes ces branches peuvent être extraites et utilisées ou fusionnées dans l’une de nos branches locales, NB:
git pull origin master
est en fait un raccourci pour
git fetch
git merge origin/master
pour extraire la branche sur laquelle on veut travailler: (si on ne possède pas de branche locale avec ce nom, en crée une automatique pour suivre la branche distante)
git checkout nom_branche_a_travailler
(le préfixe origin/ n’est pas utile)
chaque commit ajouté contribue à l’historique du projet
pour afficher une liste ordonnée (ordre chronologique inverse) de commits:
git log
par défaut, la liste présentée commence par le comit de tête de la branche actuelle pour afficher l’historique d’une branche particulière:
git log ma-branche
on peut utiliser l’option –pretty pour choisir un formatage, e.g.
git log --pretty=oneline
e.g. format personnalisé afin de connaitre l’auteur de chaque commit
git log --pretty='format:%h - %an: %s'
un commit contient une référence vers un ou plusieurs commits parents, qui pointent vers leurs comits parents et ainsi de suite jusqu’au début du projet
on peut faire afficher les commits qui ont eu lieu entre deux commits donnés (e.g. pour voir ce qui a changé entre 2 commits précis)
git log debut..fin
pour afficher tous les commits ajoutés à ma-branche pas encore fusionnés à master:
git log --oneline master..ma-branche
(oneline rend le résultat plus lisible)
git log branche-a..branche-b
affiche une liste de tous les commits de branche-b qui ne figurent pas dans branche-a si l’une des bornes de l’intervalle de commits est la HEAD actuelle, on peut laisser blanc, e.g.
git log --oneline ..master
on peut ajouter des options de filtrage pour limiter la liste des commits, e.g.
git log --author=Demare --grep=heroku --online Gemfile
-> filtre pour les commits dont l’auteur est Demare, qui proviennent de l’un de ces dossiers, contiennent le mot heroku et ont modifié le fichier Gemfile
id des commits: git doit affecter un nom ou numéro d’identification unique à chaque commit bien qu’il soit décentralisé, git doit garantir l’exactitude des données crée et utilise des ids basés sur le contenu de chaque commit plutôt qu’en affectant un nom ou numéro arbitraire les ids sont des sommes de contrôle (= sorte d’empreinte digitale numérique généralement utilsée pour commiter des données transmises sur un réseau)
quand on ajoute un commit, git prend tout ce qui le constitue (auteur, e-mail, date, heure, message de commit, référence aux commits parents et snapshot du projet) et lui applique une fonction de hashage afin de générer une chaine de 40 caractères ainsi, deux commits identiques auront des hashes identiques quel que soit l’ordinateur qui les a ajoutés -> chaque hashe identifie donc un seul commit de façon unique les premiers caractères (au moins quatre) peuvent être utilisés à la place de l’id entier du moment que cet id court est unique dans le repository
le message de commit peut être aussi long qu’on veut; il est recommandé qu’il soit court et descriptif seule la 1ère ligne apparait dans le log, c’est donc la plus importante
si on omet le –message dans la commande commit, on peut saisir le message directement dans un éditeur; pour configurer quel est l’éditeur favori:
git config --global core.editor 'atom --wait'
recommandations pour les messages de commit: utile, précis, cohérent, en utilisant la voix active (e.g. “corrigé coquille page index”)
il est recommandé qu’un commit corresponde à une unité de travail (on peut indexer et commiter des fichiers séparément si cela fait plus de sens)
chaque commit représente un changement par rapport au commit précédent; pour inspecter les différences entre deux commits
git diff
(les lignes ajoutées apparaissent préfixées de “+”, celles supprimées de “-“) NB: l’outil généraliste Kaleidoscope peut être utilisé pour comparer deux fichiers de n’importe quel type pour ouvrir les diff dans Kaleidoscope:
git difftool
pour afficher les statistiques des différences entre le commit HEAD actuel et le précédent (HEAD~1)
git diff --stat HEAD~1
git diff ne compare que deux versions à la fois
git diff --stat HEAD~50
-> ne représente pas les 50 derniers commits, mais la différence avec le commit qui occupe la 50ème place
les statistiques peuvent aussi être utilisées avec git log
git log --stat --pretty=format:"%h (%an) %s" HEAD~1..
-> statistiques en se limitant aux modifications survenues depuis l’avant-dernier commit avec format personnalisé
étiqueter les commits: les commits peuvent recevoir des noms permanents lisibles appelés tags tags sont semblables aux branches dans la mesure où elles attribuent des noms lisibles par l’homme à des commits particuliers mais contrairement aux branches qui flottent et désignent toujours le commit de tête, les tags désignent toujours un commit spécifique afin de marquer des moments intéressants ou importants du projet (en général, n’ont pas un grand intérêt) pour étiqueter un commit:
git tag nom_tag
une fois un commit étiqueté, le tag peut être utilisé partout là où on utiliserait l’id du commit si le commit n’est pas extrait au moment où on souhaite l’étiqueter:
git tag nom_tag commit_id
e.g.
git tag version1.0 3028c32
c’est un exemple de tag léger, qui est stocké dans le repository; juste un nom pointant vers un commit (comme dans le cas d’une branche) il existe des tags annotés qui, en plus d’un et une référence vers un commit, peuvent inclure un message similaire à un message de commit:
git tag version1.0 -a -m 'Version 1.0 22 dec 2020'
les tags comme les branches peuvent et doivent être partagés sur un repository distant et peuvent être poussés vers un repository distant de la même manière avec git push git push version1.0
quelques règles concernant les tags:
git checkout sert à extraire une branche; il peut aussi servir à extraire un commit -> restaure une copie locale du projet dans la version demandée le principe est le même pour extraire une branche ou un commit; mais en principe on ne s’attend pas à ajouter des commits après l’extraction d’un commit (mais cela reste possible; e.g. si on veut restaurer une version antérieure si un bug a été introduit)
git checkout commit_id
ou
git checkout commit_tag
git propose aussi un outil qui effectue ce type de recherche binaire et trouve automatiquement le commit responsable d’un problème donné:
git bisect
quand on extrait un commit, contrairement à une branche, git place dans l’état de “HEAD détaché”: le pointeur HEAD de notre ordinateur pointe vers un commit particulier mais pas une branche (“détaché” car on ne travaille sur aucune branche) si on ajoute des commits, ils seront enregistrés mais aucun nom de branche n’est disponible pour y faire référence) on n’est pas censé ajouter des commits dans cet état détaché, mais peut être utilisé comme “bac à sable” (cela limite les risques d’intégrer les changements testés à la version de production) les commits réalisés restent dans l’état détaché, sans domicile, jusqu’à ce qu’une branche soit créée pour les contenir pour créer une nouvelle branche pour les accueillir:
git checkout -b nouvelle_branche
pour sortir de l’état détaché, il suffit d’extraire une branche; revenir à master:
git checkout master
NB: git checkout traite toutes les références qui ne sont pas un nom de branche comme un commit, même si on la demande en utilisant une référence qui inclut le nom de la branche -> on pourrait ainsi se retrouver dans l’état détaché par inadvertance; ainsi:
git checkout ma-branche-2
pour extraire la branche nommée ma-branche-2 -> on extrait une branche mais si on extrait une référence à une branche distante, on extrait le commit qui se trouve actuellement à la tête de la branche, mais pas la branche
git checkout origin/ma-branche-2
à noter que les branches de git peuvent être visualisées comme un graphique orienté acyclique (GOA)
git config [--global] <clé> <valeur>
mise à jour des paramètres de git; –global indique que les préférences sont enregistrées dans un fichier du répertoire d’accueil autrement elles sont enregistrées et appliquées uniquement à un projet spécifique
git init
crée un nouveau projet git dans le répertoire de travail courant
git clone <URL> [répertoire]
copie un projet git existant
git status [-s] [chemin/vers/truc]
renvoie le statut de la copie de travail (identifie fichiers modifiés mais non indexés, ou ajoutés et non commités version raccourcie avec –short ou -s; un répertoire ou nom de fichier peut être indiqué pour limiter les résultés
git add [--all] nomfichier.txt
ajouter un fichier modifié à la zone d’indexation en vue de son inclusion dans le prochain commit
git rm dossier/nomfichier.txt
supprime le fichier puis indexe la suppression pour le prochain commit si le fichier a déjà été supprimé, se contente d’indexer le changement
git mv ancien.txt nouveau.txt
déplace le fichier et indexe la modification
git reset nomfichier.txt
inverse de git add: désindexe la modification de nomfichier.txt préalablement indexée
git commit [-a] [-m "mon mesage"]
ajoute un commit comprenant toutes les modifications indexées –all ou -a pour indexer automatiquement toutes les modifications apportées à la copie de travail –message ou -m pour préciser le message de commit (si pas précisé, git ouvre l’éditeur de texte pour le saisir)
git branch [-r|-a]
affiche une liste de toutes les branches; par défaut présente uniquement celles présentes dans la copie local du repository -r pour présenter toutes les branches récupérées d’un repository distant -a pour afficher les branches locales et distantes
git branch <nombranche> [<IDcommit>]
avec un nom de branch, git branch crée une branche sous ce nom qui démarre au commit actuel ou au commit spécifié
git checkout [-b] <nombranche-ou-commit>
met à jour la copie de travail afin qu’elle corresponde à la branche ou commit indiqué (fait basculer sur cette branche/ce commit) si une branche est extraite: git la définit comme la branche en cours pour y ajouter des commits si un commit/tag est extrait: git nous détache de toutes les branches -> on peut ajouter des commits
git merge <autrebranche>
fusionne autrebranche avec la branche actuelle; en cas de conflit, copie et indexe la plus grande portion possible de l’autre branche et balise les fichiers conflictuels
git remote add <nom> <URL>
ajoute un repository distant sous l’URL et le nom indiqué dans les paramètres du projet git local
git remote rm <nom>
retire le repository des paramètres de notre projet ainsi que toutes les branches de suivi distantes récupérées depuis le serveur (ne supprime le repository distant qu’au niveau des paramètres locaux; le serveur et les autres machines ne sont pas affectés)
git push <nomrepodistant> <nombranche>
pousse l’état actuel de nombranche dans le repository distant
git pull <nomrepodistant> <nombranche>
récupère l’état actuel de nombranche dans le repository distant vers la copie locale et tente de le fusionner avec la branche actuelle
git fetch <nomrepodistant>
copie tout le contenu du repository distant vers la copie locale (lors d’un git pull, git fetch se produit automatiquement)
git log [--online] [--pretty] [nombranche-ou-commit]
affiche une liste des commits en ordre chronologique inverse –pretty pour personnaliser le résultat –online pour le format le plus courant (ID de commit suivi du message de commit sur chaque ligne)
git diff [–stat] [nombranche-ou-commit] présentation visuelle des différences entre 2 commits –stat produit une vue résumée avec la liste des fichiers et modifiés et le nombre de lignes ajoutées/supprimées dans chacun d’eux
git tag [-a][-m] <nomtag> [<commit>]
étiqueter un tag avec nomtag -a pour créer un tag annoté (inclut la date, l’auteur et un message descriptif -> inclure –message ou -m comme pour un commit) autrement un tag léger est créé
git tag -d <nomtag>
supprimer un tag (en principe, ne devrait pas se faire)
git tag -l
liste de tous les tags de notre repository
git push --tags <nomrepodistant>
sans l’option –tags, git ne pousse aucun tag