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 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 Control System • gestionnaire de versions • CVS, SVN, ClearCase, Mercurial, Bazaar, Dropbox… • collaborer • sauvegarder l’historique 4

Version Control System • gestionnaire de versions • CVS, SVN, ClearCase, Mercurial, Bazaar, Dropbox… • collaborer • sauvegarder l’historique 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 +++ - - - 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 +++ - - - 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