Git manual - TecostNetwork/Network GitHub Wiki
La différence principale entre ces deux systèmes réside dans l’approche distribuée de git, alors que cvs est centralisé. Avec Git, le développeur a une copie complète du repository sur sa machine alors qu’avec CVS le développeur a uniquement la version de travail du code qu’il récupère depuis un serveur.
Avec Git, le développeur interagit d’abord avec son repository local puis avec le serveur, tandis qu’avec CVS l’interaction se fait directement avec le serveur avec CVS. Le serveur dans Git est également une copie du repository. Le partage de modifications avec Git se réalise donc en deux étapes (commit puis push) contre une seule avec CVS (commit).
Avec CVS, les changements sont versionnés par fichier et identifiés par un numéro de version alors qu’avec Git tout le repository est versionné à chaque modification. La version du repository est identifié par un SHA-1.
Le terme HEAD dans CVS fait référence à la branche principale. Dans Git, le terme HEAD fait référence à la branche sur laquelle on est en train de travailler, donc potentiellement une autre branche que la branche principale. La branche principale dans Git est usuellement nommée master.
Le concept le plus important à comprendre est la manière dont Git gère les commit et les branches. Un commit représente un snapshot de tout le repository à un moment donné (et non une différence). Les commit sont liés à leur parent (le commit précédent) pour former un DAG (Directed Acyclic Graph). La valeur hexadécimale associée à un commit est son identifiant (object id ou OID).
Une branche git n’est rien d’autre qu’une étiquette (un pointer) sur un commit. Lorsque l’on commit sur une branche, l’étiquette de la branche est déplacée vers le nouveau commit. Créer une branche revient uniquement à ajouter un nouveau pointer sur un commit existant. Il convient donc de parler « d’emplacement » d’une branche plutôt que du contenu d’une branche.
Ci-dessous, la création de la branche « testing » à partir de la branche « master » (Figure 1). Notez que le HEAD n’a pas bougé et pointe toujours sur la branche « master ».
Figure 1 - Création de la branche "testing" à partir du commit f30ab
Remarque : le HEAD est aussi un pointer mais _sur une branche (_un pointer de pointer en quelques sorte), il représente toujours le code sur lequel on est en train de travailler.
On se positionne sur la branche (déplacement du pointer HEAD) :
Figure 2 - Checkout de la branche "testing". Le pointer HEAD se déplace
On commit sur la branche « testing ».
Figure 3 - Commit sur la branche "testing"
On déplace le HEAD sur « master » puis on commit un changement, ce qui fait diverger notre code en deux versions « master » et « testing »
Figure 4 Checkout du "master" et commit
Stages
Figure 5 - Stages et commandes de transition
Workspace / working directory / working tree : Le working tree représente la version du code sur laquelle le développeur travaille, c’est-à-dire là où les fichiers réels sont accessibles.
Staging : le zone de stage contient les fichiers modifiés ayant été sélectionnés pour le prochain commit. Aussi appelé Index.
Local repository : copie locale du repository.
Remote repository : repository de référence (github.tecost.ch/Tecost/tecost.git)
Collaboration
Le partage du code avec Git se réalise en faisant communiquer deux copies d’un repository à l’aide de commandes dédiées (push, fetch/pull). Avant d’utiliser explicitement une de ces commandes, le développeur travaille dans un environnement isolé.
Git permet de faire communiquer deux copies d’un repository avec les remotes. Un remote est un simple raccourci une URL d’un autre repository évitant de saisir l’URL à chaque fois. Le remote origin est le nom du raccourci ajouté automatiquement lors du clone d’un repository, typiquement https://github.tecost.ch/Tecost/tecost.git
Une remote-tracking branch est un type particulier de branche gérée automatiquement par git. Une remote-tracking branch est une référence vers une branche d’un autre repository et a pour but de représenter l’état de branche distante dans le repository local. Les remote-tracking branches sont créées automatiquement par git pour toutes les branches distantes et nommées par défaut <remote>/<remote_branch_name>, par exemple origin/master.
En pratique, l’utilisation des remotes est transparente. Ne pas s’amuser à configurer d’autres remotes et à changer la configuration.
Must Read
https://git-scm.com/book/en/v2/Getting-Started-What-is-Git%3F#what_is_git_section
http://ftp.newartisans.com/pub/git.from.bottom.up.pdf
https://eagain.net/articles/git-for-computer-scientists/
https://git-scm.com/about/small-and-fast
https://git-scm.com/book/en/v2/Git-Branching-Branches-in-a-Nutshell
https://git-scm.com/book/en/v2/Git-Internals-Git-References