Introduction

La base de merge de deux commits est leur meilleur ancêtre commun : la fondation que Git utilise pour les merges trois-voies. Choisir la bonne base est ce qui fait que les merges « automatiques » fonctionnent réellement.

Introduction

Quand Git ne peut pas combiner automatiquement deux changements à la même région d'un fichier, il laisse des marqueurs de conflit dans la copie de travail et vous laisse résoudre manuellement. Les marqueurs ne sont pas magiques ; ils enregistrent exactement ce que chaque côté a fait par rapport à une base commune.

Introduction

git push téléverse les commits vers un remote et met à jour les refs de ce remote. Contrairement à fetch, il modifie l'état du serveur, donc des mécanismes de sécurité existent pour empêcher d'écraser le travail des autres.

Introduction

git pull est du sucre pour git fetch suivi de l'intégration de la branche upstream dans la branche courante. L'étape d'intégration est soit un merge (par défaut) soit un rebase.

Les deux étapes

1. git fetch <remote> <refspec> : télécharge et met à jour les refs de tracking.
2. Si pull.rebase est false : git merge FETCH_HEAD.
3. Si pull.rebase est true : git rebase FETCH_HEAD.

Séquence manuelle équivalente :

Introduction

git fetch est l'opération réseau qui télécharge de nouveaux objets et met à jour les refs de tracking distant. Il ne change pas vos branches ou arborescence de travail, ce qui en fait la commande « quoi de neuf ? » la plus sûre.

Introduction

git clone ressemble à une opération unique mais en compose en réalité plusieurs. Comprendre les étapes aide pour le dépannage des clones partiels, lents ou avec des défauts surprenants.

Introduction

Git supporte deux types de tags : lightweight, qui sont juste des refs pointant vers des commits, et annotés, qui sont des objets Git complets avec métadonnées. Utilisez les tags annotés pour les releases.

Introduction

Git garde plusieurs refs spéciales « auxiliaires » dans .git/ pour enregistrer l'état pendant les opérations multi-étapes. Les connaître transforme les récupérations effrayantes en one-liners.

ORIG_HEAD

ORIG_HEAD est défini chaque fois qu'une opération « dangereuse » déplace beaucoup HEAD : merge, rebase, reset, am. Il capture la pointe précédente pour que vous puissiez annuler :

Introduction

Git stocke les objets dans deux formats : loose (un fichier par objet sous .git/objects/xx/yyyy...) et packé (plusieurs objets dans un seul fichier .pack avec un compagnon .idx). Les packs sont bien plus efficaces sur disque et sur le réseau.

Introduction

Un commit Git référence zéro, un ou plusieurs commits parents. Tout l'historique est un graphe acyclique dirigé (DAG) de ces liens parents. Les branches et tags sont simplement des étiquettes sur des nœuds de ce graphe.

Anatomie d'un lien parent

git cat-file -p HEAD
# tree 9f1a...
# parent b2c3...
# parent d4e5...        (uniquement sur les merge commits)
# author Ada ...
# committer Ada ...

Un parent : historique linéaire. Deux parents : un merge. Zéro parent : un commit racine. Trois ou plus : un merge octopus.