Une introduction au gestionnaire de version Git.
Partir de rien ou de la connaissance d’autres VCS pour arriver à une installation fonctionnelle de Git et des opérations de base.
Licence : CC-BY-SA-NC. Pas d'utilisation commerciale = utilisation en formation rémunérée interdite. Me contacter pour un tel usage.
Git ʙ Découverte
Session 1 / 4
Matti Schneider
@matti_sg
Les éléments soulignés dans les notes signifient qu'il faut passer à l'étape suivante de
l'animation interne à la slide (soit la page suivante dans le PDF).
2
• Matti Schneider (mattischneider.fr)
2
• Matti Schneider (mattischneider.fr)
• fin d’études chez Eurogiciel
2
• Matti Schneider (mattischneider.fr)
• fin d’études chez Eurogiciel
• Git – ഁ
2
• Matti Schneider (mattischneider.fr)
• fin d’études chez Eurogiciel
• Git – ഁ
• deux ans d’expérience (plus deux avec Bazaar)
2
• Matti Schneider (mattischneider.fr)
• fin d’études chez Eurogiciel
• Git – ഁ
• deux ans d’expérience (plus deux avec Bazaar)
• intégrateur sur plusieurs dépôts publics
• github.com/MattiSG
2
• Matti Schneider (mattischneider.fr)
• fin d’études chez Eurogiciel
• Git – ഁ
• deux ans d’expérience (plus deux avec Bazaar)
• intégrateur sur plusieurs dépôts publics
• github.com/MattiSG
• nombreuses formations informelles
2
Objectifs
3
Pour ce qui est des avantages, je comparerai majoritairement à SVN. Pour les experts ClearCase, je ne serai pas capable de faire des comparaisons
pertinentes, puisque je n'ai jamais pu l'utiliser directement. Plusieurs comparatifs détaillés existent sur Internet, et gardez toutes vos questions et
remarques pour la fin de la présentation :)
Objectifs
1. Savoir ce qu’est Git.
3
Pour ce qui est des avantages, je comparerai majoritairement à SVN. Pour les experts ClearCase, je ne serai pas capable de faire des comparaisons
pertinentes, puisque je n'ai jamais pu l'utiliser directement. Plusieurs comparatifs détaillés existent sur Internet, et gardez toutes vos questions et
remarques pour la fin de la présentation :)
Objectifs
1. Savoir ce qu’est Git.
2. Ses avantages.
3
Pour ce qui est des avantages, je comparerai majoritairement à SVN. Pour les experts ClearCase, je ne serai pas capable de faire des comparaisons
pertinentes, puisque je n'ai jamais pu l'utiliser directement. Plusieurs comparatifs détaillés existent sur Internet, et gardez toutes vos questions et
remarques pour la fin de la présentation :)
Objectifs
1. Savoir ce qu’est Git.
2. Ses avantages.
3. Pouvoir débuter.
3
Pour ce qui est des avantages, je comparerai majoritairement à SVN. Pour les experts ClearCase, je ne serai pas capable de faire des comparaisons
pertinentes, puisque je n'ai jamais pu l'utiliser directement. Plusieurs comparatifs détaillés existent sur Internet, et gardez toutes vos questions et
remarques pour la fin de la présentation :)
Version Control System
4
Un VCS, en français “gestionnaire de versions”, est un outil qui a deux fonctions principales. Vous avez obligatoirement déjà utilisé un VCS, très
probablement SVN, ou encore ClearCase.
Systématiquement, l’un des objectifs est de collaborer entre plusieurs éditeurs.
Cela est rendu possible par l’autre objectif, celui de conserver la totalité de l’historique des états dans lequel un ensemble de fichiers se trouve.
Prenons l’exemple d’un fichier. On lui applique des modifications, et on aboutit à une nouvelle révision de son état.
Si l’on étend cela à plusieurs fichiers, on obtient le point de vue du VCS : un commit est un ensemble de fichiers ayant chacun atteint une révision
spécifique, et l’ensemble des modifications appliquées à des fichiers d’un commit à l’autre est un diff, soit l’ensemble des différences entre deux
commits.
Version Control System
• gestionnaire de versions
• CVS, SVN, ClearCase,
Mercurial, Bazaar,
Dropbox…
4
Un VCS, en français “gestionnaire de versions”, est un outil qui a deux fonctions principales. Vous avez obligatoirement déjà utilisé un VCS, très
probablement SVN, ou encore ClearCase.
Systématiquement, l’un des objectifs est de collaborer entre plusieurs éditeurs.
Cela est rendu possible par l’autre objectif, celui de conserver la totalité de l’historique des états dans lequel un ensemble de fichiers se trouve.
Prenons l’exemple d’un fichier. On lui applique des modifications, et on aboutit à une nouvelle révision de son état.
Si l’on étend cela à plusieurs fichiers, on obtient le point de vue du VCS : un commit est un ensemble de fichiers ayant chacun atteint une révision
spécifique, et l’ensemble des modifications appliquées à des fichiers d’un commit à l’autre est un diff, soit l’ensemble des différences entre deux
commits.
Version Control System
• gestionnaire de versions
• CVS, SVN, ClearCase,
Mercurial, Bazaar,
Dropbox…
• collaborer
4
Un VCS, en français “gestionnaire de versions”, est un outil qui a deux fonctions principales. Vous avez obligatoirement déjà utilisé un VCS, très
probablement SVN, ou encore ClearCase.
Systématiquement, l’un des objectifs est de collaborer entre plusieurs éditeurs.
Cela est rendu possible par l’autre objectif, celui de conserver la totalité de l’historique des états dans lequel un ensemble de fichiers se trouve.
Prenons l’exemple d’un fichier. On lui applique des modifications, et on aboutit à une nouvelle révision de son état.
Si l’on étend cela à plusieurs fichiers, on obtient le point de vue du VCS : un commit est un ensemble de fichiers ayant chacun atteint une révision
spécifique, et l’ensemble des modifications appliquées à des fichiers d’un commit à l’autre est un diff, soit l’ensemble des différences entre deux
commits.
Version Control System
• gestionnaire de versions
• CVS, SVN, ClearCase,
Mercurial, Bazaar,
Dropbox…
• collaborer
• sauvegarder l’historique
4
version="1.0"?>
xmlns:rdf="http://
www.w3.org/1999/02/22-
rdf-syntax-ns#">
Un VCS, en français “gestionnaire de versions”, est un outil qui a deux fonctions principales. Vous avez obligatoirement déjà utilisé un VCS, très
probablement SVN, ou encore ClearCase.
Systématiquement, l’un des objectifs est de collaborer entre plusieurs éditeurs.
Cela est rendu possible par l’autre objectif, celui de conserver la totalité de l’historique des états dans lequel un ensemble de fichiers se trouve.
Prenons l’exemple d’un fichier. On lui applique des modifications, et on aboutit à une nouvelle révision de son état.
Si l’on étend cela à plusieurs fichiers, on obtient le point de vue du VCS : un commit est un ensemble de fichiers ayant chacun atteint une révision
spécifique, et l’ensemble des modifications appliquées à des fichiers d’un commit à l’autre est un diff, soit l’ensemble des différences entre deux
commits.
Version Control System
• gestionnaire de versions
• CVS, SVN, ClearCase,
Mercurial, Bazaar,
Dropbox…
• collaborer
• sauvegarder l’historique
4
version="1.0"?>
xmlns:rdf="http://
www.w3.org/1999/02/22-
rdf-syntax-ns#">
version="1.0"?>
xmlns:rdf="http://
www.w3.org/1999/02/22-
rdf-syntax-ns#"
xmlns:contact="http://
www.w3.org/2000/10/
swap/pim/contact#">
rdf:about="contact:fullNam
e>Eric Miller
✎
Un VCS, en français “gestionnaire de versions”, est un outil qui a deux fonctions principales. Vous avez obligatoirement déjà utilisé un VCS, très
probablement SVN, ou encore ClearCase.
Systématiquement, l’un des objectifs est de collaborer entre plusieurs éditeurs.
Cela est rendu possible par l’autre objectif, celui de conserver la totalité de l’historique des états dans lequel un ensemble de fichiers se trouve.
Prenons l’exemple d’un fichier. On lui applique des modifications, et on aboutit à une nouvelle révision de son état.
Si l’on étend cela à plusieurs fichiers, on obtient le point de vue du VCS : un commit est un ensemble de fichiers ayant chacun atteint une révision
spécifique, et l’ensemble des modifications appliquées à des fichiers d’un commit à l’autre est un diff, soit l’ensemble des différences entre deux
commits.
Version Control System
• gestionnaire de versions
• CVS, SVN, ClearCase,
Mercurial, Bazaar,
Dropbox…
• collaborer
• sauvegarder l’historique
4
version="1.0"?>
xmlns:rdf="http://
www.w3.org/1999/02/22-
rdf-syntax-ns#">
version="1.0"?>
xmlns:rdf="http://
www.w3.org/1999/02/22-
rdf-syntax-ns#"
xmlns:contact="http://
www.w3.org/2000/10/
swap/pim/contact#">
rdf:about="contact:fullNam
e>Eric Miller
✎
révision
Un VCS, en français “gestionnaire de versions”, est un outil qui a deux fonctions principales. Vous avez obligatoirement déjà utilisé un VCS, très
probablement SVN, ou encore ClearCase.
Systématiquement, l’un des objectifs est de collaborer entre plusieurs éditeurs.
Cela est rendu possible par l’autre objectif, celui de conserver la totalité de l’historique des états dans lequel un ensemble de fichiers se trouve.
Prenons l’exemple d’un fichier. On lui applique des modifications, et on aboutit à une nouvelle révision de son état.
Si l’on étend cela à plusieurs fichiers, on obtient le point de vue du VCS : un commit est un ensemble de fichiers ayant chacun atteint une révision
spécifique, et l’ensemble des modifications appliquées à des fichiers d’un commit à l’autre est un diff, soit l’ensemble des différences entre deux
commits.
Version Control System
• gestionnaire de versions
• CVS, SVN, ClearCase,
Mercurial, Bazaar,
Dropbox…
• collaborer
• sauvegarder l’historique
4
version="1.0"?>
xmlns:rdf="http://
www.w3.org/1999/02/22-
rdf-syntax-ns#">
version="1.0"?>
xmlns:rdf="http://
www.w3.org/1999/02/22-
rdf-syntax-ns#"
xmlns:contact="http://
www.w3.org/2000/10/
swap/pim/contact#">
rdf:about="contact:fullNam
e>Eric Miller
✎
révision
version="1.0"?>
xmlns:rdf="http://
www.w3.org/1999/02/22-
rdf-syntax-ns#">
version="1.0"?>
xmlns:rdf="http://
www.w3.org/1999/02/22-
rdf-syntax-ns#">
Un VCS, en français “gestionnaire de versions”, est un outil qui a deux fonctions principales. Vous avez obligatoirement déjà utilisé un VCS, très
probablement SVN, ou encore ClearCase.
Systématiquement, l’un des objectifs est de collaborer entre plusieurs éditeurs.
Cela est rendu possible par l’autre objectif, celui de conserver la totalité de l’historique des états dans lequel un ensemble de fichiers se trouve.
Prenons l’exemple d’un fichier. On lui applique des modifications, et on aboutit à une nouvelle révision de son état.
Si l’on étend cela à plusieurs fichiers, on obtient le point de vue du VCS : un commit est un ensemble de fichiers ayant chacun atteint une révision
spécifique, et l’ensemble des modifications appliquées à des fichiers d’un commit à l’autre est un diff, soit l’ensemble des différences entre deux
commits.
Version Control System
• gestionnaire de versions
• CVS, SVN, ClearCase,
Mercurial, Bazaar,
Dropbox…
• collaborer
• sauvegarder l’historique
4
version="1.0"?>
xmlns:rdf="http://
www.w3.org/1999/02/22-
rdf-syntax-ns#">
version="1.0"?>
xmlns:rdf="http://
www.w3.org/1999/02/22-
rdf-syntax-ns#"
xmlns:contact="http://
www.w3.org/2000/10/
swap/pim/contact#">
rdf:about="contact:fullNam
e>Eric Miller
✎
révision
version="1.0"?>
xmlns:rdf="http://
www.w3.org/1999/02/22-
rdf-syntax-ns#">
version="1.0"?>
xmlns:rdf="http://
www.w3.org/1999/02/22-
rdf-syntax-ns#">
+++
- - -
Un VCS, en français “gestionnaire de versions”, est un outil qui a deux fonctions principales. Vous avez obligatoirement déjà utilisé un VCS, très
probablement SVN, ou encore ClearCase.
Systématiquement, l’un des objectifs est de collaborer entre plusieurs éditeurs.
Cela est rendu possible par l’autre objectif, celui de conserver la totalité de l’historique des états dans lequel un ensemble de fichiers se trouve.
Prenons l’exemple d’un fichier. On lui applique des modifications, et on aboutit à une nouvelle révision de son état.
Si l’on étend cela à plusieurs fichiers, on obtient le point de vue du VCS : un commit est un ensemble de fichiers ayant chacun atteint une révision
spécifique, et l’ensemble des modifications appliquées à des fichiers d’un commit à l’autre est un diff, soit l’ensemble des différences entre deux
commits.
Version Control System
• gestionnaire de versions
• CVS, SVN, ClearCase,
Mercurial, Bazaar,
Dropbox…
• collaborer
• sauvegarder l’historique
4
version="1.0"?>
xmlns:rdf="http://
www.w3.org/1999/02/22-
rdf-syntax-ns#">
version="1.0"?>
xmlns:rdf="http://
www.w3.org/1999/02/22-
rdf-syntax-ns#"
xmlns:contact="http://
www.w3.org/2000/10/
swap/pim/contact#">
rdf:about="contact:fullNam
e>Eric Miller
commit
commit
diff
✎
révision
version="1.0"?>
xmlns:rdf="http://
www.w3.org/1999/02/22-
rdf-syntax-ns#">
version="1.0"?>
xmlns:rdf="http://
www.w3.org/1999/02/22-
rdf-syntax-ns#">
+++
- - -
Un VCS, en français “gestionnaire de versions”, est un outil qui a deux fonctions principales. Vous avez obligatoirement déjà utilisé un VCS, très
probablement SVN, ou encore ClearCase.
Systématiquement, l’un des objectifs est de collaborer entre plusieurs éditeurs.
Cela est rendu possible par l’autre objectif, celui de conserver la totalité de l’historique des états dans lequel un ensemble de fichiers se trouve.
Prenons l’exemple d’un fichier. On lui applique des modifications, et on aboutit à une nouvelle révision de son état.
Si l’on étend cela à plusieurs fichiers, on obtient le point de vue du VCS : un commit est un ensemble de fichiers ayant chacun atteint une révision
spécifique, et l’ensemble des modifications appliquées à des fichiers d’un commit à l’autre est un diff, soit l’ensemble des différences entre deux
commits.
Branches
5
L’historique est donc un ensemble ordonné de révisions. Voici la vision de cet historique dont vous avez certainement l’habitude.
Néanmoins, dans la pratique du développement, il est quasi-systématique que plusieurs modifications soient effectuées en parallèle : l’une pour ajouter une nouvelle fonctionnalité, l’autre pour corriger un bug…
L’historique n’est donc pas linéaire. Au contraire, il s’agit d’un graphe.
On parle de branche pour chaque ensemble de commits parallèles, et de merge lorsqu’un ensemble de commits est appliqué à une autre branche.
Si vous avez l’habitude de SVN, vous avez certainement peur. SVN gère extrêmement mal les branches et, à cause de cela, le concept même de branche semble lourd, complexe, et risqué. Git rend leur utilisation tellement simple
et rapide que les branches sont utilisées plusieurs fois par jour.
Sous SVN, la création d’une branche est en réalité la création d’une copie (une “cheap copy”, certes, mais une copie néanmoins) du répertoire complet, ce qui aboutit généralement à avoir deux dossiers à la racine de tout dépôt :
“trunk” et “branches”, qui contient toutes les branches utilisées. Le tout est versionné sur le même historique linéaire, et la différence entre les branches est donc dans le contenu du commit et non dans son emplacement dans le
dépôt.
Sous Git, les branches sont réellement un ensemble de commits différents appliqués aux mêmes fichiers. Le passage d’une branche à l’autre se fait en place, c’est-à-dire que les fichiers sont directement modifiés, au lieu d’avoir
plusieurs répertoires contenant des versions différentes. Vous n’avez donc pas à reconfigurer votre environnement de travail (IDE, ligne de commande…) pour changer de branche. Les conflits sont également bien mieux gérés
sous Git. Git ne se repose pas sur les chemins des fichiers pour déterminer les modifications. Ainsi, les refactors sont beaucoup mieux suivis que sous SVN, où tout renommage doit être explicité, par exemple.
Branches
• historique
5
L’historique est donc un ensemble ordonné de révisions. Voici la vision de cet historique dont vous avez certainement l’habitude.
Néanmoins, dans la pratique du développement, il est quasi-systématique que plusieurs modifications soient effectuées en parallèle : l’une pour ajouter une nouvelle fonctionnalité, l’autre pour corriger un bug…
L’historique n’est donc pas linéaire. Au contraire, il s’agit d’un graphe.
On parle de branche pour chaque ensemble de commits parallèles, et de merge lorsqu’un ensemble de commits est appliqué à une autre branche.
Si vous avez l’habitude de SVN, vous avez certainement peur. SVN gère extrêmement mal les branches et, à cause de cela, le concept même de branche semble lourd, complexe, et risqué. Git rend leur utilisation tellement simple
et rapide que les branches sont utilisées plusieurs fois par jour.
Sous SVN, la création d’une branche est en réalité la création d’une copie (une “cheap copy”, certes, mais une copie néanmoins) du répertoire complet, ce qui aboutit généralement à avoir deux dossiers à la racine de tout dépôt :
“trunk” et “branches”, qui contient toutes les branches utilisées. Le tout est versionné sur le même historique linéaire, et la différence entre les branches est donc dans le contenu du commit et non dans son emplacement dans le
dépôt.
Sous Git, les branches sont réellement un ensemble de commits différents appliqués aux mêmes fichiers. Le passage d’une branche à l’autre se fait en place, c’est-à-dire que les fichiers sont directement modifiés, au lieu d’avoir
plusieurs répertoires contenant des versions différentes. Vous n’avez donc pas à reconfigurer votre environnement de travail (IDE, ligne de commande…) pour changer de branche. Les conflits sont également bien mieux gérés
sous Git. Git ne se repose pas sur les chemins des fichiers pour déterminer les modifications. Ainsi, les refactors sont beaucoup mieux suivis que sous SVN, où tout renommage doit être explicité, par exemple.
Branches
• historique
5
L’historique est donc un ensemble ordonné de révisions. Voici la vision de cet historique dont vous avez certainement l’habitude.
Néanmoins, dans la pratique du développement, il est quasi-systématique que plusieurs modifications soient effectuées en parallèle : l’une pour ajouter une nouvelle fonctionnalité, l’autre pour corriger un bug…
L’historique n’est donc pas linéaire. Au contraire, il s’agit d’un graphe.
On parle de branche pour chaque ensemble de commits parallèles, et de merge lorsqu’un ensemble de commits est appliqué à une autre branche.
Si vous avez l’habitude de SVN, vous avez certainement peur. SVN gère extrêmement mal les branches et, à cause de cela, le concept même de branche semble lourd, complexe, et risqué. Git rend leur utilisation tellement simple
et rapide que les branches sont utilisées plusieurs fois par jour.
Sous SVN, la création d’une branche est en réalité la création d’une copie (une “cheap copy”, certes, mais une copie néanmoins) du répertoire complet, ce qui aboutit généralement à avoir deux dossiers à la racine de tout dépôt :
“trunk” et “branches”, qui contient toutes les branches utilisées. Le tout est versionné sur le même historique linéaire, et la différence entre les branches est donc dans le contenu du commit et non dans son emplacement dans le
dépôt.
Sous Git, les branches sont réellement un ensemble de commits différents appliqués aux mêmes fichiers. Le passage d’une branche à l’autre se fait en place, c’est-à-dire que les fichiers sont directement modifiés, au lieu d’avoir
plusieurs répertoires contenant des versions différentes. Vous n’avez donc pas à reconfigurer votre environnement de travail (IDE, ligne de commande…) pour changer de branche. Les conflits sont également bien mieux gérés
sous Git. Git ne se repose pas sur les chemins des fichiers pour déterminer les modifications. Ainsi, les refactors sont beaucoup mieux suivis que sous SVN, où tout renommage doit être explicité, par exemple.
Branches
• historique
• non-linéaire
• graphe orienté acyclique
5
L’historique est donc un ensemble ordonné de révisions. Voici la vision de cet historique dont vous avez certainement l’habitude.
Néanmoins, dans la pratique du développement, il est quasi-systématique que plusieurs modifications soient effectuées en parallèle : l’une pour ajouter une nouvelle fonctionnalité, l’autre pour corriger un bug…
L’historique n’est donc pas linéaire. Au contraire, il s’agit d’un graphe.
On parle de branche pour chaque ensemble de commits parallèles, et de merge lorsqu’un ensemble de commits est appliqué à une autre branche.
Si vous avez l’habitude de SVN, vous avez certainement peur. SVN gère extrêmement mal les branches et, à cause de cela, le concept même de branche semble lourd, complexe, et risqué. Git rend leur utilisation tellement simple
et rapide que les branches sont utilisées plusieurs fois par jour.
Sous SVN, la création d’une branche est en réalité la création d’une copie (une “cheap copy”, certes, mais une copie néanmoins) du répertoire complet, ce qui aboutit généralement à avoir deux dossiers à la racine de tout dépôt :
“trunk” et “branches”, qui contient toutes les branches utilisées. Le tout est versionné sur le même historique linéaire, et la différence entre les branches est donc dans le contenu du commit et non dans son emplacement dans le
dépôt.
Sous Git, les branches sont réellement un ensemble de commits différents appliqués aux mêmes fichiers. Le passage d’une branche à l’autre se fait en place, c’est-à-dire que les fichiers sont directement modifiés, au lieu d’avoir
plusieurs répertoires contenant des versions différentes. Vous n’avez donc pas à reconfigurer votre environnement de travail (IDE, ligne de commande…) pour changer de branche. Les conflits sont également bien mieux gérés
sous Git. Git ne se repose pas sur les chemins des fichiers pour déterminer les modifications. Ainsi, les refactors sont beaucoup mieux suivis que sous SVN, où tout renommage doit être explicité, par exemple.
Branches
• historique
• non-linéaire
• graphe orienté acyclique
5
branche branche
intégration
(merge)
L’historique est donc un ensemble ordonné de révisions. Voici la vision de cet historique dont vous avez certainement l’habitude.
Néanmoins, dans la pratique du développement, il est quasi-systématique que plusieurs modifications soient effectuées en parallèle : l’une pour ajouter une nouvelle fonctionnalité, l’autre pour corriger un bug…
L’historique n’est donc pas linéaire. Au contraire, il s’agit d’un graphe.
On parle de branche pour chaque ensemble de commits parallèles, et de merge lorsqu’un ensemble de commits est appliqué à une autre branche.
Si vous avez l’habitude de SVN, vous avez certainement peur. SVN gère extrêmement mal les branches et, à cause de cela, le concept même de branche semble lourd, complexe, et risqué. Git rend leur utilisation tellement simple
et rapide que les branches sont utilisées plusieurs fois par jour.
Sous SVN, la création d’une branche est en réalité la création d’une copie (une “cheap copy”, certes, mais une copie néanmoins) du répertoire complet, ce qui aboutit généralement à avoir deux dossiers à la racine de tout dépôt :
“trunk” et “branches”, qui contient toutes les branches utilisées. Le tout est versionné sur le même historique linéaire, et la différence entre les branches est donc dans le contenu du commit et non dans son emplacement dans le
dépôt.
Sous Git, les branches sont réellement un ensemble de commits différents appliqués aux mêmes fichiers. Le passage d’une branche à l’autre se fait en place, c’est-à-dire que les fichiers sont directement modifiés, au lieu d’avoir
plusieurs répertoires contenant des versions différentes. Vous n’avez donc pas à reconfigurer votre environnement de travail (IDE, ligne de commande…) pour changer de branche. Les conflits sont également bien mieux gérés
sous Git. Git ne se repose pas sur les chemins des fichiers pour déterminer les modifications. Ainsi, les refactors sont beaucoup mieux suivis que sous SVN, où tout renommage doit être explicité, par exemple.
Branches
• historique
• non-linéaire
• graphe orienté acyclique
• très simple avec Git
5
branche branche
intégration
(merge)
L’historique est donc un ensemble ordonné de révisions. Voici la vision de cet historique dont vous avez certainement l’habitude.
Néanmoins, dans la pratique du développement, il est quasi-systématique que plusieurs modifications soient effectuées en parallèle : l’une pour ajouter une nouvelle fonctionnalité, l’autre pour corriger un bug…
L’historique n’est donc pas linéaire. Au contraire, il s’agit d’un graphe.
On parle de branche pour chaque ensemble de commits parallèles, et de merge lorsqu’un ensemble de commits est appliqué à une autre branche.
Si vous avez l’habitude de SVN, vous avez certainement peur. SVN gère extrêmement mal les branches et, à cause de cela, le concept même de branche semble lourd, complexe, et risqué. Git rend leur utilisation tellement simple
et rapide que les branches sont utilisées plusieurs fois par jour.
Sous SVN, la création d’une branche est en réalité la création d’une copie (une “cheap copy”, certes, mais une copie néanmoins) du répertoire complet, ce qui aboutit généralement à avoir deux dossiers à la racine de tout dépôt :
“trunk” et “branches”, qui contient toutes les branches utilisées. Le tout est versionné sur le même historique linéaire, et la différence entre les branches est donc dans le contenu du commit et non dans son emplacement dans le
dépôt.
Sous Git, les branches sont réellement un ensemble de commits différents appliqués aux mêmes fichiers. Le passage d’une branche à l’autre se fait en place, c’est-à-dire que les fichiers sont directement modifiés, au lieu d’avoir
plusieurs répertoires contenant des versions différentes. Vous n’avez donc pas à reconfigurer votre environnement de travail (IDE, ligne de commande…) pour changer de branche. Les conflits sont également bien mieux gérés
sous Git. Git ne se repose pas sur les chemins des fichiers pour déterminer les modifications. Ainsi, les refactors sont beaucoup mieux suivis que sous SVN, où tout renommage doit être explicité, par exemple.
Branches
• historique
• non-linéaire
• graphe orienté acyclique
• très simple avec Git
• changement “en place”
5
branche branche
intégration
(merge)
L’historique est donc un ensemble ordonné de révisions. Voici la vision de cet historique dont vous avez certainement l’habitude.
Néanmoins, dans la pratique du développement, il est quasi-systématique que plusieurs modifications soient effectuées en parallèle : l’une pour ajouter une nouvelle fonctionnalité, l’autre pour corriger un bug…
L’historique n’est donc pas linéaire. Au contraire, il s’agit d’un graphe.
On parle de branche pour chaque ensemble de commits parallèles, et de merge lorsqu’un ensemble de commits est appliqué à une autre branche.
Si vous avez l’habitude de SVN, vous avez certainement peur. SVN gère extrêmement mal les branches et, à cause de cela, le concept même de branche semble lourd, complexe, et risqué. Git rend leur utilisation tellement simple
et rapide que les branches sont utilisées plusieurs fois par jour.
Sous SVN, la création d’une branche est en réalité la création d’une copie (une “cheap copy”, certes, mais une copie néanmoins) du répertoire complet, ce qui aboutit généralement à avoir deux dossiers à la racine de tout dépôt :
“trunk” et “branches”, qui contient toutes les branches utilisées. Le tout est versionné sur le même historique linéaire, et la différence entre les branches est donc dans le contenu du commit et non dans son emplacement dans le
dépôt.
Sous Git, les branches sont réellement un ensemble de commits différents appliqués aux mêmes fichiers. Le passage d’une branche à l’autre se fait en place, c’est-à-dire que les fichiers sont directement modifiés, au lieu d’avoir
plusieurs répertoires contenant des versions différentes. Vous n’avez donc pas à reconfigurer votre environnement de travail (IDE, ligne de commande…) pour changer de branche. Les conflits sont également bien mieux gérés
sous Git. Git ne se repose pas sur les chemins des fichiers pour déterminer les modifications. Ainsi, les refactors sont beaucoup mieux suivis que sous SVN, où tout renommage doit être explicité, par exemple.
Branches
• historique
• non-linéaire
• graphe orienté acyclique
• très simple avec Git
• changement “en place”
• versionné par contenu
et non par chemin
5
branche branche
intégration
(merge)
L’historique est donc un ensemble ordonné de révisions. Voici la vision de cet historique dont vous avez certainement l’habitude.
Néanmoins, dans la pratique du développement, il est quasi-systématique que plusieurs modifications soient effectuées en parallèle : l’une pour ajouter une nouvelle fonctionnalité, l’autre pour corriger un bug…
L’historique n’est donc pas linéaire. Au contraire, il s’agit d’un graphe.
On parle de branche pour chaque ensemble de commits parallèles, et de merge lorsqu’un ensemble de commits est appliqué à une autre branche.
Si vous avez l’habitude de SVN, vous avez certainement peur. SVN gère extrêmement mal les branches et, à cause de cela, le concept même de branche semble lourd, complexe, et risqué. Git rend leur utilisation tellement simple
et rapide que les branches sont utilisées plusieurs fois par jour.
Sous SVN, la création d’une branche est en réalité la création d’une copie (une “cheap copy”, certes, mais une copie néanmoins) du répertoire complet, ce qui aboutit généralement à avoir deux dossiers à la racine de tout dépôt :
“trunk” et “branches”, qui contient toutes les branches utilisées. Le tout est versionné sur le même historique linéaire, et la différence entre les branches est donc dans le contenu du commit et non dans son emplacement dans le
dépôt.
Sous Git, les branches sont réellement un ensemble de commits différents appliqués aux mêmes fichiers. Le passage d’une branche à l’autre se fait en place, c’est-à-dire que les fichiers sont directement modifiés, au lieu d’avoir
plusieurs répertoires contenant des versions différentes. Vous n’avez donc pas à reconfigurer votre environnement de travail (IDE, ligne de commande…) pour changer de branche. Les conflits sont également bien mieux gérés
sous Git. Git ne se repose pas sur les chemins des fichiers pour déterminer les modifications. Ainsi, les refactors sont beaucoup mieux suivis que sous SVN, où tout renommage doit être explicité, par exemple.
DVCS
6
Git est un DVCS, c’est-à-dire un système de gestion de versions distribué.
Cela signifie que chaque machine travaillant sur un dépôt possède une copie complète de l’historique commun.
Cette structure rend le processus beaucoup plus résilient : même en cas d’inaccessibilité complète (crash) ou temporaire (problèmes réseau) du
serveur central, les données sont récupérables sur chacune des machines clientes.
De même, les opérations sur l’historique sont bien plus rapides, puisqu’aucune opération ne nécessite d’accès réseau.
Enfin, ce système offre une extrême liberté sur les processus organisationnels, puisqu’étant distribué, il permet de transmettre des modifications
en pair à pair sans nécessairement passer par un serveur central.
DVCS
6
Git est un DVCS, c’est-à-dire un système de gestion de versions distribué.
Cela signifie que chaque machine travaillant sur un dépôt possède une copie complète de l’historique commun.
Cette structure rend le processus beaucoup plus résilient : même en cas d’inaccessibilité complète (crash) ou temporaire (problèmes réseau) du
serveur central, les données sont récupérables sur chacune des machines clientes.
De même, les opérations sur l’historique sont bien plus rapides, puisqu’aucune opération ne nécessite d’accès réseau.
Enfin, ce système offre une extrême liberté sur les processus organisationnels, puisqu’étant distribué, il permet de transmettre des modifications
en pair à pair sans nécessairement passer par un serveur central.
DVCS
• distribué
6
Git est un DVCS, c’est-à-dire un système de gestion de versions distribué.
Cela signifie que chaque machine travaillant sur un dépôt possède une copie complète de l’historique commun.
Cette structure rend le processus beaucoup plus résilient : même en cas d’inaccessibilité complète (crash) ou temporaire (problèmes réseau) du
serveur central, les données sont récupérables sur chacune des machines clientes.
De même, les opérations sur l’historique sont bien plus rapides, puisqu’aucune opération ne nécessite d’accès réseau.
Enfin, ce système offre une extrême liberté sur les processus organisationnels, puisqu’étant distribué, il permet de transmettre des modifications
en pair à pair sans nécessairement passer par un serveur central.
DVCS
• distribué
6
Git est un DVCS, c’est-à-dire un système de gestion de versions distribué.
Cela signifie que chaque machine travaillant sur un dépôt possède une copie complète de l’historique commun.
Cette structure rend le processus beaucoup plus résilient : même en cas d’inaccessibilité complète (crash) ou temporaire (problèmes réseau) du
serveur central, les données sont récupérables sur chacune des machines clientes.
De même, les opérations sur l’historique sont bien plus rapides, puisqu’aucune opération ne nécessite d’accès réseau.
Enfin, ce système offre une extrême liberté sur les processus organisationnels, puisqu’étant distribué, il permet de transmettre des modifications
en pair à pair sans nécessairement passer par un serveur central.
DVCS
• distribué
• historique complet
sur chaque machine
6
Git est un DVCS, c’est-à-dire un système de gestion de versions distribué.
Cela signifie que chaque machine travaillant sur un dépôt possède une copie complète de l’historique commun.
Cette structure rend le processus beaucoup plus résilient : même en cas d’inaccessibilité complète (crash) ou temporaire (problèmes réseau) du
serveur central, les données sont récupérables sur chacune des machines clientes.
De même, les opérations sur l’historique sont bien plus rapides, puisqu’aucune opération ne nécessite d’accès réseau.
Enfin, ce système offre une extrême liberté sur les processus organisationnels, puisqu’étant distribué, il permet de transmettre des modifications
en pair à pair sans nécessairement passer par un serveur central.
DVCS
• distribué
• historique complet
sur chaque machine
6
dépôt
(repositery)
Git est un DVCS, c’est-à-dire un système de gestion de versions distribué.
Cela signifie que chaque machine travaillant sur un dépôt possède une copie complète de l’historique commun.
Cette structure rend le processus beaucoup plus résilient : même en cas d’inaccessibilité complète (crash) ou temporaire (problèmes réseau) du
serveur central, les données sont récupérables sur chacune des machines clientes.
De même, les opérations sur l’historique sont bien plus rapides, puisqu’aucune opération ne nécessite d’accès réseau.
Enfin, ce système offre une extrême liberté sur les processus organisationnels, puisqu’étant distribué, il permet de transmettre des modifications
en pair à pair sans nécessairement passer par un serveur central.
DVCS
• distribué
• historique complet
sur chaque machine
• résilient
6
dépôt
(repositery)
Git est un DVCS, c’est-à-dire un système de gestion de versions distribué.
Cela signifie que chaque machine travaillant sur un dépôt possède une copie complète de l’historique commun.
Cette structure rend le processus beaucoup plus résilient : même en cas d’inaccessibilité complète (crash) ou temporaire (problèmes réseau) du
serveur central, les données sont récupérables sur chacune des machines clientes.
De même, les opérations sur l’historique sont bien plus rapides, puisqu’aucune opération ne nécessite d’accès réseau.
Enfin, ce système offre une extrême liberté sur les processus organisationnels, puisqu’étant distribué, il permet de transmettre des modifications
en pair à pair sans nécessairement passer par un serveur central.
DVCS
• distribué
• historique complet
sur chaque machine
• résilient
• rapide !
6
dépôt
(repositery)
Git est un DVCS, c’est-à-dire un système de gestion de versions distribué.
Cela signifie que chaque machine travaillant sur un dépôt possède une copie complète de l’historique commun.
Cette structure rend le processus beaucoup plus résilient : même en cas d’inaccessibilité complète (crash) ou temporaire (problèmes réseau) du
serveur central, les données sont récupérables sur chacune des machines clientes.
De même, les opérations sur l’historique sont bien plus rapides, puisqu’aucune opération ne nécessite d’accès réseau.
Enfin, ce système offre une extrême liberté sur les processus organisationnels, puisqu’étant distribué, il permet de transmettre des modifications
en pair à pair sans nécessairement passer par un serveur central.
DVCS
• distribué
• historique complet
sur chaque machine
• résilient
• rapide !
• pair-à-pair
6
dépôt
(repositery)
Git est un DVCS, c’est-à-dire un système de gestion de versions distribué.
Cela signifie que chaque machine travaillant sur un dépôt possède une copie complète de l’historique commun.
Cette structure rend le processus beaucoup plus résilient : même en cas d’inaccessibilité complète (crash) ou temporaire (problèmes réseau) du
serveur central, les données sont récupérables sur chacune des machines clientes.
De même, les opérations sur l’historique sont bien plus rapides, puisqu’aucune opération ne nécessite d’accès réseau.
Enfin, ce système offre une extrême liberté sur les processus organisationnels, puisqu’étant distribué, il permet de transmettre des modifications
en pair à pair sans nécessairement passer par un serveur central.
Histoire
7
Linus Torvalds, créateur et développeur du noyau Linux.
Le noyau Linux était versionné par BitKeeper, un logiciel propriétaire, depuis 2002.
En 2005, BitKeeper a cessé d’offrir une version gratuite, et a refusé de fournir des licences commerciales aux développeurs de l’OSDL (Open Source
Development Labs), dont Linus Torvalds.
Aucun VCS existant ne répondait à ses exigences, en termes d’usabilité (“when in doubt, do exactly the opposite of CVS”) et de performance.
Il commença donc à travailler à un nouveau système de gestion de versions, au départ spécifiquement pour le noyau Linux. Le projet fut
rapidement repris et élargi pour devenir un VCS complet.
Aujourd’hui, toute l’industrie adopte Git. Morale : don’t mess with Open-Source ;)
Histoire
7
Linus Torvalds, créateur et développeur du noyau Linux.
Le noyau Linux était versionné par BitKeeper, un logiciel propriétaire, depuis 2002.
En 2005, BitKeeper a cessé d’offrir une version gratuite, et a refusé de fournir des licences commerciales aux développeurs de l’OSDL (Open Source
Development Labs), dont Linus Torvalds.
Aucun VCS existant ne répondait à ses exigences, en termes d’usabilité (“when in doubt, do exactly the opposite of CVS”) et de performance.
Il commença donc à travailler à un nouveau système de gestion de versions, au départ spécifiquement pour le noyau Linux. Le projet fut
rapidement repris et élargi pour devenir un VCS complet.
Aujourd’hui, toute l’industrie adopte Git. Morale : don’t mess with Open-Source ;)
Histoire
7
Linus Torvalds, créateur et développeur du noyau Linux.
Le noyau Linux était versionné par BitKeeper, un logiciel propriétaire, depuis 2002.
En 2005, BitKeeper a cessé d’offrir une version gratuite, et a refusé de fournir des licences commerciales aux développeurs de l’OSDL (Open Source
Development Labs), dont Linus Torvalds.
Aucun VCS existant ne répondait à ses exigences, en termes d’usabilité (“when in doubt, do exactly the opposite of CVS”) et de performance.
Il commença donc à travailler à un nouveau système de gestion de versions, au départ spécifiquement pour le noyau Linux. Le projet fut
rapidement repris et élargi pour devenir un VCS complet.
Aujourd’hui, toute l’industrie adopte Git. Morale : don’t mess with Open-Source ;)
Installation
8
Il faut bien entendu installer Git. Il est écrit en C, n’a aucune dépendance spécifique, et est précompilé pour la quasi-totalité des plateformes et
disponible sur tous les dépôts Linux.
Pour simplifier l'utilisation, vous pouvez également installer un plugin pour votre IDE, le navigateur de fichiers de votre OS, etc.
Je vous conseille très fortement l’utilisation d’une interface graphique. Il ne s’agit pas d’un simple bonus, mais d’un gain réel à l’usage : un
support visuel à la gestion des branches et à l’ajout d’éléments aux commits devient vite extrêmement utile. Si vous n’avez pas de vue graphique,
vous vous limiterez très vite à n’utiliser qu’un sous-ensemble des possibilités de Git.
Installation
• exécutable (C)
• git-scm.com
8
Il faut bien entendu installer Git. Il est écrit en C, n’a aucune dépendance spécifique, et est précompilé pour la quasi-totalité des plateformes et
disponible sur tous les dépôts Linux.
Pour simplifier l'utilisation, vous pouvez également installer un plugin pour votre IDE, le navigateur de fichiers de votre OS, etc.
Je vous conseille très fortement l’utilisation d’une interface graphique. Il ne s’agit pas d’un simple bonus, mais d’un gain réel à l’usage : un
support visuel à la gestion des branches et à l’ajout d’éléments aux commits devient vite extrêmement utile. Si vous n’avez pas de vue graphique,
vous vous limiterez très vite à n’utiliser qu’un sous-ensemble des possibilités de Git.
Installation
• exécutable (C)
• git-scm.com
• plugins
• IDE, explorateur fichiers…
8
Il faut bien entendu installer Git. Il est écrit en C, n’a aucune dépendance spécifique, et est précompilé pour la quasi-totalité des plateformes et
disponible sur tous les dépôts Linux.
Pour simplifier l'utilisation, vous pouvez également installer un plugin pour votre IDE, le navigateur de fichiers de votre OS, etc.
Je vous conseille très fortement l’utilisation d’une interface graphique. Il ne s’agit pas d’un simple bonus, mais d’un gain réel à l’usage : un
support visuel à la gestion des branches et à l’ajout d’éléments aux commits devient vite extrêmement utile. Si vous n’avez pas de vue graphique,
vous vous limiterez très vite à n’utiliser qu’un sous-ensemble des possibilités de Git.
Installation
• exécutable (C)
• git-scm.com
• plugins
• IDE, explorateur fichiers…
• GUI
• Windows : GitExtensions
• OS X : GitX
• Linux : GitG, Kgit, Cgit…
8
Il faut bien entendu installer Git. Il est écrit en C, n’a aucune dépendance spécifique, et est précompilé pour la quasi-totalité des plateformes et
disponible sur tous les dépôts Linux.
Pour simplifier l'utilisation, vous pouvez également installer un plugin pour votre IDE, le navigateur de fichiers de votre OS, etc.
Je vous conseille très fortement l’utilisation d’une interface graphique. Il ne s’agit pas d’un simple bonus, mais d’un gain réel à l’usage : un
support visuel à la gestion des branches et à l’ajout d’éléments aux commits devient vite extrêmement utile. Si vous n’avez pas de vue graphique,
vous vous limiterez très vite à n’utiliser qu’un sous-ensemble des possibilités de Git.
Installation
• exécutable (C)
• git-scm.com
• plugins
• IDE, explorateur fichiers…
• GUI
• Windows : GitExtensions
• OS X : GitX
• Linux : GitG, Kgit, Cgit…
8
Il faut bien entendu installer Git. Il est écrit en C, n’a aucune dépendance spécifique, et est précompilé pour la quasi-totalité des plateformes et
disponible sur tous les dépôts Linux.
Pour simplifier l'utilisation, vous pouvez également installer un plugin pour votre IDE, le navigateur de fichiers de votre OS, etc.
Je vous conseille très fortement l’utilisation d’une interface graphique. Il ne s’agit pas d’un simple bonus, mais d’un gain réel à l’usage : un
support visuel à la gestion des branches et à l’ajout d’éléments aux commits devient vite extrêmement utile. Si vous n’avez pas de vue graphique,
vous vous limiterez très vite à n’utiliser qu’un sous-ensemble des possibilités de Git.
Configuration
9
Git associera votre identité à chaque commit, il est donc vital pour la traçabilité du code que vous renseigniez correctement ces informations.
Les fins de ligne sont différentes entre Windows et les autres OS. Pour éviter tout problème de compatibilité, Git peut convertir les fins de ligne à la volée. Sous Windows, on va donc
demander de transformer en CRLF lors de la récupération des modifications, et de re-convertir en LF lors de l’envoi.
Sous les autres OS, on demandera l’utilisation systématique de LF. Voir http://help.github.com/line-endings/
Toutes les informations de configuration stockées en “--global” sont enregistrées dans un fichier à la racine de votre répertoire utilisateur (~/.gitconfig).
Enfin, la création d’une clé SSH sera rapidement nécessaire pour toute authentification avec Git. Il vous faudra donc en générer au moins une. Voir http://www.git-attitude.fr/2010/09/13/
comprendre-et-maitriser-les-cles-ssh/
Configuration
• identification
9
Git associera votre identité à chaque commit, il est donc vital pour la traçabilité du code que vous renseigniez correctement ces informations.
Les fins de ligne sont différentes entre Windows et les autres OS. Pour éviter tout problème de compatibilité, Git peut convertir les fins de ligne à la volée. Sous Windows, on va donc
demander de transformer en CRLF lors de la récupération des modifications, et de re-convertir en LF lors de l’envoi.
Sous les autres OS, on demandera l’utilisation systématique de LF. Voir http://help.github.com/line-endings/
Toutes les informations de configuration stockées en “--global” sont enregistrées dans un fichier à la racine de votre répertoire utilisateur (~/.gitconfig).
Enfin, la création d’une clé SSH sera rapidement nécessaire pour toute authentification avec Git. Il vous faudra donc en générer au moins une. Voir http://www.git-attitude.fr/2010/09/13/
comprendre-et-maitriser-les-cles-ssh/
Configuration
• identification
git config --global user.name "Prénom Nom"
git config --global user.email "[email protected]"
9
Git associera votre identité à chaque commit, il est donc vital pour la traçabilité du code que vous renseigniez correctement ces informations.
Les fins de ligne sont différentes entre Windows et les autres OS. Pour éviter tout problème de compatibilité, Git peut convertir les fins de ligne à la volée. Sous Windows, on va donc
demander de transformer en CRLF lors de la récupération des modifications, et de re-convertir en LF lors de l’envoi.
Sous les autres OS, on demandera l’utilisation systématique de LF. Voir http://help.github.com/line-endings/
Toutes les informations de configuration stockées en “--global” sont enregistrées dans un fichier à la racine de votre répertoire utilisateur (~/.gitconfig).
Enfin, la création d’une clé SSH sera rapidement nécessaire pour toute authentification avec Git. Il vous faudra donc en générer au moins une. Voir http://www.git-attitude.fr/2010/09/13/
comprendre-et-maitriser-les-cles-ssh/
Configuration
• identification
git config --global user.name "Prénom Nom"
git config --global user.email "[email protected]"
• fins de lignes
• sous Windows
git config --global core.autocrlf true
• autres
git config --global core.autocrlf input
9
Git associera votre identité à chaque commit, il est donc vital pour la traçabilité du code que vous renseigniez correctement ces informations.
Les fins de ligne sont différentes entre Windows et les autres OS. Pour éviter tout problème de compatibilité, Git peut convertir les fins de ligne à la volée. Sous Windows, on va donc
demander de transformer en CRLF lors de la récupération des modifications, et de re-convertir en LF lors de l’envoi.
Sous les autres OS, on demandera l’utilisation systématique de LF. Voir http://help.github.com/line-endings/
Toutes les informations de configuration stockées en “--global” sont enregistrées dans un fichier à la racine de votre répertoire utilisateur (~/.gitconfig).
Enfin, la création d’une clé SSH sera rapidement nécessaire pour toute authentification avec Git. Il vous faudra donc en générer au moins une. Voir http://www.git-attitude.fr/2010/09/13/
comprendre-et-maitriser-les-cles-ssh/
Configuration
• identification
git config --global user.name "Prénom Nom"
git config --global user.email "[email protected]"
• fins de lignes
• sous Windows
git config --global core.autocrlf true
• autres
git config --global core.autocrlf input
• clé SSH
• Putty sous Windows, ssh-keygen ailleurs
9
Git associera votre identité à chaque commit, il est donc vital pour la traçabilité du code que vous renseigniez correctement ces informations.
Les fins de ligne sont différentes entre Windows et les autres OS. Pour éviter tout problème de compatibilité, Git peut convertir les fins de ligne à la volée. Sous Windows, on va donc
demander de transformer en CRLF lors de la récupération des modifications, et de re-convertir en LF lors de l’envoi.
Sous les autres OS, on demandera l’utilisation systématique de LF. Voir http://help.github.com/line-endings/
Toutes les informations de configuration stockées en “--global” sont enregistrées dans un fichier à la racine de votre répertoire utilisateur (~/.gitconfig).
Enfin, la création d’une clé SSH sera rapidement nécessaire pour toute authentification avec Git. Il vous faudra donc en générer au moins une. Voir http://www.git-attitude.fr/2010/09/13/
comprendre-et-maitriser-les-cles-ssh/
Création d'un dépôt
10
La création d'un dépôt Git est très simple.
Supposons que l'on veuille versionner un projet.
La commande “git init” va créer un dossier invisible .git, qui contient la totalité du dépôt, c'est-à-dire toutes les branches et tout l'historique des révisions. Contrairement à SVN qui ajoute
des dossiers invisibles .svn de manière récursive, seul ce dossier à la racine du dossier versionné est utilisé. Cela signifie donc que l'export d'une version spécifique est plus simple qu'avec
SVN, qu'il faudrait nettoyer.
Appliquons une modification dans ce dépôt tout neuf.
Pour obtenir des informations sur les fichiers modifiés depuis le dernier commit, on utilise la commande “status”, comme dans la majorité des VCS.
Git nous informe de la présence d'un fichier non connu, “untracked”.
Comme vous le voyez, Git met immédiatement l'emphase sur la branche actuelle. Nous verrons plus loin comment gérer les branches.
Création d'un dépôt
$ cd "Colors list"
10
Colors
list
La création d'un dépôt Git est très simple.
Supposons que l'on veuille versionner un projet.
La commande “git init” va créer un dossier invisible .git, qui contient la totalité du dépôt, c'est-à-dire toutes les branches et tout l'historique des révisions. Contrairement à SVN qui ajoute
des dossiers invisibles .svn de manière récursive, seul ce dossier à la racine du dossier versionné est utilisé. Cela signifie donc que l'export d'une version spécifique est plus simple qu'avec
SVN, qu'il faudrait nettoyer.
Appliquons une modification dans ce dépôt tout neuf.
Pour obtenir des informations sur les fichiers modifiés depuis le dernier commit, on utilise la commande “status”, comme dans la majorité des VCS.
Git nous informe de la présence d'un fichier non connu, “untracked”.
Comme vous le voyez, Git met immédiatement l'emphase sur la branche actuelle. Nous verrons plus loin comment gérer les branches.
Création d'un dépôt
$ cd "Colors list"
$ git init
Initialized empty Git repository
10
Colors
list
config
.git
HEAD
La création d'un dépôt Git est très simple.
Supposons que l'on veuille versionner un projet.
La commande “git init” va créer un dossier invisible .git, qui contient la totalité du dépôt, c'est-à-dire toutes les branches et tout l'historique des révisions. Contrairement à SVN qui ajoute
des dossiers invisibles .svn de manière récursive, seul ce dossier à la racine du dossier versionné est utilisé. Cela signifie donc que l'export d'une version spécifique est plus simple qu'avec
SVN, qu'il faudrait nettoyer.
Appliquons une modification dans ce dépôt tout neuf.
Pour obtenir des informations sur les fichiers modifiés depuis le dernier commit, on utilise la commande “status”, comme dans la majorité des VCS.
Git nous informe de la présence d'un fichier non connu, “untracked”.
Comme vous le voyez, Git met immédiatement l'emphase sur la branche actuelle. Nous verrons plus loin comment gérer les branches.
Création d'un dépôt
$ cd "Colors list"
$ git init
Initialized empty Git repository
$ echo 'red' > colors
10
Colors
list
config
.git
HEAD
colors
La création d'un dépôt Git est très simple.
Supposons que l'on veuille versionner un projet.
La commande “git init” va créer un dossier invisible .git, qui contient la totalité du dépôt, c'est-à-dire toutes les branches et tout l'historique des révisions. Contrairement à SVN qui ajoute
des dossiers invisibles .svn de manière récursive, seul ce dossier à la racine du dossier versionné est utilisé. Cela signifie donc que l'export d'une version spécifique est plus simple qu'avec
SVN, qu'il faudrait nettoyer.
Appliquons une modification dans ce dépôt tout neuf.
Pour obtenir des informations sur les fichiers modifiés depuis le dernier commit, on utilise la commande “status”, comme dans la majorité des VCS.
Git nous informe de la présence d'un fichier non connu, “untracked”.
Comme vous le voyez, Git met immédiatement l'emphase sur la branche actuelle. Nous verrons plus loin comment gérer les branches.
Création d'un dépôt
$ cd "Colors list"
$ git init
Initialized empty Git repository
$ echo 'red' > colors
$ git status
10
Colors
list
config
.git
HEAD
colors
La création d'un dépôt Git est très simple.
Supposons que l'on veuille versionner un projet.
La commande “git init” va créer un dossier invisible .git, qui contient la totalité du dépôt, c'est-à-dire toutes les branches et tout l'historique des révisions. Contrairement à SVN qui ajoute
des dossiers invisibles .svn de manière récursive, seul ce dossier à la racine du dossier versionné est utilisé. Cela signifie donc que l'export d'une version spécifique est plus simple qu'avec
SVN, qu'il faudrait nettoyer.
Appliquons une modification dans ce dépôt tout neuf.
Pour obtenir des informations sur les fichiers modifiés depuis le dernier commit, on utilise la commande “status”, comme dans la majorité des VCS.
Git nous informe de la présence d'un fichier non connu, “untracked”.
Comme vous le voyez, Git met immédiatement l'emphase sur la branche actuelle. Nous verrons plus loin comment gérer les branches.
Création d'un dépôt
$ cd "Colors list"
$ git init
Initialized empty Git repository
$ echo 'red' > colors
$ git status
# On branch master
#
# Initial commit
#
# Untracked files:
#
# colors
nothing added to commit
but untracked files present
(use "git add" to track)
10
Colors
list
config
.git
HEAD
colors
La création d'un dépôt Git est très simple.
Supposons que l'on veuille versionner un projet.
La commande “git init” va créer un dossier invisible .git, qui contient la totalité du dépôt, c'est-à-dire toutes les branches et tout l'historique des révisions. Contrairement à SVN qui ajoute
des dossiers invisibles .svn de manière récursive, seul ce dossier à la racine du dossier versionné est utilisé. Cela signifie donc que l'export d'une version spécifique est plus simple qu'avec
SVN, qu'il faudrait nettoyer.
Appliquons une modification dans ce dépôt tout neuf.
Pour obtenir des informations sur les fichiers modifiés depuis le dernier commit, on utilise la commande “status”, comme dans la majorité des VCS.
Git nous informe de la présence d'un fichier non connu, “untracked”.
Comme vous le voyez, Git met immédiatement l'emphase sur la branche actuelle. Nous verrons plus loin comment gérer les branches.
Création d'un dépôt
$ cd "Colors list"
$ git init
Initialized empty Git repository
$ echo 'red' > colors
$ git status
# On branch master
#
# Initial commit
#
# Untracked files:
#
# colors
nothing added to commit
but untracked files present
(use "git add" to track)
10
Colors
list
config
.git
HEAD
colors
La création d'un dépôt Git est très simple.
Supposons que l'on veuille versionner un projet.
La commande “git init” va créer un dossier invisible .git, qui contient la totalité du dépôt, c'est-à-dire toutes les branches et tout l'historique des révisions. Contrairement à SVN qui ajoute
des dossiers invisibles .svn de manière récursive, seul ce dossier à la racine du dossier versionné est utilisé. Cela signifie donc que l'export d'une version spécifique est plus simple qu'avec
SVN, qu'il faudrait nettoyer.
Appliquons une modification dans ce dépôt tout neuf.
Pour obtenir des informations sur les fichiers modifiés depuis le dernier commit, on utilise la commande “status”, comme dans la majorité des VCS.
Git nous informe de la présence d'un fichier non connu, “untracked”.
Comme vous le voyez, Git met immédiatement l'emphase sur la branche actuelle. Nous verrons plus loin comment gérer les branches.
Repositery Staging
(index)
Working
directory
Aire d'assemblage
# Untracked files:
# colors
nothing added to commit
but untracked files present
(use "git add" to track)
11
Mon
projet
colors
Voyons à présent comment versionner des fichiers et suivre leurs modifications.
Dans la plupart des VCS, un fichier et soit enregistré, soit modifié. Git offre une position intermédiaire, l'“aire d'assemblage”, ou “staging area” (ou encore index). Pour commit des modifications, celles-ci
doivent d'abord être ajoutées dans l'aire d'assemblage, avec la commande add.
Si l'on demande à nouveau l'état du dépôt, Git nous informe que le fichier sera enregistré lors du commit.
L'intérêt principal de cette étape est de permettre de faire des commits réellement atomiques, une bonne pratique reconnue : vous avez commencé à coder une fonctionnalité, et ce faisant avez découvert un
bug, que vous avez corrigé… Au moment de commit, vous vous retrouvez avec un grand nombre de modifications peut-être indépendantes. Grâce à l'aire d'assemblage, vous pouvez effectuer plusieurs
commits distincts en sélectionnant les fichiers correspondants un par un.
Pour effectuer le commit à proprement parler, la commande est simplement commit, à laquelle on doit bien sûr fournir une description des modifications. Une fois exécutée, cette commande ajoutera
effectivement la révision au dépôt.
On notera que Git donne un récapitulatif du nombre de fichiers ajoutés au dépôt, qui n'est pas nécessairement le nombre de fichiers modifiés, donc, mais celui d'ajoutés à l'aire d'assemblage.
Repositery Staging
(index)
Working
directory
Aire d'assemblage
# Untracked files:
# colors
nothing added to commit
but untracked files present
(use "git add" to track)
$ git add colors
11
Mon
projet
colors
Mon
projet
colors
Voyons à présent comment versionner des fichiers et suivre leurs modifications.
Dans la plupart des VCS, un fichier et soit enregistré, soit modifié. Git offre une position intermédiaire, l'“aire d'assemblage”, ou “staging area” (ou encore index). Pour commit des modifications, celles-ci
doivent d'abord être ajoutées dans l'aire d'assemblage, avec la commande add.
Si l'on demande à nouveau l'état du dépôt, Git nous informe que le fichier sera enregistré lors du commit.
L'intérêt principal de cette étape est de permettre de faire des commits réellement atomiques, une bonne pratique reconnue : vous avez commencé à coder une fonctionnalité, et ce faisant avez découvert un
bug, que vous avez corrigé… Au moment de commit, vous vous retrouvez avec un grand nombre de modifications peut-être indépendantes. Grâce à l'aire d'assemblage, vous pouvez effectuer plusieurs
commits distincts en sélectionnant les fichiers correspondants un par un.
Pour effectuer le commit à proprement parler, la commande est simplement commit, à laquelle on doit bien sûr fournir une description des modifications. Une fois exécutée, cette commande ajoutera
effectivement la révision au dépôt.
On notera que Git donne un récapitulatif du nombre de fichiers ajoutés au dépôt, qui n'est pas nécessairement le nombre de fichiers modifiés, donc, mais celui d'ajoutés à l'aire d'assemblage.
Repositery Staging
(index)
Working
directory
Aire d'assemblage
# Untracked files:
# colors
nothing added to commit
but untracked files present
(use "git add" to track)
$ git add colors
$ git status
# Changes to be committed:
# new file: colors
11
Mon
projet
colors
Mon
projet
colors
Voyons à présent comment versionner des fichiers et suivre leurs modifications.
Dans la plupart des VCS, un fichier et soit enregistré, soit modifié. Git offre une position intermédiaire, l'“aire d'assemblage”, ou “staging area” (ou encore index). Pour commit des modifications, celles-ci
doivent d'abord être ajoutées dans l'aire d'assemblage, avec la commande add.
Si l'on demande à nouveau l'état du dépôt, Git nous informe que le fichier sera enregistré lors du commit.
L'intérêt principal de cette étape est de permettre de faire des commits réellement atomiques, une bonne pratique reconnue : vous avez commencé à coder une fonctionnalité, et ce faisant avez découvert un
bug, que vous avez corrigé… Au moment de commit, vous vous retrouvez avec un grand nombre de modifications peut-être indépendantes. Grâce à l'aire d'assemblage, vous pouvez effectuer plusieurs
commits distincts en sélectionnant les fichiers correspondants un par un.
Pour effectuer le commit à proprement parler, la commande est simplement commit, à laquelle on doit bien sûr fournir une description des modifications. Une fois exécutée, cette commande ajoutera
effectivement la révision au dépôt.
On notera que Git donne un récapitulatif du nombre de fichiers ajoutés au dépôt, qui n'est pas nécessairement le nombre de fichiers modifiés, donc, mais celui d'ajoutés à l'aire d'assemblage.
Repositery Staging
(index)
Working
directory
Aire d'assemblage
# Untracked files:
# colors
nothing added to commit
but untracked files present
(use "git add" to track)
$ git add colors
$ git status
# Changes to be committed:
# new file: colors
$ git commit -m "Put red"
11
Mon
projet
colors
Mon
projet
colors
Voyons à présent comment versionner des fichiers et suivre leurs modifications.
Dans la plupart des VCS, un fichier et soit enregistré, soit modifié. Git offre une position intermédiaire, l'“aire d'assemblage”, ou “staging area” (ou encore index). Pour commit des modifications, celles-ci
doivent d'abord être ajoutées dans l'aire d'assemblage, avec la commande add.
Si l'on demande à nouveau l'état du dépôt, Git nous informe que le fichier sera enregistré lors du commit.
L'intérêt principal de cette étape est de permettre de faire des commits réellement atomiques, une bonne pratique reconnue : vous avez commencé à coder une fonctionnalité, et ce faisant avez découvert un
bug, que vous avez corrigé… Au moment de commit, vous vous retrouvez avec un grand nombre de modifications peut-être indépendantes. Grâce à l'aire d'assemblage, vous pouvez effectuer plusieurs
commits distincts en sélectionnant les fichiers correspondants un par un.
Pour effectuer le commit à proprement parler, la commande est simplement commit, à laquelle on doit bien sûr fournir une description des modifications. Une fois exécutée, cette commande ajoutera
effectivement la révision au dépôt.
On notera que Git donne un récapitulatif du nombre de fichiers ajoutés au dépôt, qui n'est pas nécessairement le nombre de fichiers modifiés, donc, mais celui d'ajoutés à l'aire d'assemblage.
Repositery Staging
(index)
Working
directory
Aire d'assemblage
# Untracked files:
# colors
nothing added to commit
but untracked files present
(use "git add" to track)
$ git add colors
$ git status
# Changes to be committed:
# new file: colors
$ git commit -m "Put red"
[master (root-commit) bdeddb3]
Put red
1 files changed,
1 insertions(+), 0 deletions(-)
create mode 100644 colors
11
Mon
projet
colors
Mon
projet
colors
Mon
projet
colors
Voyons à présent comment versionner des fichiers et suivre leurs modifications.
Dans la plupart des VCS, un fichier et soit enregistré, soit modifié. Git offre une position intermédiaire, l'“aire d'assemblage”, ou “staging area” (ou encore index). Pour commit des modifications, celles-ci
doivent d'abord être ajoutées dans l'aire d'assemblage, avec la commande add.
Si l'on demande à nouveau l'état du dépôt, Git nous informe que le fichier sera enregistré lors du commit.
L'intérêt principal de cette étape est de permettre de faire des commits réellement atomiques, une bonne pratique reconnue : vous avez commencé à coder une fonctionnalité, et ce faisant avez découvert un
bug, que vous avez corrigé… Au moment de commit, vous vous retrouvez avec un grand nombre de modifications peut-être indépendantes. Grâce à l'aire d'assemblage, vous pouvez effectuer plusieurs
commits distincts en sélectionnant les fichiers correspondants un par un.
Pour effectuer le commit à proprement parler, la commande est simplement commit, à laquelle on doit bien sûr fournir une description des modifications. Une fois exécutée, cette commande ajoutera
effectivement la révision au dépôt.
On notera que Git donne un récapitulatif du nombre de fichiers ajoutés au dépôt, qui n'est pas nécessairement le nombre de fichiers modifiés, donc, mais celui d'ajoutés à l'aire d'assemblage.
Repositery Staging
(index)
Working
directory
Aire d'assemblage
# Untracked files:
# colors
nothing added to commit
but untracked files present
(use "git add" to track)
$ git add colors
$ git status
# Changes to be committed:
# new file: colors
$ git commit -m "Put red"
[master (root-commit) bdeddb3]
Put red
1 files changed,
1 insertions(+), 0 deletions(-)
create mode 100644 colors
11
Mon
projet
colors
Mon
projet
colors
Mon
projet
colors
Voyons à présent comment versionner des fichiers et suivre leurs modifications.
Dans la plupart des VCS, un fichier et soit enregistré, soit modifié. Git offre une position intermédiaire, l'“aire d'assemblage”, ou “staging area” (ou encore index). Pour commit des modifications, celles-ci
doivent d'abord être ajoutées dans l'aire d'assemblage, avec la commande add.
Si l'on demande à nouveau l'état du dépôt, Git nous informe que le fichier sera enregistré lors du commit.
L'intérêt principal de cette étape est de permettre de faire des commits réellement atomiques, une bonne pratique reconnue : vous avez commencé à coder une fonctionnalité, et ce faisant avez découvert un
bug, que vous avez corrigé… Au moment de commit, vous vous retrouvez avec un grand nombre de modifications peut-être indépendantes. Grâce à l'aire d'assemblage, vous pouvez effectuer plusieurs
commits distincts en sélectionnant les fichiers correspondants un par un.
Pour effectuer le commit à proprement parler, la commande est simplement commit, à laquelle on doit bien sûr fournir une description des modifications. Une fois exécutée, cette commande ajoutera
effectivement la révision au dépôt.
On notera que Git donne un récapitulatif du nombre de fichiers ajoutés au dépôt, qui n'est pas nécessairement le nombre de fichiers modifiés, donc, mais celui d'ajoutés à l'aire d'assemblage.
Repositery Staging
(index)
Working
directory
Aire d'assemblage
# Untracked files:
# colors
nothing added to commit
but untracked files present
(use "git add" to track)
$ git add colors
$ git status
# Changes to be committed:
# new file: colors
$ git commit -m "Put red"
[master (root-commit) bdeddb3]
Put red
1 files changed,
1 insertions(+), 0 deletions(-)
create mode 100644 colors
11
Mon
projet
colors
Mon
projet
colors
Mon
projet
colors
Voyons à présent comment versionner des fichiers et suivre leurs modifications.
Dans la plupart des VCS, un fichier et soit enregistré, soit modifié. Git offre une position intermédiaire, l'“aire d'assemblage”, ou “staging area” (ou encore index). Pour commit des modifications, celles-ci
doivent d'abord être ajoutées dans l'aire d'assemblage, avec la commande add.
Si l'on demande à nouveau l'état du dépôt, Git nous informe que le fichier sera enregistré lors du commit.
L'intérêt principal de cette étape est de permettre de faire des commits réellement atomiques, une bonne pratique reconnue : vous avez commencé à coder une fonctionnalité, et ce faisant avez découvert un
bug, que vous avez corrigé… Au moment de commit, vous vous retrouvez avec un grand nombre de modifications peut-être indépendantes. Grâce à l'aire d'assemblage, vous pouvez effectuer plusieurs
commits distincts en sélectionnant les fichiers correspondants un par un.
Pour effectuer le commit à proprement parler, la commande est simplement commit, à laquelle on doit bien sûr fournir une description des modifications. Une fois exécutée, cette commande ajoutera
effectivement la révision au dépôt.
On notera que Git donne un récapitulatif du nombre de fichiers ajoutés au dépôt, qui n'est pas nécessairement le nombre de fichiers modifiés, donc, mais celui d'ajoutés à l'aire d'assemblage.
SHA
[master (root-commit) bdeddb3]
Put red
1 files changed,
1 insertions(+), 0 deletions(-)
create mode 100644 colors
12
Pour obtenir l'historique des précédents commits, on utilise la commande log.
Un commit est donc décrit par son auteur (identifié par son nom et email, d'où l'importance de l'enregistrer correctement), sa date d'application, son message de description… Et par une
longue suite de chiffres et lettres. On peut d'ailleurs remarquer que cette valeur correspond à celle affichée lors du commit.
Il s'agit de l'empreinte, ou somme de contrôle, SHA1 du commit. Git identifie de manière unique chaque commit par son empreinte SHA.
Appliquons une nouvelle modification et un nouveau commit (on remarque au passage l'usage de l'option -a pour ajouter automatiquement tous les fichiers modifiés au commit).
L'empreinte de ce nouveau commit est générée bien évidemment à partir des modifications appliquées, mais également de tout l'arbre des commits précédents.
Ainsi, la corruption (accidentelle ou malveillante) d'un dépôt Git est pratiquement impossible, puisque la corruption d'une révision quelconque implique une incohérence immédiatement
détectable par la cascade des sommes de contrôle.
SHA
[master (root-commit) bdeddb3]
Put red
1 files changed,
1 insertions(+), 0 deletions(-)
create mode 100644 colors
$ git log
commit
bdeddb367771d0fd3aa5d96e3bd186311
Author: Matti Schneider
Date: Thu Apr 19 10:18:56 2012
Put red
12
Pour obtenir l'historique des précédents commits, on utilise la commande log.
Un commit est donc décrit par son auteur (identifié par son nom et email, d'où l'importance de l'enregistrer correctement), sa date d'application, son message de description… Et par une
longue suite de chiffres et lettres. On peut d'ailleurs remarquer que cette valeur correspond à celle affichée lors du commit.
Il s'agit de l'empreinte, ou somme de contrôle, SHA1 du commit. Git identifie de manière unique chaque commit par son empreinte SHA.
Appliquons une nouvelle modification et un nouveau commit (on remarque au passage l'usage de l'option -a pour ajouter automatiquement tous les fichiers modifiés au commit).
L'empreinte de ce nouveau commit est générée bien évidemment à partir des modifications appliquées, mais également de tout l'arbre des commits précédents.
Ainsi, la corruption (accidentelle ou malveillante) d'un dépôt Git est pratiquement impossible, puisque la corruption d'une révision quelconque implique une incohérence immédiatement
détectable par la cascade des sommes de contrôle.
SHA
[master (root-commit) bdeddb3]
Put red
1 files changed,
1 insertions(+), 0 deletions(-)
create mode 100644 colors
$ git log
commit
bdeddb367771d0fd3aa5d96e3bd186311
Author: Matti Schneider
Date: Thu Apr 19 10:18:56 2012
Put red
12
Pour obtenir l'historique des précédents commits, on utilise la commande log.
Un commit est donc décrit par son auteur (identifié par son nom et email, d'où l'importance de l'enregistrer correctement), sa date d'application, son message de description… Et par une
longue suite de chiffres et lettres. On peut d'ailleurs remarquer que cette valeur correspond à celle affichée lors du commit.
Il s'agit de l'empreinte, ou somme de contrôle, SHA1 du commit. Git identifie de manière unique chaque commit par son empreinte SHA.
Appliquons une nouvelle modification et un nouveau commit (on remarque au passage l'usage de l'option -a pour ajouter automatiquement tous les fichiers modifiés au commit).
L'empreinte de ce nouveau commit est générée bien évidemment à partir des modifications appliquées, mais également de tout l'arbre des commits précédents.
Ainsi, la corruption (accidentelle ou malveillante) d'un dépôt Git est pratiquement impossible, puisque la corruption d'une révision quelconque implique une incohérence immédiatement
détectable par la cascade des sommes de contrôle.
SHA
[master (root-commit) bdeddb3]
Put red
1 files changed,
1 insertions(+), 0 deletions(-)
create mode 100644 colors
$ git log
commit
bdeddb367771d0fd3aa5d96e3bd186311
Author: Matti Schneider
Date: Thu Apr 19 10:18:56 2012
Put red
12
Pour obtenir l'historique des précédents commits, on utilise la commande log.
Un commit est donc décrit par son auteur (identifié par son nom et email, d'où l'importance de l'enregistrer correctement), sa date d'application, son message de description… Et par une
longue suite de chiffres et lettres. On peut d'ailleurs remarquer que cette valeur correspond à celle affichée lors du commit.
Il s'agit de l'empreinte, ou somme de contrôle, SHA1 du commit. Git identifie de manière unique chaque commit par son empreinte SHA.
Appliquons une nouvelle modification et un nouveau commit (on remarque au passage l'usage de l'option -a pour ajouter automatiquement tous les fichiers modifiés au commit).
L'empreinte de ce nouveau commit est générée bien évidemment à partir des modifications appliquées, mais également de tout l'arbre des commits précédents.
Ainsi, la corruption (accidentelle ou malveillante) d'un dépôt Git est pratiquement impossible, puisque la corruption d'une révision quelconque implique une incohérence immédiatement
détectable par la cascade des sommes de contrôle.
SHA
[master (root-commit) bdeddb3]
Put red
1 files changed,
1 insertions(+), 0 deletions(-)
create mode 100644 colors
$ git log
commit
bdeddb367771d0fd3aa5d96e3bd186311
Author: Matti Schneider
Date: Thu Apr 19 10:18:56 2012
Put red
12
bdeddb367771d0fd3
aa5d96e3bdd186311
Pour obtenir l'historique des précédents commits, on utilise la commande log.
Un commit est donc décrit par son auteur (identifié par son nom et email, d'où l'importance de l'enregistrer correctement), sa date d'application, son message de description… Et par une
longue suite de chiffres et lettres. On peut d'ailleurs remarquer que cette valeur correspond à celle affichée lors du commit.
Il s'agit de l'empreinte, ou somme de contrôle, SHA1 du commit. Git identifie de manière unique chaque commit par son empreinte SHA.
Appliquons une nouvelle modification et un nouveau commit (on remarque au passage l'usage de l'option -a pour ajouter automatiquement tous les fichiers modifiés au commit).
L'empreinte de ce nouveau commit est générée bien évidemment à partir des modifications appliquées, mais également de tout l'arbre des commits précédents.
Ainsi, la corruption (accidentelle ou malveillante) d'un dépôt Git est pratiquement impossible, puisque la corruption d'une révision quelconque implique une incohérence immédiatement
détectable par la cascade des sommes de contrôle.
SHA
[master (root-commit) bdeddb3]
Put red
1 files changed,
1 insertions(+), 0 deletions(-)
create mode 100644 colors
$ git log
commit
bdeddb367771d0fd3aa5d96e3bd186311
Author: Matti Schneider
Date: Thu Apr 19 10:18:56 2012
Put red
$ echo "green" >> colors
$ git commit -a
-m "Added green"
12
bdeddb367771d0fd3
aa5d96e3bdd186311
Pour obtenir l'historique des précédents commits, on utilise la commande log.
Un commit est donc décrit par son auteur (identifié par son nom et email, d'où l'importance de l'enregistrer correctement), sa date d'application, son message de description… Et par une
longue suite de chiffres et lettres. On peut d'ailleurs remarquer que cette valeur correspond à celle affichée lors du commit.
Il s'agit de l'empreinte, ou somme de contrôle, SHA1 du commit. Git identifie de manière unique chaque commit par son empreinte SHA.
Appliquons une nouvelle modification et un nouveau commit (on remarque au passage l'usage de l'option -a pour ajouter automatiquement tous les fichiers modifiés au commit).
L'empreinte de ce nouveau commit est générée bien évidemment à partir des modifications appliquées, mais également de tout l'arbre des commits précédents.
Ainsi, la corruption (accidentelle ou malveillante) d'un dépôt Git est pratiquement impossible, puisque la corruption d'une révision quelconque implique une incohérence immédiatement
détectable par la cascade des sommes de contrôle.
SHA
[master (root-commit) bdeddb3]
Put red
1 files changed,
1 insertions(+), 0 deletions(-)
create mode 100644 colors
$ git log
commit
bdeddb367771d0fd3aa5d96e3bd186311
Author: Matti Schneider
Date: Thu Apr 19 10:18:56 2012
Put red
$ echo "green" >> colors
$ git commit -a
-m "Added green"
12
bdeddb367771d0fd3
aa5d96e3bdd186311
8a6846e6fd4509d8b
37883498e4aaa0eb6
+++
- - -
Pour obtenir l'historique des précédents commits, on utilise la commande log.
Un commit est donc décrit par son auteur (identifié par son nom et email, d'où l'importance de l'enregistrer correctement), sa date d'application, son message de description… Et par une
longue suite de chiffres et lettres. On peut d'ailleurs remarquer que cette valeur correspond à celle affichée lors du commit.
Il s'agit de l'empreinte, ou somme de contrôle, SHA1 du commit. Git identifie de manière unique chaque commit par son empreinte SHA.
Appliquons une nouvelle modification et un nouveau commit (on remarque au passage l'usage de l'option -a pour ajouter automatiquement tous les fichiers modifiés au commit).
L'empreinte de ce nouveau commit est générée bien évidemment à partir des modifications appliquées, mais également de tout l'arbre des commits précédents.
Ainsi, la corruption (accidentelle ou malveillante) d'un dépôt Git est pratiquement impossible, puisque la corruption d'une révision quelconque implique une incohérence immédiatement
détectable par la cascade des sommes de contrôle.
SHA
[master (root-commit) bdeddb3]
Put red
1 files changed,
1 insertions(+), 0 deletions(-)
create mode 100644 colors
$ git log
commit
bdeddb367771d0fd3aa5d96e3bd186311
Author: Matti Schneider
Date: Thu Apr 19 10:18:56 2012
Put red
$ echo "green" >> colors
$ git commit -a
-m "Added green"
12
bdeddb367771d0fd3
aa5d96e3bdd186311
8a6846e6fd4509d8b
37883498e4aaa0eb6
+++
- - -
Pour obtenir l'historique des précédents commits, on utilise la commande log.
Un commit est donc décrit par son auteur (identifié par son nom et email, d'où l'importance de l'enregistrer correctement), sa date d'application, son message de description… Et par une
longue suite de chiffres et lettres. On peut d'ailleurs remarquer que cette valeur correspond à celle affichée lors du commit.
Il s'agit de l'empreinte, ou somme de contrôle, SHA1 du commit. Git identifie de manière unique chaque commit par son empreinte SHA.
Appliquons une nouvelle modification et un nouveau commit (on remarque au passage l'usage de l'option -a pour ajouter automatiquement tous les fichiers modifiés au commit).
L'empreinte de ce nouveau commit est générée bien évidemment à partir des modifications appliquées, mais également de tout l'arbre des commits précédents.
Ainsi, la corruption (accidentelle ou malveillante) d'un dépôt Git est pratiquement impossible, puisque la corruption d'une révision quelconque implique une incohérence immédiatement
détectable par la cascade des sommes de contrôle.
SHA
[master (root-commit) bdeddb3]
Put red
1 files changed,
1 insertions(+), 0 deletions(-)
create mode 100644 colors
$ git log
commit
bdeddb367771d0fd3aa5d96e3bd186311
Author: Matti Schneider
Date: Thu Apr 19 10:18:56 2012
Put red
$ echo "green" >> colors
$ git commit -a
-m "Added green"
12
bdeddb367771d0fd3
aa5d96e3bdd186311
8a6846e6fd4509d8b
37883498e4aaa0eb6
+++
- - -
Pour obtenir l'historique des précédents commits, on utilise la commande log.
Un commit est donc décrit par son auteur (identifié par son nom et email, d'où l'importance de l'enregistrer correctement), sa date d'application, son message de description… Et par une
longue suite de chiffres et lettres. On peut d'ailleurs remarquer que cette valeur correspond à celle affichée lors du commit.
Il s'agit de l'empreinte, ou somme de contrôle, SHA1 du commit. Git identifie de manière unique chaque commit par son empreinte SHA.
Appliquons une nouvelle modification et un nouveau commit (on remarque au passage l'usage de l'option -a pour ajouter automatiquement tous les fichiers modifiés au commit).
L'empreinte de ce nouveau commit est générée bien évidemment à partir des modifications appliquées, mais également de tout l'arbre des commits précédents.
Ainsi, la corruption (accidentelle ou malveillante) d'un dépôt Git est pratiquement impossible, puisque la corruption d'une révision quelconque implique une incohérence immédiatement
détectable par la cascade des sommes de contrôle.
Branches
13
Nous allons à présent voir comment manipuler les branches.
Git fournit toujours par défaut la branche master. Une branche est essentiellement un pointeur vers un commit spécifique. Pour créer une nouvelle branche, on utilise la commande branch. Nous avons
ajouté ici la branche purple.
Pour lister l'ensemble des branches existantes, on utilise branch sans argument.
Git nous indique par l'astérisque la branche actuelle. Comment peut-il savoir quelle est la branche courante si elles pointent toutes deux vers le même commit ? En conservant un pointeur vers la branche
actuelle, nommé HEAD.
Voyons à présent comment les modifications sont gérées avec les branches. Si l'on modifie un fichier sur la branche courante, puis que l'on commit ces modifications, le pointeur de la branche courante est
mis à jour vers le nouveau commit, mais pas celui des autres branches.
Pour changer de branche, on utilise la commande checkout, qui va donc simplement mettre à jour le pointeur HEAD.
Si l'on modifie à nouveau un fichier, et que l'on commit ces modifications sur une autre branche, c'est là qu'une divergence apparaît. On a en parallèle deux versions différentes du même fichier, au même
chemin. Il faut bien comprendre que les modifications du contenu sont appliquées en place, il n'y a pas deux fichiers distincts, mais un seul qui est modifié au gré des checkouts.
Branches
13
master
Nous allons à présent voir comment manipuler les branches.
Git fournit toujours par défaut la branche master. Une branche est essentiellement un pointeur vers un commit spécifique. Pour créer une nouvelle branche, on utilise la commande branch. Nous avons
ajouté ici la branche purple.
Pour lister l'ensemble des branches existantes, on utilise branch sans argument.
Git nous indique par l'astérisque la branche actuelle. Comment peut-il savoir quelle est la branche courante si elles pointent toutes deux vers le même commit ? En conservant un pointeur vers la branche
actuelle, nommé HEAD.
Voyons à présent comment les modifications sont gérées avec les branches. Si l'on modifie un fichier sur la branche courante, puis que l'on commit ces modifications, le pointeur de la branche courante est
mis à jour vers le nouveau commit, mais pas celui des autres branches.
Pour changer de branche, on utilise la commande checkout, qui va donc simplement mettre à jour le pointeur HEAD.
Si l'on modifie à nouveau un fichier, et que l'on commit ces modifications sur une autre branche, c'est là qu'une divergence apparaît. On a en parallèle deux versions différentes du même fichier, au même
chemin. Il faut bien comprendre que les modifications du contenu sont appliquées en place, il n'y a pas deux fichiers distincts, mais un seul qui est modifié au gré des checkouts.
Branches
$ git branch purple
13
purple master
Nous allons à présent voir comment manipuler les branches.
Git fournit toujours par défaut la branche master. Une branche est essentiellement un pointeur vers un commit spécifique. Pour créer une nouvelle branche, on utilise la commande branch. Nous avons
ajouté ici la branche purple.
Pour lister l'ensemble des branches existantes, on utilise branch sans argument.
Git nous indique par l'astérisque la branche actuelle. Comment peut-il savoir quelle est la branche courante si elles pointent toutes deux vers le même commit ? En conservant un pointeur vers la branche
actuelle, nommé HEAD.
Voyons à présent comment les modifications sont gérées avec les branches. Si l'on modifie un fichier sur la branche courante, puis que l'on commit ces modifications, le pointeur de la branche courante est
mis à jour vers le nouveau commit, mais pas celui des autres branches.
Pour changer de branche, on utilise la commande checkout, qui va donc simplement mettre à jour le pointeur HEAD.
Si l'on modifie à nouveau un fichier, et que l'on commit ces modifications sur une autre branche, c'est là qu'une divergence apparaît. On a en parallèle deux versions différentes du même fichier, au même
chemin. Il faut bien comprendre que les modifications du contenu sont appliquées en place, il n'y a pas deux fichiers distincts, mais un seul qui est modifié au gré des checkouts.
Branches
$ git branch purple
$ git branch
purple
* master
13
purple master
Nous allons à présent voir comment manipuler les branches.
Git fournit toujours par défaut la branche master. Une branche est essentiellement un pointeur vers un commit spécifique. Pour créer une nouvelle branche, on utilise la commande branch. Nous avons
ajouté ici la branche purple.
Pour lister l'ensemble des branches existantes, on utilise branch sans argument.
Git nous indique par l'astérisque la branche actuelle. Comment peut-il savoir quelle est la branche courante si elles pointent toutes deux vers le même commit ? En conservant un pointeur vers la branche
actuelle, nommé HEAD.
Voyons à présent comment les modifications sont gérées avec les branches. Si l'on modifie un fichier sur la branche courante, puis que l'on commit ces modifications, le pointeur de la branche courante est
mis à jour vers le nouveau commit, mais pas celui des autres branches.
Pour changer de branche, on utilise la commande checkout, qui va donc simplement mettre à jour le pointeur HEAD.
Si l'on modifie à nouveau un fichier, et que l'on commit ces modifications sur une autre branche, c'est là qu'une divergence apparaît. On a en parallèle deux versions différentes du même fichier, au même
chemin. Il faut bien comprendre que les modifications du contenu sont appliquées en place, il n'y a pas deux fichiers distincts, mais un seul qui est modifié au gré des checkouts.
Branches
$ git branch purple
$ git branch
purple
* master
13
purple master
HEAD
Nous allons à présent voir comment manipuler les branches.
Git fournit toujours par défaut la branche master. Une branche est essentiellement un pointeur vers un commit spécifique. Pour créer une nouvelle branche, on utilise la commande branch. Nous avons
ajouté ici la branche purple.
Pour lister l'ensemble des branches existantes, on utilise branch sans argument.
Git nous indique par l'astérisque la branche actuelle. Comment peut-il savoir quelle est la branche courante si elles pointent toutes deux vers le même commit ? En conservant un pointeur vers la branche
actuelle, nommé HEAD.
Voyons à présent comment les modifications sont gérées avec les branches. Si l'on modifie un fichier sur la branche courante, puis que l'on commit ces modifications, le pointeur de la branche courante est
mis à jour vers le nouveau commit, mais pas celui des autres branches.
Pour changer de branche, on utilise la commande checkout, qui va donc simplement mettre à jour le pointeur HEAD.
Si l'on modifie à nouveau un fichier, et que l'on commit ces modifications sur une autre branche, c'est là qu'une divergence apparaît. On a en parallèle deux versions différentes du même fichier, au même
chemin. Il faut bien comprendre que les modifications du contenu sont appliquées en place, il n'y a pas deux fichiers distincts, mais un seul qui est modifié au gré des checkouts.
Branches
$ git branch purple
$ git branch
purple
* master
$ echo "green" >> colors
13
purple master
HEAD
Nous allons à présent voir comment manipuler les branches.
Git fournit toujours par défaut la branche master. Une branche est essentiellement un pointeur vers un commit spécifique. Pour créer une nouvelle branche, on utilise la commande branch. Nous avons
ajouté ici la branche purple.
Pour lister l'ensemble des branches existantes, on utilise branch sans argument.
Git nous indique par l'astérisque la branche actuelle. Comment peut-il savoir quelle est la branche courante si elles pointent toutes deux vers le même commit ? En conservant un pointeur vers la branche
actuelle, nommé HEAD.
Voyons à présent comment les modifications sont gérées avec les branches. Si l'on modifie un fichier sur la branche courante, puis que l'on commit ces modifications, le pointeur de la branche courante est
mis à jour vers le nouveau commit, mais pas celui des autres branches.
Pour changer de branche, on utilise la commande checkout, qui va donc simplement mettre à jour le pointeur HEAD.
Si l'on modifie à nouveau un fichier, et que l'on commit ces modifications sur une autre branche, c'est là qu'une divergence apparaît. On a en parallèle deux versions différentes du même fichier, au même
chemin. Il faut bien comprendre que les modifications du contenu sont appliquées en place, il n'y a pas deux fichiers distincts, mais un seul qui est modifié au gré des checkouts.
Branches
$ git branch purple
$ git branch
purple
* master
$ echo "green" >> colors
$ git commit -a -m "grn"
13
purple
master
HEAD
Nous allons à présent voir comment manipuler les branches.
Git fournit toujours par défaut la branche master. Une branche est essentiellement un pointeur vers un commit spécifique. Pour créer une nouvelle branche, on utilise la commande branch. Nous avons
ajouté ici la branche purple.
Pour lister l'ensemble des branches existantes, on utilise branch sans argument.
Git nous indique par l'astérisque la branche actuelle. Comment peut-il savoir quelle est la branche courante si elles pointent toutes deux vers le même commit ? En conservant un pointeur vers la branche
actuelle, nommé HEAD.
Voyons à présent comment les modifications sont gérées avec les branches. Si l'on modifie un fichier sur la branche courante, puis que l'on commit ces modifications, le pointeur de la branche courante est
mis à jour vers le nouveau commit, mais pas celui des autres branches.
Pour changer de branche, on utilise la commande checkout, qui va donc simplement mettre à jour le pointeur HEAD.
Si l'on modifie à nouveau un fichier, et que l'on commit ces modifications sur une autre branche, c'est là qu'une divergence apparaît. On a en parallèle deux versions différentes du même fichier, au même
chemin. Il faut bien comprendre que les modifications du contenu sont appliquées en place, il n'y a pas deux fichiers distincts, mais un seul qui est modifié au gré des checkouts.
Branches
$ git branch purple
$ git branch
purple
* master
$ echo "green" >> colors
$ git commit -a -m "grn"
$ git checkout purple
Switched to branch 'purple'
13
purple
master
HEAD
Nous allons à présent voir comment manipuler les branches.
Git fournit toujours par défaut la branche master. Une branche est essentiellement un pointeur vers un commit spécifique. Pour créer une nouvelle branche, on utilise la commande branch. Nous avons
ajouté ici la branche purple.
Pour lister l'ensemble des branches existantes, on utilise branch sans argument.
Git nous indique par l'astérisque la branche actuelle. Comment peut-il savoir quelle est la branche courante si elles pointent toutes deux vers le même commit ? En conservant un pointeur vers la branche
actuelle, nommé HEAD.
Voyons à présent comment les modifications sont gérées avec les branches. Si l'on modifie un fichier sur la branche courante, puis que l'on commit ces modifications, le pointeur de la branche courante est
mis à jour vers le nouveau commit, mais pas celui des autres branches.
Pour changer de branche, on utilise la commande checkout, qui va donc simplement mettre à jour le pointeur HEAD.
Si l'on modifie à nouveau un fichier, et que l'on commit ces modifications sur une autre branche, c'est là qu'une divergence apparaît. On a en parallèle deux versions différentes du même fichier, au même
chemin. Il faut bien comprendre que les modifications du contenu sont appliquées en place, il n'y a pas deux fichiers distincts, mais un seul qui est modifié au gré des checkouts.
Branches
$ git branch purple
$ git branch
purple
* master
$ echo "green" >> colors
$ git commit -a -m "grn"
$ git checkout purple
Switched to branch 'purple'
$ echo "purple" >> colors
13
purple
master
HEAD
Nous allons à présent voir comment manipuler les branches.
Git fournit toujours par défaut la branche master. Une branche est essentiellement un pointeur vers un commit spécifique. Pour créer une nouvelle branche, on utilise la commande branch. Nous avons
ajouté ici la branche purple.
Pour lister l'ensemble des branches existantes, on utilise branch sans argument.
Git nous indique par l'astérisque la branche actuelle. Comment peut-il savoir quelle est la branche courante si elles pointent toutes deux vers le même commit ? En conservant un pointeur vers la branche
actuelle, nommé HEAD.
Voyons à présent comment les modifications sont gérées avec les branches. Si l'on modifie un fichier sur la branche courante, puis que l'on commit ces modifications, le pointeur de la branche courante est
mis à jour vers le nouveau commit, mais pas celui des autres branches.
Pour changer de branche, on utilise la commande checkout, qui va donc simplement mettre à jour le pointeur HEAD.
Si l'on modifie à nouveau un fichier, et que l'on commit ces modifications sur une autre branche, c'est là qu'une divergence apparaît. On a en parallèle deux versions différentes du même fichier, au même
chemin. Il faut bien comprendre que les modifications du contenu sont appliquées en place, il n'y a pas deux fichiers distincts, mais un seul qui est modifié au gré des checkouts.
Branches
$ git branch purple
$ git branch
purple
* master
$ echo "green" >> colors
$ git commit -a -m "grn"
$ git checkout purple
Switched to branch 'purple'
$ echo "purple" >> colors
$ git commit -a -m "purp"
13
purple
master
HEAD
Nous allons à présent voir comment manipuler les branches.
Git fournit toujours par défaut la branche master. Une branche est essentiellement un pointeur vers un commit spécifique. Pour créer une nouvelle branche, on utilise la commande branch. Nous avons
ajouté ici la branche purple.
Pour lister l'ensemble des branches existantes, on utilise branch sans argument.
Git nous indique par l'astérisque la branche actuelle. Comment peut-il savoir quelle est la branche courante si elles pointent toutes deux vers le même commit ? En conservant un pointeur vers la branche
actuelle, nommé HEAD.
Voyons à présent comment les modifications sont gérées avec les branches. Si l'on modifie un fichier sur la branche courante, puis que l'on commit ces modifications, le pointeur de la branche courante est
mis à jour vers le nouveau commit, mais pas celui des autres branches.
Pour changer de branche, on utilise la commande checkout, qui va donc simplement mettre à jour le pointeur HEAD.
Si l'on modifie à nouveau un fichier, et que l'on commit ces modifications sur une autre branche, c'est là qu'une divergence apparaît. On a en parallèle deux versions différentes du même fichier, au même
chemin. Il faut bien comprendre que les modifications du contenu sont appliquées en place, il n'y a pas deux fichiers distincts, mais un seul qui est modifié au gré des checkouts.
Branches
$ git branch purple
$ git branch
purple
* master
$ echo "green" >> colors
$ git commit -a -m "grn"
$ git checkout purple
Switched to branch 'purple'
$ echo "purple" >> colors
$ git commit -a -m "purp"
[purple 65332d5] purp
13
purple master
HEAD
Nous allons à présent voir comment manipuler les branches.
Git fournit toujours par défaut la branche master. Une branche est essentiellement un pointeur vers un commit spécifique. Pour créer une nouvelle branche, on utilise la commande branch. Nous avons
ajouté ici la branche purple.
Pour lister l'ensemble des branches existantes, on utilise branch sans argument.
Git nous indique par l'astérisque la branche actuelle. Comment peut-il savoir quelle est la branche courante si elles pointent toutes deux vers le même commit ? En conservant un pointeur vers la branche
actuelle, nommé HEAD.
Voyons à présent comment les modifications sont gérées avec les branches. Si l'on modifie un fichier sur la branche courante, puis que l'on commit ces modifications, le pointeur de la branche courante est
mis à jour vers le nouveau commit, mais pas celui des autres branches.
Pour changer de branche, on utilise la commande checkout, qui va donc simplement mettre à jour le pointeur HEAD.
Si l'on modifie à nouveau un fichier, et que l'on commit ces modifications sur une autre branche, c'est là qu'une divergence apparaît. On a en parallèle deux versions différentes du même fichier, au même
chemin. Il faut bien comprendre que les modifications du contenu sont appliquées en place, il n'y a pas deux fichiers distincts, mais un seul qui est modifié au gré des checkouts.
Branches
$ git branch purple
$ git branch
purple
* master
$ echo "green" >> colors
$ git commit -a -m "grn"
$ git checkout purple
Switched to branch 'purple'
$ echo "purple" >> colors
$ git commit -a -m "purp"
[purple 65332d5] purp
13
purple master
colors
colors
“red
blue
purple”
“red
blue
green”
HEAD
Nous allons à présent voir comment manipuler les branches.
Git fournit toujours par défaut la branche master. Une branche est essentiellement un pointeur vers un commit spécifique. Pour créer une nouvelle branche, on utilise la commande branch. Nous avons
ajouté ici la branche purple.
Pour lister l'ensemble des branches existantes, on utilise branch sans argument.
Git nous indique par l'astérisque la branche actuelle. Comment peut-il savoir quelle est la branche courante si elles pointent toutes deux vers le même commit ? En conservant un pointeur vers la branche
actuelle, nommé HEAD.
Voyons à présent comment les modifications sont gérées avec les branches. Si l'on modifie un fichier sur la branche courante, puis que l'on commit ces modifications, le pointeur de la branche courante est
mis à jour vers le nouveau commit, mais pas celui des autres branches.
Pour changer de branche, on utilise la commande checkout, qui va donc simplement mettre à jour le pointeur HEAD.
Si l'on modifie à nouveau un fichier, et que l'on commit ces modifications sur une autre branche, c'est là qu'une divergence apparaît. On a en parallèle deux versions différentes du même fichier, au même
chemin. Il faut bien comprendre que les modifications du contenu sont appliquées en place, il n'y a pas deux fichiers distincts, mais un seul qui est modifié au gré des checkouts.
Branches
$ git branch purple
$ git branch
purple
* master
$ echo "green" >> colors
$ git commit -a -m "grn"
$ git checkout purple
Switched to branch 'purple'
$ echo "purple" >> colors
$ git commit -a -m "purp"
[purple 65332d5] purp
13
purple master
colors
colors
“red
blue
purple”
“red
blue
green”
HEAD
Nous allons à présent voir comment manipuler les branches.
Git fournit toujours par défaut la branche master. Une branche est essentiellement un pointeur vers un commit spécifique. Pour créer une nouvelle branche, on utilise la commande branch. Nous avons
ajouté ici la branche purple.
Pour lister l'ensemble des branches existantes, on utilise branch sans argument.
Git nous indique par l'astérisque la branche actuelle. Comment peut-il savoir quelle est la branche courante si elles pointent toutes deux vers le même commit ? En conservant un pointeur vers la branche
actuelle, nommé HEAD.
Voyons à présent comment les modifications sont gérées avec les branches. Si l'on modifie un fichier sur la branche courante, puis que l'on commit ces modifications, le pointeur de la branche courante est
mis à jour vers le nouveau commit, mais pas celui des autres branches.
Pour changer de branche, on utilise la commande checkout, qui va donc simplement mettre à jour le pointeur HEAD.
Si l'on modifie à nouveau un fichier, et que l'on commit ces modifications sur une autre branche, c'est là qu'une divergence apparaît. On a en parallèle deux versions différentes du même fichier, au même
chemin. Il faut bien comprendre que les modifications du contenu sont appliquées en place, il n'y a pas deux fichiers distincts, mais un seul qui est modifié au gré des checkouts.
“red blue
purple”
Intégration & conflits
14
purple master
colors
HEAD
À présent, comment intégrer les modifications d'une branche à l'autre ?
Tout d'abord, sélectionnons la branche de destination de l'intégration, généralement master.
Pour intégrer, on utilisera la commande merge, suivie du nom de la branche à intégrer. Ici, on a fait deux modifications différentes au même endroit, et un conflit émerge donc.
Les conflits sont rares avec Git, qui a des stratégies de fusion très puissantes. Ici, j'ai volontairement provoqué un conflit pour vous présenter la méthode de résolution, mais cela reste une situation
exceptionnelle lors de l'intégration. C'est d'ailleurs cette facilité qui rend l'utilisation des branches aussi habituelle.
Le contenu du fichier conflictuel est donc modifié pour comprendre les marqueurs standard de conflit : de part et d'autre des signes "===" se trouvent les différentes versions du même bloc, et c'est à nous
de réécrire l'ensemble du bloc à partir de ces informations, avec un éditeur quelconque.
Une fois le conflit résolu, la compilation effectuée et les tests passés, on peut valider l'intégration. L'intégration n'est en réalité qu'un commit un peu spécial, et la procédure est la même qu'un commit
standard : marquer un conflit comme résolu consiste simplement à ajouter le fichier corrigé à l'aire d'assemblage, puis à valider la modification par un commit, qui mettra à jour la branche destinataire de
l'intégration. Le message "Successful merge" est un grand classique d'une telle opération de résolution de conflits.
“red blue
purple”
green”
Intégration & conflits
$ git checkout master
Switched to branch 'master'
14
purple master
colors
HEAD
À présent, comment intégrer les modifications d'une branche à l'autre ?
Tout d'abord, sélectionnons la branche de destination de l'intégration, généralement master.
Pour intégrer, on utilisera la commande merge, suivie du nom de la branche à intégrer. Ici, on a fait deux modifications différentes au même endroit, et un conflit émerge donc.
Les conflits sont rares avec Git, qui a des stratégies de fusion très puissantes. Ici, j'ai volontairement provoqué un conflit pour vous présenter la méthode de résolution, mais cela reste une situation
exceptionnelle lors de l'intégration. C'est d'ailleurs cette facilité qui rend l'utilisation des branches aussi habituelle.
Le contenu du fichier conflictuel est donc modifié pour comprendre les marqueurs standard de conflit : de part et d'autre des signes "===" se trouvent les différentes versions du même bloc, et c'est à nous
de réécrire l'ensemble du bloc à partir de ces informations, avec un éditeur quelconque.
Une fois le conflit résolu, la compilation effectuée et les tests passés, on peut valider l'intégration. L'intégration n'est en réalité qu'un commit un peu spécial, et la procédure est la même qu'un commit
standard : marquer un conflit comme résolu consiste simplement à ajouter le fichier corrigé à l'aire d'assemblage, puis à valider la modification par un commit, qui mettra à jour la branche destinataire de
l'intégration. Le message "Successful merge" est un grand classique d'une telle opération de résolution de conflits.
“red blue
purple”
green”
Intégration & conflits
$ git checkout master
Switched to branch 'master'
$ git merge purple
14
purple master
colors
HEAD
À présent, comment intégrer les modifications d'une branche à l'autre ?
Tout d'abord, sélectionnons la branche de destination de l'intégration, généralement master.
Pour intégrer, on utilisera la commande merge, suivie du nom de la branche à intégrer. Ici, on a fait deux modifications différentes au même endroit, et un conflit émerge donc.
Les conflits sont rares avec Git, qui a des stratégies de fusion très puissantes. Ici, j'ai volontairement provoqué un conflit pour vous présenter la méthode de résolution, mais cela reste une situation
exceptionnelle lors de l'intégration. C'est d'ailleurs cette facilité qui rend l'utilisation des branches aussi habituelle.
Le contenu du fichier conflictuel est donc modifié pour comprendre les marqueurs standard de conflit : de part et d'autre des signes "===" se trouvent les différentes versions du même bloc, et c'est à nous
de réécrire l'ensemble du bloc à partir de ces informations, avec un éditeur quelconque.
Une fois le conflit résolu, la compilation effectuée et les tests passés, on peut valider l'intégration. L'intégration n'est en réalité qu'un commit un peu spécial, et la procédure est la même qu'un commit
standard : marquer un conflit comme résolu consiste simplement à ajouter le fichier corrigé à l'aire d'assemblage, puis à valider la modification par un commit, qui mettra à jour la branche destinataire de
l'intégration. Le message "Successful merge" est un grand classique d'une telle opération de résolution de conflits.
“red blue
purple”
green”
<<<<<<< HEAD
green
=======
purple
>>>>>>> purple
Intégration & conflits
$ git checkout master
Switched to branch 'master'
$ git merge purple
Auto-merging colors
CONFLICT: Merge conflict in colors
14
purple master
colors
HEAD
À présent, comment intégrer les modifications d'une branche à l'autre ?
Tout d'abord, sélectionnons la branche de destination de l'intégration, généralement master.
Pour intégrer, on utilisera la commande merge, suivie du nom de la branche à intégrer. Ici, on a fait deux modifications différentes au même endroit, et un conflit émerge donc.
Les conflits sont rares avec Git, qui a des stratégies de fusion très puissantes. Ici, j'ai volontairement provoqué un conflit pour vous présenter la méthode de résolution, mais cela reste une situation
exceptionnelle lors de l'intégration. C'est d'ailleurs cette facilité qui rend l'utilisation des branches aussi habituelle.
Le contenu du fichier conflictuel est donc modifié pour comprendre les marqueurs standard de conflit : de part et d'autre des signes "===" se trouvent les différentes versions du même bloc, et c'est à nous
de réécrire l'ensemble du bloc à partir de ces informations, avec un éditeur quelconque.
Une fois le conflit résolu, la compilation effectuée et les tests passés, on peut valider l'intégration. L'intégration n'est en réalité qu'un commit un peu spécial, et la procédure est la même qu'un commit
standard : marquer un conflit comme résolu consiste simplement à ajouter le fichier corrigé à l'aire d'assemblage, puis à valider la modification par un commit, qui mettra à jour la branche destinataire de
l'intégration. Le message "Successful merge" est un grand classique d'une telle opération de résolution de conflits.
“red blue
purple”
green purple”
Intégration & conflits
$ git checkout master
Switched to branch 'master'
$ git merge purple
Auto-merging colors
CONFLICT: Merge conflict in colors
# fix conflict
14
purple master
colors
HEAD
À présent, comment intégrer les modifications d'une branche à l'autre ?
Tout d'abord, sélectionnons la branche de destination de l'intégration, généralement master.
Pour intégrer, on utilisera la commande merge, suivie du nom de la branche à intégrer. Ici, on a fait deux modifications différentes au même endroit, et un conflit émerge donc.
Les conflits sont rares avec Git, qui a des stratégies de fusion très puissantes. Ici, j'ai volontairement provoqué un conflit pour vous présenter la méthode de résolution, mais cela reste une situation
exceptionnelle lors de l'intégration. C'est d'ailleurs cette facilité qui rend l'utilisation des branches aussi habituelle.
Le contenu du fichier conflictuel est donc modifié pour comprendre les marqueurs standard de conflit : de part et d'autre des signes "===" se trouvent les différentes versions du même bloc, et c'est à nous
de réécrire l'ensemble du bloc à partir de ces informations, avec un éditeur quelconque.
Une fois le conflit résolu, la compilation effectuée et les tests passés, on peut valider l'intégration. L'intégration n'est en réalité qu'un commit un peu spécial, et la procédure est la même qu'un commit
standard : marquer un conflit comme résolu consiste simplement à ajouter le fichier corrigé à l'aire d'assemblage, puis à valider la modification par un commit, qui mettra à jour la branche destinataire de
l'intégration. Le message "Successful merge" est un grand classique d'une telle opération de résolution de conflits.
“red blue
purple”
green purple”
Intégration & conflits
$ git checkout master
Switched to branch 'master'
$ git merge purple
Auto-merging colors
CONFLICT: Merge conflict in colors
# fix conflict
$ git add colors
$ git commit
-m "Successful merge"
14
purple master
colors
HEAD
À présent, comment intégrer les modifications d'une branche à l'autre ?
Tout d'abord, sélectionnons la branche de destination de l'intégration, généralement master.
Pour intégrer, on utilisera la commande merge, suivie du nom de la branche à intégrer. Ici, on a fait deux modifications différentes au même endroit, et un conflit émerge donc.
Les conflits sont rares avec Git, qui a des stratégies de fusion très puissantes. Ici, j'ai volontairement provoqué un conflit pour vous présenter la méthode de résolution, mais cela reste une situation
exceptionnelle lors de l'intégration. C'est d'ailleurs cette facilité qui rend l'utilisation des branches aussi habituelle.
Le contenu du fichier conflictuel est donc modifié pour comprendre les marqueurs standard de conflit : de part et d'autre des signes "===" se trouvent les différentes versions du même bloc, et c'est à nous
de réécrire l'ensemble du bloc à partir de ces informations, avec un éditeur quelconque.
Une fois le conflit résolu, la compilation effectuée et les tests passés, on peut valider l'intégration. L'intégration n'est en réalité qu'un commit un peu spécial, et la procédure est la même qu'un commit
standard : marquer un conflit comme résolu consiste simplement à ajouter le fichier corrigé à l'aire d'assemblage, puis à valider la modification par un commit, qui mettra à jour la branche destinataire de
l'intégration. Le message "Successful merge" est un grand classique d'une telle opération de résolution de conflits.
“red blue
purple”
green purple”
Intégration & conflits
$ git checkout master
Switched to branch 'master'
$ git merge purple
Auto-merging colors
CONFLICT: Merge conflict in colors
# fix conflict
$ git add colors
$ git commit
-m "Successful merge"
[master 5fbe3d4] Successful merge
14
purple
master
colors
HEAD
À présent, comment intégrer les modifications d'une branche à l'autre ?
Tout d'abord, sélectionnons la branche de destination de l'intégration, généralement master.
Pour intégrer, on utilisera la commande merge, suivie du nom de la branche à intégrer. Ici, on a fait deux modifications différentes au même endroit, et un conflit émerge donc.
Les conflits sont rares avec Git, qui a des stratégies de fusion très puissantes. Ici, j'ai volontairement provoqué un conflit pour vous présenter la méthode de résolution, mais cela reste une situation
exceptionnelle lors de l'intégration. C'est d'ailleurs cette facilité qui rend l'utilisation des branches aussi habituelle.
Le contenu du fichier conflictuel est donc modifié pour comprendre les marqueurs standard de conflit : de part et d'autre des signes "===" se trouvent les différentes versions du même bloc, et c'est à nous
de réécrire l'ensemble du bloc à partir de ces informations, avec un éditeur quelconque.
Une fois le conflit résolu, la compilation effectuée et les tests passés, on peut valider l'intégration. L'intégration n'est en réalité qu'un commit un peu spécial, et la procédure est la même qu'un commit
standard : marquer un conflit comme résolu consiste simplement à ajouter le fichier corrigé à l'aire d'assemblage, puis à valider la modification par un commit, qui mettra à jour la branche destinataire de
l'intégration. Le message "Successful merge" est un grand classique d'une telle opération de résolution de conflits.
Publication
15
origin
local
Nous allons voir ici comment collaborer sur un dépôt distant partagé.
Pour initialiser un dépôt local à partir d'un dépôt distant, on utilise la commande clone. L'URL d'origine peut utiliser de nombreux protocoles : SSH via le protocole git, HTTPS, HTTP, file…
Une fois le dépôt récupéré, on peut le modifier en local (édition, git add, git commit).
Pour partager ces modifications, il faut les envoyer sur le dépôt distant. Pour cela, on utilise la commande push. Cette commande va calculer la différence entre les dépôts local et distant, compresser les
éléments à envoyer, puis les transmettre sur le réseau et mettre à jour le dépôt distant.
Imaginons maintenant la situation inverse : un collaborateur a mis à jour le dépôt distant avec ses propres modifications, et on veut les rapatrier.
Pour cela, on utilise la commande inverse de push, pull. Cette commande va télécharger les modifications, et les intégrer dans le graphe local, avec un merge comme on l'a vu précédemment.
On voit encore une fois que Git insiste sur les branches, en listant tant la locale que la distante. On peut également lire la mention “Fast forward” ; cela signifie que l'intégration s'est déroulée sans conflit.
Publication
$ git clone URL/projet
15
origin
local
Nous allons voir ici comment collaborer sur un dépôt distant partagé.
Pour initialiser un dépôt local à partir d'un dépôt distant, on utilise la commande clone. L'URL d'origine peut utiliser de nombreux protocoles : SSH via le protocole git, HTTPS, HTTP, file…
Une fois le dépôt récupéré, on peut le modifier en local (édition, git add, git commit).
Pour partager ces modifications, il faut les envoyer sur le dépôt distant. Pour cela, on utilise la commande push. Cette commande va calculer la différence entre les dépôts local et distant, compresser les
éléments à envoyer, puis les transmettre sur le réseau et mettre à jour le dépôt distant.
Imaginons maintenant la situation inverse : un collaborateur a mis à jour le dépôt distant avec ses propres modifications, et on veut les rapatrier.
Pour cela, on utilise la commande inverse de push, pull. Cette commande va télécharger les modifications, et les intégrer dans le graphe local, avec un merge comme on l'a vu précédemment.
On voit encore une fois que Git insiste sur les branches, en listant tant la locale que la distante. On peut également lire la mention “Fast forward” ; cela signifie que l'intégration s'est déroulée sans conflit.
Publication
$ git clone URL/projet
Cloning into projet…
done.
15
origin
local
clone
Nous allons voir ici comment collaborer sur un dépôt distant partagé.
Pour initialiser un dépôt local à partir d'un dépôt distant, on utilise la commande clone. L'URL d'origine peut utiliser de nombreux protocoles : SSH via le protocole git, HTTPS, HTTP, file…
Une fois le dépôt récupéré, on peut le modifier en local (édition, git add, git commit).
Pour partager ces modifications, il faut les envoyer sur le dépôt distant. Pour cela, on utilise la commande push. Cette commande va calculer la différence entre les dépôts local et distant, compresser les
éléments à envoyer, puis les transmettre sur le réseau et mettre à jour le dépôt distant.
Imaginons maintenant la situation inverse : un collaborateur a mis à jour le dépôt distant avec ses propres modifications, et on veut les rapatrier.
Pour cela, on utilise la commande inverse de push, pull. Cette commande va télécharger les modifications, et les intégrer dans le graphe local, avec un merge comme on l'a vu précédemment.
On voit encore une fois que Git insiste sur les branches, en listant tant la locale que la distante. On peut également lire la mention “Fast forward” ; cela signifie que l'intégration s'est déroulée sans conflit.
Publication
$ git clone URL/projet
Cloning into projet…
done.
# code, add, commit
15
origin
local
clone
Nous allons voir ici comment collaborer sur un dépôt distant partagé.
Pour initialiser un dépôt local à partir d'un dépôt distant, on utilise la commande clone. L'URL d'origine peut utiliser de nombreux protocoles : SSH via le protocole git, HTTPS, HTTP, file…
Une fois le dépôt récupéré, on peut le modifier en local (édition, git add, git commit).
Pour partager ces modifications, il faut les envoyer sur le dépôt distant. Pour cela, on utilise la commande push. Cette commande va calculer la différence entre les dépôts local et distant, compresser les
éléments à envoyer, puis les transmettre sur le réseau et mettre à jour le dépôt distant.
Imaginons maintenant la situation inverse : un collaborateur a mis à jour le dépôt distant avec ses propres modifications, et on veut les rapatrier.
Pour cela, on utilise la commande inverse de push, pull. Cette commande va télécharger les modifications, et les intégrer dans le graphe local, avec un merge comme on l'a vu précédemment.
On voit encore une fois que Git insiste sur les branches, en listant tant la locale que la distante. On peut également lire la mention “Fast forward” ; cela signifie que l'intégration s'est déroulée sans conflit.
Publication
$ git clone URL/projet
Cloning into projet…
done.
# code, add, commit
$ git push
15
origin
local
clone
Nous allons voir ici comment collaborer sur un dépôt distant partagé.
Pour initialiser un dépôt local à partir d'un dépôt distant, on utilise la commande clone. L'URL d'origine peut utiliser de nombreux protocoles : SSH via le protocole git, HTTPS, HTTP, file…
Une fois le dépôt récupéré, on peut le modifier en local (édition, git add, git commit).
Pour partager ces modifications, il faut les envoyer sur le dépôt distant. Pour cela, on utilise la commande push. Cette commande va calculer la différence entre les dépôts local et distant, compresser les
éléments à envoyer, puis les transmettre sur le réseau et mettre à jour le dépôt distant.
Imaginons maintenant la situation inverse : un collaborateur a mis à jour le dépôt distant avec ses propres modifications, et on veut les rapatrier.
Pour cela, on utilise la commande inverse de push, pull. Cette commande va télécharger les modifications, et les intégrer dans le graphe local, avec un merge comme on l'a vu précédemment.
On voit encore une fois que Git insiste sur les branches, en listant tant la locale que la distante. On peut également lire la mention “Fast forward” ; cela signifie que l'intégration s'est déroulée sans conflit.
Publication
$ git clone URL/projet
Cloning into projet…
done.
# code, add, commit
$ git push
Counting objects: 7, done.
Total 4, reused 0
To user@repo:projet.git
36130..cd831 master -> master
15
origin
local
clone push
Nous allons voir ici comment collaborer sur un dépôt distant partagé.
Pour initialiser un dépôt local à partir d'un dépôt distant, on utilise la commande clone. L'URL d'origine peut utiliser de nombreux protocoles : SSH via le protocole git, HTTPS, HTTP, file…
Une fois le dépôt récupéré, on peut le modifier en local (édition, git add, git commit).
Pour partager ces modifications, il faut les envoyer sur le dépôt distant. Pour cela, on utilise la commande push. Cette commande va calculer la différence entre les dépôts local et distant, compresser les
éléments à envoyer, puis les transmettre sur le réseau et mettre à jour le dépôt distant.
Imaginons maintenant la situation inverse : un collaborateur a mis à jour le dépôt distant avec ses propres modifications, et on veut les rapatrier.
Pour cela, on utilise la commande inverse de push, pull. Cette commande va télécharger les modifications, et les intégrer dans le graphe local, avec un merge comme on l'a vu précédemment.
On voit encore une fois que Git insiste sur les branches, en listant tant la locale que la distante. On peut également lire la mention “Fast forward” ; cela signifie que l'intégration s'est déroulée sans conflit.
Publication
$ git clone URL/projet
Cloning into projet…
done.
# code, add, commit
$ git push
Counting objects: 7, done.
Total 4, reused 0
To user@repo:projet.git
36130..cd831 master -> master
15
origin
local
clone push
Nous allons voir ici comment collaborer sur un dépôt distant partagé.
Pour initialiser un dépôt local à partir d'un dépôt distant, on utilise la commande clone. L'URL d'origine peut utiliser de nombreux protocoles : SSH via le protocole git, HTTPS, HTTP, file…
Une fois le dépôt récupéré, on peut le modifier en local (édition, git add, git commit).
Pour partager ces modifications, il faut les envoyer sur le dépôt distant. Pour cela, on utilise la commande push. Cette commande va calculer la différence entre les dépôts local et distant, compresser les
éléments à envoyer, puis les transmettre sur le réseau et mettre à jour le dépôt distant.
Imaginons maintenant la situation inverse : un collaborateur a mis à jour le dépôt distant avec ses propres modifications, et on veut les rapatrier.
Pour cela, on utilise la commande inverse de push, pull. Cette commande va télécharger les modifications, et les intégrer dans le graphe local, avec un merge comme on l'a vu précédemment.
On voit encore une fois que Git insiste sur les branches, en listant tant la locale que la distante. On peut également lire la mention “Fast forward” ; cela signifie que l'intégration s'est déroulée sans conflit.
Publication
$ git clone URL/projet
Cloning into projet…
done.
# code, add, commit
$ git push
Counting objects: 7, done.
Total 4, reused 0
To user@repo:projet.git
36130..cd831 master -> master
$ git pull
15
origin
local
clone push
Nous allons voir ici comment collaborer sur un dépôt distant partagé.
Pour initialiser un dépôt local à partir d'un dépôt distant, on utilise la commande clone. L'URL d'origine peut utiliser de nombreux protocoles : SSH via le protocole git, HTTPS, HTTP, file…
Une fois le dépôt récupéré, on peut le modifier en local (édition, git add, git commit).
Pour partager ces modifications, il faut les envoyer sur le dépôt distant. Pour cela, on utilise la commande push. Cette commande va calculer la différence entre les dépôts local et distant, compresser les
éléments à envoyer, puis les transmettre sur le réseau et mettre à jour le dépôt distant.
Imaginons maintenant la situation inverse : un collaborateur a mis à jour le dépôt distant avec ses propres modifications, et on veut les rapatrier.
Pour cela, on utilise la commande inverse de push, pull. Cette commande va télécharger les modifications, et les intégrer dans le graphe local, avec un merge comme on l'a vu précédemment.
On voit encore une fois que Git insiste sur les branches, en listant tant la locale que la distante. On peut également lire la mention “Fast forward” ; cela signifie que l'intégration s'est déroulée sans conflit.
Publication
$ git clone URL/projet
Cloning into projet…
done.
# code, add, commit
$ git push
Counting objects: 7, done.
Total 4, reused 0
To user@repo:projet.git
36130..cd831 master -> master
$ git pull
Updating 36130..cd831
Fast forward
colors | 1 +
1 files changed,
1 insertions(+), 0 deletions(-)
15
origin
local
clone push pull
Nous allons voir ici comment collaborer sur un dépôt distant partagé.
Pour initialiser un dépôt local à partir d'un dépôt distant, on utilise la commande clone. L'URL d'origine peut utiliser de nombreux protocoles : SSH via le protocole git, HTTPS, HTTP, file…
Une fois le dépôt récupéré, on peut le modifier en local (édition, git add, git commit).
Pour partager ces modifications, il faut les envoyer sur le dépôt distant. Pour cela, on utilise la commande push. Cette commande va calculer la différence entre les dépôts local et distant, compresser les
éléments à envoyer, puis les transmettre sur le réseau et mettre à jour le dépôt distant.
Imaginons maintenant la situation inverse : un collaborateur a mis à jour le dépôt distant avec ses propres modifications, et on veut les rapatrier.
Pour cela, on utilise la commande inverse de push, pull. Cette commande va télécharger les modifications, et les intégrer dans le graphe local, avec un merge comme on l'a vu précédemment.
On voit encore une fois que Git insiste sur les branches, en listant tant la locale que la distante. On peut également lire la mention “Fast forward” ; cela signifie que l'intégration s'est déroulée sans conflit.
Publication
$ git clone URL/projet
Cloning into projet…
done.
# code, add, commit
$ git push
Counting objects: 7, done.
Total 4, reused 0
To user@repo:projet.git
36130..cd831 master -> master
$ git pull
Updating 36130..cd831
Fast forward
colors | 1 +
1 files changed,
1 insertions(+), 0 deletions(-)
15
origin
local
clone push pull
Nous allons voir ici comment collaborer sur un dépôt distant partagé.
Pour initialiser un dépôt local à partir d'un dépôt distant, on utilise la commande clone. L'URL d'origine peut utiliser de nombreux protocoles : SSH via le protocole git, HTTPS, HTTP, file…
Une fois le dépôt récupéré, on peut le modifier en local (édition, git add, git commit).
Pour partager ces modifications, il faut les envoyer sur le dépôt distant. Pour cela, on utilise la commande push. Cette commande va calculer la différence entre les dépôts local et distant, compresser les
éléments à envoyer, puis les transmettre sur le réseau et mettre à jour le dépôt distant.
Imaginons maintenant la situation inverse : un collaborateur a mis à jour le dépôt distant avec ses propres modifications, et on veut les rapatrier.
Pour cela, on utilise la commande inverse de push, pull. Cette commande va télécharger les modifications, et les intégrer dans le graphe local, avec un merge comme on l'a vu précédemment.
On voit encore une fois que Git insiste sur les branches, en listant tant la locale que la distante. On peut également lire la mention “Fast forward” ; cela signifie que l'intégration s'est déroulée sans conflit.
Publication
$ git clone URL/projet
Cloning into projet…
done.
# code, add, commit
$ git push
Counting objects: 7, done.
Total 4, reused 0
To user@repo:projet.git
36130..cd831 master -> master
$ git pull
Updating 36130..cd831
Fast forward
colors | 1 +
1 files changed,
1 insertions(+), 0 deletions(-)
15
origin
local
clone push pull
Nous allons voir ici comment collaborer sur un dépôt distant partagé.
Pour initialiser un dépôt local à partir d'un dépôt distant, on utilise la commande clone. L'URL d'origine peut utiliser de nombreux protocoles : SSH via le protocole git, HTTPS, HTTP, file…
Une fois le dépôt récupéré, on peut le modifier en local (édition, git add, git commit).
Pour partager ces modifications, il faut les envoyer sur le dépôt distant. Pour cela, on utilise la commande push. Cette commande va calculer la différence entre les dépôts local et distant, compresser les
éléments à envoyer, puis les transmettre sur le réseau et mettre à jour le dépôt distant.
Imaginons maintenant la situation inverse : un collaborateur a mis à jour le dépôt distant avec ses propres modifications, et on veut les rapatrier.
Pour cela, on utilise la commande inverse de push, pull. Cette commande va télécharger les modifications, et les intégrer dans le graphe local, avec un merge comme on l'a vu précédemment.
On voit encore une fois que Git insiste sur les branches, en listant tant la locale que la distante. On peut également lire la mention “Fast forward” ; cela signifie que l'intégration s'est déroulée sans conflit.
Apprentissage
16
En cas d'erreur, Git en explique très bien la raison et une solution éventuelle.
En revanche, le vocabulaire employé ne vous sera pas toujours clair. Utilisez bien entendu vos amis Google et StackOverflow… Et faites attention
avec les solutions alternatives proposées. Si vous n'êtes pas certain de son fonctionnement, ne tentez pas le diable : il s'agit souvent de moyens de
forcer l'action, mais il y a généralement une très bonne raison pour qu'elle ait été refusée en premier lieu.
Apprentissage
• utiliser la ligne de commande
16
En cas d'erreur, Git en explique très bien la raison et une solution éventuelle.
En revanche, le vocabulaire employé ne vous sera pas toujours clair. Utilisez bien entendu vos amis Google et StackOverflow… Et faites attention
avec les solutions alternatives proposées. Si vous n'êtes pas certain de son fonctionnement, ne tentez pas le diable : il s'agit souvent de moyens de
forcer l'action, mais il y a généralement une très bonne raison pour qu'elle ait été refusée en premier lieu.
Apprentissage
• utiliser la ligne de commande
• puis passer au graphique (diff, chunks…)
16
En cas d'erreur, Git en explique très bien la raison et une solution éventuelle.
En revanche, le vocabulaire employé ne vous sera pas toujours clair. Utilisez bien entendu vos amis Google et StackOverflow… Et faites attention
avec les solutions alternatives proposées. Si vous n'êtes pas certain de son fonctionnement, ne tentez pas le diable : il s'agit souvent de moyens de
forcer l'action, mais il y a généralement une très bonne raison pour qu'elle ait été refusée en premier lieu.
Apprentissage
• utiliser la ligne de commande
• puis passer au graphique (diff, chunks…)
• lire les erreurs
16
En cas d'erreur, Git en explique très bien la raison et une solution éventuelle.
En revanche, le vocabulaire employé ne vous sera pas toujours clair. Utilisez bien entendu vos amis Google et StackOverflow… Et faites attention
avec les solutions alternatives proposées. Si vous n'êtes pas certain de son fonctionnement, ne tentez pas le diable : il s'agit souvent de moyens de
forcer l'action, mais il y a généralement une très bonne raison pour qu'elle ait été refusée en premier lieu.
Apprentissage
• utiliser la ligne de commande
• puis passer au graphique (diff, chunks…)
• lire les erreurs
• ne rentrer les commandes proposées qu’en les comprenant
16
En cas d'erreur, Git en explique très bien la raison et une solution éventuelle.
En revanche, le vocabulaire employé ne vous sera pas toujours clair. Utilisez bien entendu vos amis Google et StackOverflow… Et faites attention
avec les solutions alternatives proposées. Si vous n'êtes pas certain de son fonctionnement, ne tentez pas le diable : il s'agit souvent de moyens de
forcer l'action, mais il y a généralement une très bonne raison pour qu'elle ait été refusée en premier lieu.
Apprentissage
• utiliser la ligne de commande
• puis passer au graphique (diff, chunks…)
• lire les erreurs
• ne rentrer les commandes proposées qu’en les comprenant
• git help
16
En cas d'erreur, Git en explique très bien la raison et une solution éventuelle.
En revanche, le vocabulaire employé ne vous sera pas toujours clair. Utilisez bien entendu vos amis Google et StackOverflow… Et faites attention
avec les solutions alternatives proposées. Si vous n'êtes pas certain de son fonctionnement, ne tentez pas le diable : il s'agit souvent de moyens de
forcer l'action, mais il y a généralement une très bonne raison pour qu'elle ait été refusée en premier lieu.
Quelques arguments
17
Quelques arguments
• .gitignore
17
Quelques arguments
• .gitignore
• performance
17
Quelques arguments
• .gitignore
• performance
• communauté
17
Quelques arguments
• .gitignore
• performance
• communauté
• GitHub
17
Quelques arguments
• .gitignore
• performance
• communauté
• GitHub
• libre
17
Quelques arguments
• .gitignore
• performance
• communauté
• GitHub
• libre
• destination de l'industrie
17
Prochaines
sessions
1. Introduction
18
Prochaines
sessions
1. Introduction
2. Stratégies
18
Prochaines
sessions
1. Introduction
2. Stratégies
3. Usage intermédiaire
18
Prochaines
sessions
1. Introduction
2. Stratégies
3. Usage intermédiaire
4. Usage avancé
18
Merci !
Des questions ?
• Ressources
• Panorama de Git
• Tutorial : gitimmersion.com
• Vidéos : gitcasts.com
• Devenir un pro : progit.org
• Pour les habitués de ClearCase
• Pouquoi Git est meilleur que X
• Taille et rapidité sur gros projet
• Outils
• Installeur Windows :
code.google.com/p/gitextensions
• GUI OS X :
github.com/brotherbard/gitx
• Images
• Logo Git par Alex Bargi
• Cible, Cerveau, Balance, Main, Shuffle,
Médaille, Trophée
CC-BY TheNounProject.com
• Photos Linus Torvalds
CC-BY-SA Wikimedia Commons
• Dossier, doc, serveur, écran © Apple
• Remerciements
• GitHub
• Scott Chacon
• Antoine Büsch
• Bart van Zon
• Daniel Öberg
• Eurogiciel
19
Panorama de Git : http://xenon.stanford.edu/~blynn/gitmagic/intl/fr/index.html
Pour les habitués de ClearCase : http://speakerdeck.com/u/9seconds/p/wtf-is-git
Pouquoi Git est meilleur que X : http://fr.whygitisbetterthanx.com
Taille et rapidité d'un dépôt Git sur un très gros projet : http://www.blender.org/forum/viewtopic.php?t=22459
mattisg
dunglas
hpgrahsl
manfredsteyer
seike460
murabayashi
hschwentner
slsops
kizuku_miyagi
nozaki
mfunaki
itsmedreamwalker
mkeeda
schacon
cromwellryan
samlambert
chriscoyier
orderedlist
marcelosomers
philnash
zakiyama
jcasabona
morganepeng
iamctodd
lara