Introduction à GIT§

IUT Lyon 1)

Creative Commons License

Ce travail est sous licence Creative Commons Attribution-ShareAlike 3.0 France.

1

Motivations§

2

Exemple 1§

_images/motivation1.png

Note

  • la version la plus à jour est-elle Rapport.doc ou Rapport_VFinale.doc ?
  • et si on avait aussi Rapport_VFinale1.doc et Rapport_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 ?
3

Exemple 2§

_images/motivation2.png

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)
4

Histoires vraies§

5

Conclusion§

VCS (Version Control System)

6

Avertissement§

_images/logogit.png
7

Historique des VCS§

8

Origines§

9

Évolutions§

Systèmes centralisés

Systèmes décentralisés

→ facilitent une utilisation individuelle

10

Notions de base§

11

Bon exemple§

_images/motivation3.png

Note

Le répertoire .git est un répertoire caché, qui contient tout l'historique des fichiers.

12

Les avantages de la gestion de versions§

13

Notions§

14

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.

15

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 :

On parle également de révision.

16
Illustration§
_images/historique1.png

Visualisation d'un historique simple dans un outil graphique.

NB : on ignore pour l'instant le rectangle master ; on l'expliquera par la suite.

17
Remarque§

Bien que conceptuellement, chaque commit contient tous les fichiers du projet, GIT utilise un système de stockage très efficace :

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.).

18

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.

_images/historique2.png
19

Index§

L'index est un espace temporaire contenant les modifications prêtes à être « commitées ».

Ces modifications peuvent être :

_images/historique3.png

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.

20

Mise en œuvre§

Dans ce cours, nous considérerons deux méthodes possibles :

_images/popup_menu.png

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.

21

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

22

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.

23
Depuis l'interface graphique§
_images/gui-commit-annot.svg
24
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"
25

Consulter l'historique§

26
Depuis l'interface graphique§
_images/gui-log-annot.svg
27

Résumé des états possibles d'un fichier avec GIT§

_images/git-states.svg

Figure inspirée de git-scm.org.

28
Exercice§
  1. Créez un nouveau répertoire, et faites-en un dépôt GIT.
  2. 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.
  3. 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.
  4. Affichez l'historique de vos changements (selon votre méthode préférée).
  5. 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.

29

Motivation§

L'intérêt d'utiliser un VCS est de pouvoir consulter n'importe quelle version antérieure du projet.

⚠ Attention cependant :

Dans les deux cas, vous risqueriez de perdre ces modifications (GIT affiche d'ailleurs des messages d'avertissement).

31

Mise en œuvre§

32

Expressions de révision§

Il existe plusieurs méthodes pour spécifier une révision à GIT :

(liste non exhaustive)

33

Identifiant§

Chaque commit a un identifiant, affiché

  • par l'interface graphique (cf. figure),
  • par la commande git log.

On peut spécifier une révision en utilisant

  • l'identifiant complet du commit, ou
  • les premiers caractères de l'identifiant, tant qu'il n'y a pas d'ambiguïté

Exemple :

$ git checkout 9a063f5fd514e966837163ceffaec332ce66fdff    # ou
$ git checkout 9a063
34

Relatif§

HEAD~ ou HEAD~1 désignent le parent du commit courant. Ainsi :

$ git checkout HEAD~

permet de remonter d'un commit dans l'historique.

NB : HEAD~2 remonte de deux commits, HEAD~3 de trois commits, et ainsi de suite.

35

Retour au présent§

NB : ceci est en fait un cas particulier de l'action Changer de branche que nous étudierons un peu plus tard.

36

Exercice§

  1. Naviguez dans l'historique du dépôt créé à l'exercice précédent, pour afficher l'avant-dernière version de votre fichier HTML.
  2. Affichez ensuite l'antépénultième (avant-avant-dernière) version.
  3. Affichez ensuite la deuxième version de votre fichier HTML.
  4. Affichez ensuite la première version de votre fichier HTML.
  5. Revenez au « présent » (i.e. la dernière version).
37

Entractes§

Nous venons de voir les fonctionnalités les plus basiques de GIT, qui permettent de gérer efficacement correctement l'historique d'un ensemble de fichiers → à utiliser sans modération.

Dans la suite, nous allons étudier des fonctionnalités un peu plus avancées, qui seraient impraticables avec une gestion « manuelle » de l'historique.

  • elle peuvent donc vous sembler superflues,
  • mais s'avèrent vite indispensables quand on y a pris goût.
38

Branches§

39

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.

40

Exemple 1 : CV§

Pour un CV, on souhaite avoir :

41
Illustration§
_images/branches_cv.png

Note

L'historique n'a plus une structure linéaire, mais arborescente (ce qui justifiera la métaphore de la « branche »).

42

Exemple 2 : site web§

Pour un site web, on souhaite avoir :

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.

43
Illustration§
_images/branches_siteweb.png

Note

L'historique n'est même plus un arbre, mais un graphe orienté sans cycle.

44

Exemple 3 : logiciel§

Dans un projet logiciel, on souhaite avoir :

Une fois au point, chaque nouvelle fonctionnalités est intégrée à la version stable.

45
Illustration§
_images/branches_logiciel.png
46

Notions§

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).

47

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.

48

Mise en œuvre§

49

Afficher la liste des branches§

50

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).

51
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.
52
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>
53

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.

54
Mise en œuvre§
55
À 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 :

56

Exercice§

  1. 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.
  2. Modifiez la feuille de style (par exemple pour changer la couleur de fond) et commitez vos changements.
  3. Revenez sur la branche master. Constatez que vos changements de style ont disparu (pour l'instant).
  4. Dans la branche master, modifiez ou ajoutez du contenu au fichier HTML, et commitez vos modifications.
  5. 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.
  6. Modifiez à nouveau la feuille de style (par exemple pour changer la police) et commitez vos changements.
57

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.

58
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.

_images/merge-ff.svg

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.

_images/merge-noff.svg

Avantage : les deux branches gardent leur identité dans le graphe.

59
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.

_images/merge-commit.svg

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.

60
Mise en œuvre§
61
Exercice§
  1. Nous allons maintenant fusionner la branche style (créée à l'exercice précédent) avec la branche master.
  2. Placez-vous dans la branche master, et appliquez la méthode de votre choix (ligne de commande ou interface graphique) pour y fusionner la branche style.
  3. Constatez que toutes vos modifications (contenu HTML et style) sont maintenant visibles.
  4. Constatez également (dans l'historique) que le commit ainsi créé a deux commit parents.
62

Gérer les conflits§

63

Motivation§

La fusion de branches est automatiquement gérée par GIT lorsque les modifications des deux branches portent sur :

64

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
65

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
66

Conflit§

On a donc un conflit lorsque les deux branches modifient :

Dans ce cas, le conflit doit être résolu à la main avant de pouvoir créer le commit de fusion.

67

Remarque§

Avertissement

La stratégie de GIT n'est qu'une heuristique.

Cela signifie que des branches jugées compatibles par GIT peuvent être sémantiquement incohérentes. Il convient donc de vérifier le résultat de la fusion, même lorsqu'aucun conflit n'est signalé.

68

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.
69

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.

70

Résolution du conflit§

Une fois les fichiers en conflit corrigés, on peut résoudre le conflit :

Le nouveau commit aura pour parents les sommets des branches fusionnées.

71

Abandon§

On peut également décider d'abandonner la fusion :

72
Exercice§
  1. Créez un nouveau dépot, et ajoutez-y un fichier conflit.txt contenant le texte suivant :

    La première ligne
    La deuxième ligne
    La troisième ligne
    
  2. 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.

  3. Lorsque GIT vous signale un conflit, constatez comment le fichier conflit.txt a été modifié, et résolvez le conflit.

73

Dépot distant§

74

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)...

75

Motivations§

76

Vue d'ensemble§

_images/git-states2.svg
77

Mise en œuvre§

78

Créer un dépôt sur un serveur§

Il existe plusieurs sites permettant d'héberger et de partager vos projets GIT :

GitHub BitBucket
GitLab Framagit

dont un hébergé par l'université Lyon 1 :

http://forge.univ-lyon1.fr/

Note

Concernant la forge de Lyon 1, en cas de problème avec les certificats SSL, consultez cette FAQ

79

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

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.

80
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.

81

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

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.

82
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).

83

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

Mise en œuvre

84
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...

85
Exercice§
  1. Créez un dépôt distant sur le service d'hébergement de votre choix.
  2. Clonez le dans un dépôt local
  3. Créez un fichier "message.txt" dans le dépôt local, commitez le et poussez le.
  4. Constatez que le fichier message.txt apparaît bien sur la page Web de votre dépôt distant.
86

Collaboration§

87

Motivation§

88

Notions§

89

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.

90

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.

91

Mise en œuvre§

92

Lier à un dépôt distant§

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.

93

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.

94
Mise en œuvre§

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.

95

Fusionner une branche de suivi§

Le principe est le même que pour la fusion entre branches locales.

96

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).

97

Organisation en étoile§

_images/collab_star.svg

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.

98

Organisation pair-à-pair§

_images/collab_p2p.svg

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.

99

Organisation "github"§

_images/collab_github.svg

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.

100
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).

101

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 :-)

102

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.

103

Amendement§

Il arrive que l'on fasse un commit incomplet :

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éé.

104

Mise en œuvre§

105

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.

_images/rebase.svg
106

Mise en œuvre§

107

Pour aller plus loin§

108

Se documenter§

109

Autres outils de gestion de version§

Mercurial

110

Un dernier conseil§

Rien de tel que la pratique pour maîtriser GIT (ou tout autre outil de gestion de version), alors n'hésitez pas à utiliser abondamment ces outils, même pour vos petits projets...

111

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.

112