Introduction à GIT¶§
Département Informatique (IUT Lyon 1)
Ce travail est sous licence Creative Commons Attribution-ShareAlike 3.0 France.
Motivations¶§
Exemple 1¶§
Note
- la version la plus à jour est-elle
Rapport.docouRapport_VFinale.doc? - et si on avait aussi
Rapport_VFinale1.docetRapport_VFinale2.doc(expérience vécue) ? - les versions n’apparaissent pas dans l’ordre (1.1, 1, 2)
- la version 2-jd vient elle avant ou après la version 2 ?
Exemple 2¶§
Note
- les versions de l’image sont elles numérotées indépendamment, ou par rapport aux versions de la page ?
- nécessité de renommer les fichiers pour visualiser une ancienne version (pour que les liens fonctionnent)
Histoires vraies¶§
Après que nous avons échangé avec un collègue des versions d’un fichier nommées
X_1.1.doc,X_1.2.doc,X_1.3.doc(et ainsi de suite),il a nommé la version finale
X_1.0.doc...Un autre collègue m’a envoyé, le 15 mars 2013, un fichier nommé
2013-03-17-xxx.Je l’ai modifié le 16 mars ; quel nom lui donner ?...
Conclusion¶§
- La gestion des versions est un travail fastidieux et méthodique.
- Les humains ne sont pas doués pour les travaux fastidieux et méthodiques.
- Laissons cela à l’ordinateur,
- et concentrons-nous sur la partie du travail où nous sommes meilleurs que l’ordinateur.
→ VCS (Version Control System)
Historique des VCS¶§
Notions de base¶§
Bon exemple¶§
Note
Le répertoire .git est un répertoire caché,
qui contient tout l’historique des fichiers.
Les avantages de la gestion de versions¶§
- Sauvegarde (modulo la synchronisation avec un serveur distant)
- Conservation de l’historique (nominatif) des fichiers (qui a fait quoi ?)
- Possibilité de retour en arrière
- Fusion des modifications lors du travail collaboratif
- Visualiser les changements au cours du temps
Notions¶§
Dépôt (repository)¶§
Le répertoire caché .git est nommé dépôt
(en anglais repository).
Il contient toutes les données dont GIT a besoin pour gérer l’historique. Sauf rarissimes exceptions, vous ne modifierez jamais son contenu directement, mais uniquement en passant par les commandes GIT.
Commit¶§
L’historique d’un projet est une séquence de « photos », contenant l’état de tous les fichiers du projet.
Ces « photos » s’appellent des commits, et possèdent :
- une date
- un auteur
- une description textuelle
- un lien vers le(s) commit(s) précédent(s)
On parle également de révision.
Illustration¶§
Visualisation d’un historique simple dans un outil graphique.
NB : on ignore pour l’instant le rectangle master ;
on l’expliquera par la suite.
Remarque¶§
Bien que conceptuellement, chaque commit contient tous les fichiers du projet, GIT utilise un système de stockage très efficace :
- le commit ne stocke que les fichiers modifiés par rapport au commit précédent;
- l’ensemble peut être compressé (
git gc) pour réduire encore la redondance (lorsque deux versions successives d’un fichier sont très proches).
NB : bien que GIT (et les autres VCS) soient plus particulièrement conçus pour des fichiers texte, ils fonctionnent aussi avec des fichiers binaires (images, bureautique, etc.).
Copie de travail¶§
On appelle copie de travail (en anglais working copy) les fichiers effectivement présents dans le répertoire géré par GIT.
Leur état peut être différent du dernier commit de l’historique.
Index¶§
L’index est un espace temporaire contenant les modifications prêtes à être « commitées ».
Ces modifications peuvent être :
- création de fichier
- modification de fichier
- suppression de fichier
Note
On remarque le code couleur de l’application gitk :
- rouge : changements non indexés, non commités
- vert : changements indexés, non commités
- jaune : commit courant (HEAD)
- bleu : autres commits
NB: la sémantique du rouge et du vert est la même pour la ligne de commande. Cependant, certains outils GIT ne respectent pas ce code couleur; c’est notamment le cas de TortoiseGit que nous allons utiliser par la suite.
Mise en œuvre¶§
Dans ce cours, nous considérerons deux méthodes possibles :
- Ligne de commande (Git Bash)
- Interface graphique (TortoiseGit)
Note
Il existe d’autres interfaces graphiques pour GIT,
notamment Git Gui qui est installé sur les machines de l’IUT,
mais que nous ne présenterons pas dans ce cours.
De plus, la plupart des IDE fournissent un accès aux commendes GIT, mais nous ne les traiterons pas non plus.
Création du dépôt¶§
Initialise la gestion de version dans un répertoire
en créant le sous-répertoire .git.
Mise en œuvre
Dans le menu contextuel du répertoire concerné, Git Create repository here...
En ligne de commande, depuis le répertoire concerné:
$ git init
Commiter des modifications¶§
Une fois les fichiers modifiés et dans un état satisfaisant, vous pouvez les commiter.
Remarque : lorsque vous effectuez un commit, il est essentiel d’écrire un message accompagnant le commit. Ce message doit être informatif quant à la nature des modifications que vous êtes en train de commiter.
Par exemple, blip est un mauvais message de commit, mais Correction des fautes d’orthographe dans la doc technique est un bon message de commit.
Note
En cas de problème, il est possible de corriger un commit (tant qu’il n’a pas été partagé avec d’autres collaborateurs), mais nous étudierons cela plus tard.
En ligne de commande¶§
Ajouter un fichier dans l’index
$ git add <filename>
Retirer un fichier de l’index
$ git reset <filename>
Pour voir l’état des modifications en cours
$ git status # résumé
$ git diff # détail des changements
Pour commiter les modifications indexées
$ git commit #ou
$ git commit -m "message de commit"
Consulter l’historique¶§
Menu contextuel > TortoiseGit > Show log
(cf. figure suivante)
En ligne de commande :
afficher la liste des commits
$ git log
(avec l’identifiant de chaque commit)
afficher le détail d’un commit particulier
$ git show <id-commit>
Résumé des états possibles d’un fichier avec GIT¶§
Figure inspirée de git-scm.org.
Exercice¶§
- Créez un nouveau répertoire, et faites-en un dépôt GIT.
- Ajoutez un fichier HTML dans ce répertoire, contenant une brève description de vous (ou de n’importe quel autre sujet qui vous intéresse). Commitez ces changements.
- Ajoutez maintenant une feuille de style externe à votre fichier HTML,
(c’est à dire sous la forme d’un fichier CSS séparé,
référencé par une balise
<link>). Commitez ces changements. - Affichez l’historique de vos changements (selon votre méthode préférée).
- Entraînez-vous à faire des commits : modifiez le contenu du fichier HTML et/ou de la feuille de style, ajoutez éventuellement d’autres fichiers (images par exemples). À chaque changement, commitez votre travail en rédigeant un message de commit suffisament explicite.
Note
Il faut observer le .git. S’il n’apparaît pas, veiller à configurer l’explorateur de fichiers pour qu’il affiche les fichiers et dossiers cachés.
Branches¶§
Motivation¶§
Dans certaines situations, on peut souhaiter faire cohabiter et évoluer plusieurs versions divergentes du même projet.
Ces versions peuvent parfois converger à nouveau (mais pas forcément).
Note
Les copies d’écran de ces exemples sont faites avec un autre logiciel que les précédentes, ce qui explique le code couleur différent.
Exemple 1 : CV¶§
Pour un CV, on souhaite avoir :
- une version « maître » que l’on maintient à jour,
- des variantes pour chaque demande d’emploi, adaptées en fonction de l’employeur visé.
Exemple 2 : site web¶§
Pour un site web, on souhaite avoir :
- la version publiée,
- une version de travail, dans laquelle on apporte des modifications incrémentales.
Les deux versions mènent leur existence en parallèle, la version publiée étant régulièrement mise à jour par rapport à la version de travail.
Exemple 3 : logiciel¶§
Dans un projet logiciel, on souhaite avoir :
- la version stable, dans laquelle on se contente de corriger des bugs, et
- une ou plusieurs versions expérimentales, dans lesquelles on implémente de nouvelles fonctionnalités ;
Une fois au point, chaque nouvelle fonctionnalités est intégrée à la version stable.
Notions¶§
- Une branche est la lignée (généalogique) de commits, à laquelle on a donné un nom.
- Le commit le plus récent de la branche est appelé sommet (en anglais tip) de cette branche.
- La copie de travail est (en général) liée au sommet d’une branche
(
masterpar défaut). - À chaque nouveau commit, le sommet de la branche courante est avancé vers ce nouveau commit (la branche « pousse »).
Note
Par « lignée », on entend : l’ensemble des commits ancêtres du sommet de la branche.
Dans le cas simple, cette lignée a une structure linéaire,
mais ce n’est pas toujours le cas
(comme en témoignent, dans les illustrations ci-avant,
la branche publié dans l’exemple du site web
et la branche master dans
l’exemple du logiciel).
Accessibilit鶧
Un commit est accessible s’il appartient à au moins une branche. Les commits non accessibles sont automatiquement supprimés par GIT.
Note
Cette suppression n’est cependant pas immédiate. Il est donc parfois possible de « sauver » un commit devenu récemment inaccessible, en créant une nouvelle branche avant sa suppression effective.
Lorsqu’on navigue dans l’historique, on lie la copie de travail à un commit particulier plutôt qu’à une branche (mode detached HEAD).
→ Les commits que l’on ferait dans cet état n’appartiendraient à aucune branche et seraient donc perdus.
Mise en œuvre¶§
Afficher la liste des branches¶§
Dans les interfaces graphiques :
elle apparaît chaque fois qu’elle est nécessaire
(par exemple, dans la boite de dialogue Switch/Checkout... vue précédemment).
En ligne de commande :
$ git branch
Le nom de la branche courante apparaît précédé d’une étoile.
Créer une nouvelle branche¶§
Cette opération consiste à placer, sur un commit existant, le sommet d’une nouvelle branche (qui pourra croître indépendamment des autres).
Depuis l’interface graphique¶§
Menu contextuel > TortoiseGit > Create Branch...
- on doit choisir un nom pour la nouvelle branche ;
- dans la section « Base on », on peut choisir sur quel commit la nouvelle sera créée (par défaut: commit courrant
HEAD) ;- si on coche la case Switch to new branch (en bas à droite) la nouvelle branche deviendra la branche courante.
En ligne de commande¶§
Pour créer une nouvelle branche sur le commit courant :
$ git branch <nom_nouvelle_branche>
Pour créer une nouvelle branche à un autre emplacement :
$ git branch <nom_nouvelle_branche> <revision>
Ces commandes ne changent pas la branche courante. Pour créer une nouvelle branche et en faire la branche courante, utilisez plutôt :
$ git checkout -b <nom_nouvelle_branche> # ou
$ git checkout -b <nom_nouvelle_branche> <revision>
Changer de branche¶§
Cette opération consiste à modifier la copie de travail pour la mettre dans le même état que le sommet d’une branche.
Indice
Pour pouvoir l’effectuer, il est nécessaire que la copie de travail ne contienne aucune modification non commitée.
Mise en œuvre¶§
Menu contextuel > TortoiseGit > Switch/Checkout...
- s’assurer que
Branchest bien coché, - sélectionner dans la liste correspondante le nom de la branche,
- valider.
- s’assurer que
En ligne de commande :
$ git checkout <branche>
À propos de git checkout¶§
La commande git checkout est utilisée dans divers contextes,
qui rendent difficile à percevoir sa cohérence interne.
La fonction première de cette commande est de modifier l’état de la copie de travail. Selon ses arguments, elle a des effets supplémentaires :
- un branche : changer la branche courante
- une révision : passer en mode detached HEAD
Exercice¶§
- Dans le dépôt que vous avez créé au premier exercice,
créez une branche nommée
style, et placez-vous dans cette branche. - Modifiez la feuille de style (par exemple pour changer la couleur de fond) et commitez vos changements.
- Revenez sur la branche
master. Constatez que vos changements de style ont disparu (pour l’instant). - Dans la branche
master, modifiez ou ajoutez du contenu au fichier HTML, et commitez vos modifications. - Revenez sur la branche
style. Constatez que vos changements de style ont réapparu, mais que vos dernières modifications dans le fichier HTML ont, elles, disparu. - Modifiez à nouveau la feuille de style (par exemple pour changer la police) et commitez vos changements.
Fusionner deux branches¶§
L’opération de fusion (en anglais merge) permet d’intégrer les modifications d’une branche dans une autre.
Note
GIT permet également de fusionner plus de deux branches dans une même opération, mais nous n’irons pas jusque là dans ce cours.
Il y a deux situations possibles, selon les positions relatives de la branche à fusionner (source) et de la branche destination.
Fusion sans commit¶§
Si la branche destination est contenue dans la branche source,
la fusion a simplement pour effet de déplacer le sommet de la branche cible.
Ce type de fusion est appelée fast forward.
Note
Ce comportement préserve autant que possible un historique linéaire, donc plus simple.
Cependant, dans certains cas, on souhaite forcer la création d’un commit même lorsqu’on est dans cette situation (c’est notamment le choix qui a été fait dans l’exemple du site web).
Pour cela, en ligne de commande, on ajoutera l’option --no-ff.
Avantage : les deux branches gardent leur identité dans le graphe.
Fusion avec commit¶§
Si la branche destination et la source ont divergé,
la fusion crée un nouveau commit intégrant les modifications des deux branches ;
ce commit devient le sommet de la branche destination.
Note
Bien sûr, cela suppose que les modifications des deux branches soient compatibles. La section suivante traite des conflits, et de comment les résoudre.
Mise en œuvre¶§
Menu contextuel > TortoiseGit > Merge...
- s’assurer que
Branchest bien coché, - sélectionner la branche à fusionner dans la branche actuelle,
- valider.
- s’assurer que
En ligne de commande :
$ git merge <branche>
Exercice¶§
- Nous allons maintenant fusionner la branche
style(créée à l’exercice précédent) avec la branchemaster. - Placez-vous dans la branche
master, et appliquez la méthode de votre choix (ligne de commande ou interface graphique) pour y fusionner la branchestyle. - Constatez que toutes vos modifications (contenu HTML et style) sont maintenant visibles.
- Constatez également (dans l’historique) que le commit ainsi créé a deux commit parents.
Gérer les conflits¶§
Motivation¶§
La fusion de branches est automatiquement gérée par GIT lorsque les modifications des deux branches portent sur :
- des fichiers différents, ou
- des parties distinctes des mêmes fichiers texte.
Exemple géré par GIT¶§
Branche 1 :
- La première ligne
+ La première ligne modifiée
La deuxième ligne
La troisième ligne
Branche 2 :
La première ligne
La deuxième ligne
- La troisième ligne
+ La troisième ligne modifiée
Fusion :
La première ligne modifiée
La deuxième ligne
La troisième ligne modifiée
Exemple non géré par GIT¶§
Branche 1 :
- La première ligne
+ La première ligne modifiée
La deuxième ligne
- La troisième ligne
+ La troisième ligne modifiée
Branche 2 :
- La première ligne
+ La première ligne changée
La deuxième ligne
La troisième ligne
Mise en œuvre¶§
Lorsque GIT rencontre un conflit au moment d’une fusion, un message indique les fichiers en conflit.
On est dans un état instable qui suppose :
- de résoudre le conflit, ou
- d’abandonner la fusion.
Fichiers comportant un conflit¶§
Les fichiers texte comportant un conflit sont automatiquement modifiés pour :
- inclure les modifications non conflictuelles, et
- faire apparaître les deux versions concurrentes pour les modifications conflictuelles.
<<<<<<< HEAD
La 1e ligne modifiée
=======
La 1e ligne changée
>>>>>>> src
La 2e ligne
La 3e ligne modifiée
Les fichiers binaires ne sont pas modifiés.
Résolution du conflit¶§
Une fois les fichiers en conflit corrigés, on peut résoudre le conflit :
Menu contextuel > TortoiseGit > Resolve...
En ligne de commande :
$ git commit -a
Le nouveau commit aura pour parents les sommets des branches fusionnées.
Abandon¶§
On peut également décider d’abandonner la fusion :
Menu contextuel > TortoiseGit > Abort Merge
En ligne de commande :
$ git merge --abort
Exercice¶§
Créez un nouveau dépot, et ajoutez-y un fichier
conflit.txtcontenant le texte suivant :La première ligne La deuxième ligne La troisième ligne
Créez plusieurs branches, dans lesquelles vous modifierez différemment le fichier
conflit.txt, en suivant les exemples ci-avant. Tentez ensuite de fusionner ces branches.Lorsque GIT vous signale un conflit, constatez comment le fichier
conflit.txta été modifié, et résolvez le conflit.
Dépot distant¶§
Notion¶§
Un dépôt distant (en anglais remote repository) est un dépôt GIT, tout à fait similaire à un dépôt local, mais acessible à distance via une URL.
Exemple : https://github.com/pchampin/intro-git.git
Un dépôt local peut être lié à un dépôt distant ; GIT offre des fonctionnalités pour copier des commits de l’un à l’autre.
Note
En fait, un dépôt distant n’est pas forcément « à distance » (même si c’est le plus souvent le cas).
On peut aussi utiliser comme dépôt distant un dépôt accessible dans un répertoire partagé, ou sur un support amovible (clé USB, disque dûr externe)...
Motivations¶§
- sauvegarder le projet (fichiers + historique),
- travailler sur plusieurs machines,
- rendre le projet accessible à d’autres personnes,
- travailler sur un projet publié par quelqu’un d’autre,
- collaborer à plusieurs sur un projet (ce sera l’objet du chapitre suivant).
Mise en œuvre¶§
Créer un dépôt sur un serveur¶§
Il existe plusieurs sites permettant d’héberger et de partager vos projets GIT :
|
|
|
|
dont un hébergé par l’université Lyon 1 :
Note
Concernant la forge de Lyon 1, en cas de problème avec les certificats SSL, consultez cette FAQ
Cloner un dépôt distant¶§
Une fois votre dépôt distant créé, vous pouvez en faire un clone (une copie à la fois des fichiers et de l’historique) sous forme d’un dépôt local, qui sera lié à ce dépôt distant.
Mise en œuvre
Menu contextuel > Git Clone...
- dans le champs URL, sélectionner l’URL du dépôt distant ;
- le cas échéant, modifier l’emplacement du dépôt local ;
- valider.
en ligne de commande :
$ git clone <url-dépôt-distant> <emplacement>
Note
Il est possible de procéder à l’inverse : commencer à travailler sur un dépôt local, puis créer un dépôt distant pour publier le travail.
La procédure est un peu plus complexe, mais est généralement bien documentée par les services d’hébergement GIT, au moment où vous créerez le dépôt distant.
Problème depuis le campus Lyon1¶§
Si vous rencontrez des problèmes pour cloner un dépôt,
cela peut venir d’une mauvaise configuration du proxy.
Dans Git Bash, tapez les deux commandes suivantes :
$ git config --global http.proxy http://proxy.univ-lyon1.fr:3128
$ git config --global https.proxy https://proxy.univ-lyon1.fr:3128
puis tentez à nouveau.
Publier des commits¶§
Cette opération copie sur le dépôt distant les commits locaux (de la branche courante) qui n’y sont pas encore présents.
Mise en œuvre
Menu contextuel > TortoiseGit > Push...
En ligne de commande :
$ git push
Indice
Cela suppose évidemment que vous soyez propriétaire du dépôt distant, ou que le propriétaire ait configuré son dépôt pour vous autoriser à le modifier.
Désynchronisation¶§
Le push n’est possible que si la branche locale contient tous les commits présents dans la branche distante (plus, bien sûr, les nouveaux commits que vous voulez pousser).
Si la branche distante contient des commits inconnus de votre dépôt local (poussés depuis une autre machine, par vous ou quelqu’un d’autre), il faudra au préalable les récupérer (cf. ci-après).
Récupérer les commits¶§
Cette opération copie dans le dépôt local les commits distants (de la branche courante) qui n’y sont pas encore présents. Elle met également à jour la copie de travail.
Cela est nécessaire
- lorsque vous travaillez sur plusieurs machines, et utilisez le dépôt distant pour les synchroniser, ou
- lorsque le dépôt distant est modifié par quelqu’un d’autre.
Mise en œuvre
Menu contextuel > TortoiseGit > Pull...
En ligne de commande :
$ git pull
Désynchronisation¶§
Dans le cas le plus simple, le dépôt distant est « en avance » par rapport au dépôt local : il contient tous les commits du dépôt local, plus ceux que vous cherchez à récupérer.
Dans un cas plus complexe, des commits ont pû être ajoutés parallèlement dans les deux dépôts.
Dans ce cas, pull effectue automatiquement une opération de fusion.
Cela peut entraîner un conflit, qu’il faudra résoudre comme vu
précédemment.
Indice
Il est bien sûr préférable d’éviter ces conflits plutôt que de les résoudre a posteriori. Modifier la même information en parallèle n’est, de toute façon, pas une bonne idée...
Collaboration¶§
Motivation¶§
- On a vu que GIT gérait l’évolution des fichiers,
qu’elle soit linéaire ou non linéaire (branches) :
- en facilitant la fusion des modifications parallèles, et
- en détectant les conflits.
- Déjà utiles dans un contexte individuel, ces fonctionnalités vont s’avérer primordiales dans un contexte collectif.
Notions¶§
- Lorsqu’on travaille à plusieurs,
- chacun possède une copie des fichiers.
- Lorsqu’on travaille à plusieurs avec GIT,
- chacun possède une copie des fichiers et du dépôt.
- On ne s’échange plus les fichiers individuellement,
- mais des commits (donc des états cohérents de l’ensemble des fichiers).
- On met en commun en fusionnant les branches.
Dépôt distant¶§
On a vu dans la section précédente qu’un dépôt local pouvait être lié à un dépôt distant.
En fait, un dépôt GIT peut être lié à un nombre arbitraire de dépôts distants, chacun identifié par un nom.
Lors d’un clone,
le dépôt cloné est automatiquement ajouté comme dépôt distant,
sous le nom origin.
Branche de suivi¶§
Pour chaque branche de chaque dépôt distant, GIT crée dans le dépôt local une branche spéciale appelée branche de suivi (en anglais remote-tracking branch). Son nom est de la forme :
<nom-dépôt-distant>/<branche>
Cette branche reflète l’état de la branche distante correspondante ; elle n’est jamais modifiée directement.
Elle peut en revanche être fusionnée à une branche locale, afin d’y intégrer les modifications faites par d’autres.
Mise en œuvre¶§
Lier à un dépôt distant¶§
Menu contextuel > TortoiseGit > Settings > Git > Remotes
(interface complète de gestion des dépôts distants)
En ligne de commande :
$ git remote add <nom> <emplacement>
Indice
Cette opération est à faire une seul fois par dépôt (et par dépôt distant), pour pouvoir ensuite interagir avec le dépôt distant.
Mettre à jour les branches de suivi¶§
On a vu précédemment la commande git pull
qui récupère les commits distants et les fusionne dans la branche courante.
La commande git fetch permet de simplement récupérer les commits distants et de mettre à jour les branches de suivi,
sans impacter les branches locales.
Note
En fait, git pull n’est ni plus ni moins un raccourci qui effectue un git fetch
suivi d’un git merge.
Mise en œuvre¶§
Menu contextuel > TortoiseGit > Fetch...
- s’assurer que
Remoteest bien coché, - sélectionner le dépôt distant souhaité la liste correspondante,
- valider.
- s’assurer que
En ligne de commande :
$ git fetch <nom-dépôt-distant>
Indice
Les branches de suivi sont créées par le fetch.
Ainsi, si de nouvelles branches sont créées dans le dépôt distant, les branches de suivi correspondantes seront également ajoutées.
Fusionner une branche de suivi¶§
Le principe est le même que pour la fusion entre branches locales.
Menu contextuel > TortoiseGit > Merge...
- s’assurer que
Branchest bien coché, - sélectionner la branche de suivi à fusionner dans la branche actuelle,
- valider.
- s’assurer que
En ligne de commande :
$ git merge <branche-de-suivi>
Types de collaborations¶§
La flexibilité de GIT permet de multiples formes d’organisation pour le travail collaboratif.
On donne ici quelques exemples (non exhaustifs, et non exclusifs).
Organisation en étoile¶§
Note
Ce type de collaboration est inspiré des VCS centralisés, et est simple à mettre en œuvre.
Il suppose de mettre un place un unique dépôt distant sur lequel plusieurs collaborateurs ont les droits en écriture.
Organisation pair-à-pair¶§
Note
Ce type de collaboration est très flexible. On peut notamment le mettre en œuvre sans disposer d’un serveur, en utilisant par exemple des média amovibles (clé USB, carte DS, disque externe...) comme “dépot distant” pour communiquer entre les différents acteurs.
Organisation “github”¶§
Note
Ce type de collaboration est encouragé par les sites d’hébergement comme Github (mais également d’autres).
Chaque collaborateur dispose d’un clone public (fork) du projet, et y publie les commits qu’il souhaite partager.
Il sollicite ensuite les autres collaborateur pour tirer ces commits dans leur propre dépôt/ On appelle cette sollicitation un pull request (ou plus rarement un merge request).
La plupart du temps, l’un des dépôts publics (celui du leader du projet, typiquement) est considéré comme la référence, donc ce type d’organisation se rapproche de l’organisation en étoile, mais permet à n’importe qui de proposer des modifications, sans avoir besoin d’obtenir les droits en écriture sur le dépôt de référence.
Exercice¶§
Le meilleur moyen d’expérimenter la collaboration est de travailler avec des collaborateurs !
Si vous voulez essayer, publiez votre dépôt sur l’espace partagé de votre choix, et demandez à un collègue d’en faire un clone.
C’est à vous de fixer les droits sur votre dépôt distant en fonction de ce que vous souhaitez (accessible en lecture seule, ou bien en lecture / écriture).
Ré-écrire l’histoire¶§
Note
L’objectif n’est pas de travailler sur ces notions, mais de signaler leur existence pour plus tard... et pour les curieux :-)
Motivation¶§
Avant de publier un ensemble de commits, on peut souhaiter le « nettoyer » un peu,
notamment pour rendre l’historique du projet plus lisible.
Avertissement
Ceci ne doit jamais être fait sur des commits
qui ont déjà été partagés avec d’autres personnes
(notamment avec git push).
Cela créerait une incohérence entre les dépôts.
Amendement¶§
Il arrive que l’on fasse un commit incomplet :
- oubli d’ajouter certains fichiers / certaines modifications,
- coquilles dans les ajouts...
On peut bien sûr corriger cet oubli dans un nouveau commit, mais cela contredit l’idée qu’un commit représente un état cohérent de l’ensemble des fichiers.
Dans ces situations, il est possible de modifier (amender) le dernier commit créé.
Rebase¶§
On a vu que la fusion de deux branches créait un commit à plusieurs parents si les branches avaient divergé.
Si on préfère garder un historique linéaire, GIT permet de « rejouer » les modifications d’une branche à partir du sommet de l’autre branche, en re-créant les commits correspondants.
Pour aller plus loin¶§
Se documenter¶§
- Si vous voulez en savoir plus sur GIT, consultez son excellente documentation sur git-scm.org ainsi que les vidéos très instructives !
Autres outils de gestion de version¶§
- Vous n’êtes pas certains de préférer GIT? Prenez le temps de comparer les différents outils de gestion de version. Il existe de nombreux comparatifs en ligne, comme par exemple sur Wikipedia.
Mercurial
- Mercurial (abbrégé Hg) est un gestionnaire de version similaire à GIT, mais comporte quelques différences (de terminologie notamment).
- Un guide de pour passer de GIT à Mercurial est disponible ici : https://www.mercurial-scm.org/wiki/GitConcepts
Crédits¶§
Ce support a été réalisé par Pierre-Antoine Champin et Amélie Cordier.
Merci à Isabelle Gonçalves et Jocelyn Delalande pour leurs contributions.