Différences

Ci-dessous, les différences entre deux révisions de la page.

--- dev:git:start [2020/04/22 11:59] – yoann
+++ dev:git:start [2023/09/19 13:05] (Version actuelle) – yoann
@@ Ligne 1: / Ligne 1: @@
-{{tag>git}}
+{{tag>git dev}}
 ====== Git ======
-Git est un outil de suivi de version ou **gestionnaire de révisions**. Contrairement à certains outils centralisés du même type comme svn, Git est distribué, ce  qui le rend très réactif.
+Git est un outil de suivi de version ou **gestionnaire de révisions**. Contrairement à certains outils centralisés du même type comme svn, Git est distribué, ce  qui le rend très réactif, plus didactique car aucun serveur n'est nécessaire pour apprendre à travailler avec Git.
-Git est capable de suivre les modifications apportées à tous types de fichiers texte ou binaire. Une révision est une série de modifications apportée sur un ou plusieurs fichiers que Git ajoute à son historique. L'historique Git pourra ensuite être parcouru ou travailler autour de ces étapes (révisions).
+Un gestionnaire de révision permet de garder en mémoire:
+  * Les modifications apportées sur chaque fichier ;
+  * Pourquoi elles ont eu lieu ;
+  * et par qui !
-L'ensemble des révisions forment l'historique. L' interaction entre l’utilisateur et Git se concentre
+Cette tâche de gestion des révisions est appelée **versioning** en anglais.
+Git est capable de suivre les modifications apportées à tous types de fichiers (textes ou binaires) que l'on désigne par sources du projet. Une **révision** est une série de modifications apportée sur les sources du projet. Git note les modifications associées à l’ensemble des fichiers qu’il suit avant de les ajouter, sous forme de révision, à son historique. L'historique Git pourra ensuite être parcouru et travaillé autour de ces étapes (révisions).
+Pour qu'un outil de gestion de révision puisse être utilisé à son plein potentiel (et pas comme un simple outil de sauvegarde), l'utilisateur doit prendre soin de créer des **révisions atomiques**. Il est essentiel que chaque révision corresponde à une modification logique et structurée du logiciel pour que certains outils intégrés à Git puisse être utilisés efficacement.
+Le rôle de Git est de suivre l'évolution du code source d'un projet. Il conserve la trace de l'ensemble des révisions formant **l'historique**. L' interaction entre l’utilisateur et Git se concentre
 essentiellement sur la manipulation de cet historique, qu’il s’agisse d’y ajouter du contenu (nouvelle révision), d’en modifier l’agencement des révisions (rebase) ou de changer le contenu d’une révision (fixup).
-Avec Git on réécrit l'histoire pour lui donner un sens logique et l'ordonner. On peut également créer des réalités parallèles (branches) évoluant de façon indépendante.
+Avec Git on peut réécrire l'histoire pour lui donner un sens logique et l'ordonner. On peut également créer des réalités parallèles (branches) évoluant de façon indépendante.
-commit: Sélectionner une série de modifications apportées sur un ou plusieurs fichiers afin de créer une révision au sein de l'historique Git. Le commit contient des métadonnées (ID, auteur, date, commentaire, etc). De nombreuses commandes Git requièrent l'ID du commit souvent désigné par "sha".
+**commit**: Sélectionner (désigner ou grouper) une série de modifications apportées sur un ou plusieurs fichiers afin de créer une révision au sein de l'historique Git. Le commit contient des métadonnées (ID, auteur, date, commentaire, etc) permettant à l'utilisateur de documenter la révision. De nombreuses commandes Git requièrent l'ID du commit souvent désigné par "sha".
-checkout: Extraction d'une révision de l'historique dans l'espace de travail
+L'**espace de travail** est l'arborescence sur le système de fichier contenant les sources manipulables par l'utilisateur. C'est en comparant l'état des sources au sein de l'espace de travail avec une révision que Git peut indiquer à l'utilisateur les éventuels changement à intégrer à l'historique du projet.
-branche: Permet de gérer de façon isolée une série de changements. Les applications les plus communes concernent les **branches de maintenances** et les **branches de développement** apportant de nouvelles fonctionnalités.
+L'espace de travail peut être créé/recréer par extraction d'une révision précise de l'historique.
-Branche de maintenance: Créée à partir d'une ancienne révision, elle contient un ensemble de correctifs. La branche restera parrallèle et ne rejoindra jamais la branche principale. Ici on cherche à publier de nouvelles versions corrigées d'un produit existant.
+**checkout**: Extraction d'une révision de l'historique vers l'espace de travail.
+Grâce au checkout, on peut remplacer les changements apportés dans le répertoire de travail existant et revenir dans l'état antérieur correspondant à cette révision.
+Un très bon [[http://ndpsoftware.com/git-cheatsheet.html|support interactif]] décrit les différentes zones et les actions des principales commandes.
+L'historique d'un projet n'est pas forcément linéaire. Il peut contenir des **branches**. Un projet peut donc avoir un historique présentant des branches parallèles et c'est même une des principales fonctionnalités d'un tel outil.
+Une **branche** permet de gérer de façon isolée une série de changements. Les applications les plus communes concernent les **branches de maintenances** et les **branches de développement** apportant de nouvelles fonctionnalités.
+Branche de maintenance: Créée à partir d'une ancienne révision, elle contient un ensemble de correctifs. La branche restera parallèle et ne rejoindra jamais la branche principale. Ici on cherche à publier de nouvelles versions corrigées d'un produit existant.
 Il est parfois pertinent qu'un changement appliqué sur une branche puisse être fait également sur une autre. Dans le cas par exemple d'un défaut affectant plusieurs versions du logiciel. Git possède un ensemble d'outils facilitant grandement ce travail désigné sous le terme **backport**.
-Branche dévelopement: Rejoins tôt ou tard la branche d'où elle provient. Une fois la fonctionnalité implémentée, l'ensemble des révisions rejoin la branche parente.
+Branche développement: Rejoins tôt ou tard la branche d'où elle provient. Une fois la fonctionnalité implémentée, l'ensemble des révisions rejoint la branche parente. Lors de cette opération deux possibilités:
+  * **Rebase**: L'ensemble des modifications de la branche de développement sont appliquées directement sur l'état actuel de la branche cible. Dans ce cas, l'historique ne conservera pas de trace de l' existence de branche de développement. Le **rebase** permet de conserver un historique linéaire et séquentiel.
+  * **Merge** ou fusion: Dans ce cas l'historique conserve l' existence de la branche, des points de divergence et de fusion.
+Ces opérations rebase ou merge sont automatisée mais peuvent avoir besoin d'intervention en cas de conflit.
+Le nombre de révisions pouvant rapidement devenir important même pour de modestes projets, un système d'étiquetage (**tag**) permet d'associer un numéro de version, un nom à une révision précise.
 ===== Installer =====

wikinotes

Outils pour utilisateurs

Outils du site

Différences

Outils de la page