Découvrez les principes et fonctionnalités essentielles de git. Soyez prêts à travailler en 3 heures.
La dernière version est disponible en téléchargement direct à cette adresse : http://giant-teapot.org/uploads/tutorials/git_tutorial.pdf
Diaporama pour la formation git réalisée pour l'association Atilla, septembre 2012.
Cette formation présente les élements de base pour maîtriser git/gitLab. Elle contient aussi des astuces et de bonnes pratiques pour mieux utiliser git.
This document provides an overview of version control and Git. It discusses what version control is, why it is used, and common types including local, centralized, and distributed. It then focuses on Git, covering its history and origins from Linux kernel development. Key Git concepts are explained like data storage, file lifecycles, basic commands like clone, add, commit, branch, merge, and working with remotes. Tips are provided on installation, ignoring files, using with IDEs, and further learning resources.
Git est un logiciel de gestion de versions décentralisé qui vous permettra de gérer la vie d'un code informatique. Il permet une stratégie de backup, de gérer des versions et de stocker tout l'historique des modifications apportées à un projet informatique.
Cette formation présente les élements de base pour maîtriser git/gitLab. Elle contient aussi des astuces et de bonnes pratiques pour mieux utiliser git.
This document provides an overview of version control and Git. It discusses what version control is, why it is used, and common types including local, centralized, and distributed. It then focuses on Git, covering its history and origins from Linux kernel development. Key Git concepts are explained like data storage, file lifecycles, basic commands like clone, add, commit, branch, merge, and working with remotes. Tips are provided on installation, ignoring files, using with IDEs, and further learning resources.
Git est un logiciel de gestion de versions décentralisé qui vous permettra de gérer la vie d'un code informatique. Il permet une stratégie de backup, de gérer des versions et de stocker tout l'historique des modifications apportées à un projet informatique.
Git allows for a distributed model where every user has their own local copy of the code and changes are merged to a local master branch, while SVN uses a centralized model where changes are committed to a central repository. Git operations like diff and commit are much faster since they are performed locally without network latency. Git also uses much less storage space than SVN. A key advantage of Git is its powerful branching and merging capabilities.
The everyday developer's guide to version control with GitE Carter
Git is a distributed version control system that allows developers to track changes in source code. It provides tools to commit changes locally, branch code for parallel development, and collaborate remotely by pushing and pulling changes from a shared repository. Common Git commands include init to create a repository, add and commit to save changes locally, checkout to switch branches, pull to retrieve remote changes, and push to upload local changes. Git helps developers work efficiently by enabling features like branching, undoing mistakes, and viewing the revision history.
Git provides a distributed version control system that is faster and more lightweight than the centralized SVN. Git allows for easy branching and merging of code. Developers can work independently on their local repositories and sync changes to remote repositories. This allows teams to work together seamlessly on codebases.
Git is a distributed version control system that allows developers to work collaboratively on projects. It works by creating snapshots of files in a project over time. Developers can commit changes locally and then push them to a remote repository to share with others. Key Git concepts include repositories, commits, branches, cloning repositories from remote locations, and commands like push, pull, commit, log and diff to manage changes.
The document discusses Git and GitHub. It begins with an overview of distributed version control systems (DVCS) like Git and how they differ from centralized version control systems. It then covers the basics of Git, including installing Git, initializing repositories, tracking changes, branching and merging. Finally, it discusses GitHub and how developers can use features like forking, pull requests and wikis to collaborate on projects hosted there. Common Git workflows like Git flow are also introduced.
Git is a version control system that stores snapshots of files rather than tracking changes between file versions. It allows for offline work and nearly all operations are performed locally. Files can exist in three states - committed, modified, or staged. Commits create snapshots of the staged files. Branches act as pointers to commits, with the default branch being master.
Do you know the basics of Git but wonder what all the hype is about? Do you want the ultimate control over your Git history? This tutorial will walk you through the basics of committing changes before diving into the more advanced and "dangerous" Git commands.
Git is an open source, distributed version control system used to track many different projects. You can use it to manage anything from a personal notes directory to a multi-programmer project.
This tutorial provides a short walk through of basic git commands and the Git philosophy to project management. Then we’ll dive into an exploration of the more advanced and “dangerous” Git commands. Watch as we rewrite our repository history, track bugs down to a specific commit, and untangle commits into an LKML-worthy patchset.
This document provides a summary of Git in 10 minutes. It begins with an overview and breakdown of the content which includes explanations of what Git is, how it works, the GitHub flow, frequently used commands, confusions around undoing changes, and useful links. The body then delves into each section providing more details on Distributed version control, local vs remote operations, the GitHub flow process, example commands for undoing changes, and resources for additional learning.
This slide discusses the most popular distributed version control system that is GIT and it's different commands that we need in our daily operations for project collaboration.
This document provides an overview of Git and its basic commands for beginners. It covers installing Git, creating repositories on Bitbucket and GitHub, tracking changes with commands like add, commit, push, pull, and resolving merge conflicts. It also discusses branching, tagging, reverting changes, and ignoring files. Key concepts explained include distributed version control, staging changes, commit histories, and setting up aliases and submodules.
Git 101 - Crash Course in Version Control using GitGeoff Hoffman
Find out why more and more developers are switching to Git - distributed version control. This intro to Git covers the basics, from cloning to pushing for beginners.
Git allows for a distributed model where every user has their own local copy of the code and changes are merged to a local master branch, while SVN uses a centralized model where changes are committed to a central repository. Git operations like diff and commit are much faster since they are performed locally without network latency. Git also uses much less storage space than SVN. A key advantage of Git is its powerful branching and merging capabilities.
The everyday developer's guide to version control with GitE Carter
Git is a distributed version control system that allows developers to track changes in source code. It provides tools to commit changes locally, branch code for parallel development, and collaborate remotely by pushing and pulling changes from a shared repository. Common Git commands include init to create a repository, add and commit to save changes locally, checkout to switch branches, pull to retrieve remote changes, and push to upload local changes. Git helps developers work efficiently by enabling features like branching, undoing mistakes, and viewing the revision history.
Git provides a distributed version control system that is faster and more lightweight than the centralized SVN. Git allows for easy branching and merging of code. Developers can work independently on their local repositories and sync changes to remote repositories. This allows teams to work together seamlessly on codebases.
Git is a distributed version control system that allows developers to work collaboratively on projects. It works by creating snapshots of files in a project over time. Developers can commit changes locally and then push them to a remote repository to share with others. Key Git concepts include repositories, commits, branches, cloning repositories from remote locations, and commands like push, pull, commit, log and diff to manage changes.
The document discusses Git and GitHub. It begins with an overview of distributed version control systems (DVCS) like Git and how they differ from centralized version control systems. It then covers the basics of Git, including installing Git, initializing repositories, tracking changes, branching and merging. Finally, it discusses GitHub and how developers can use features like forking, pull requests and wikis to collaborate on projects hosted there. Common Git workflows like Git flow are also introduced.
Git is a version control system that stores snapshots of files rather than tracking changes between file versions. It allows for offline work and nearly all operations are performed locally. Files can exist in three states - committed, modified, or staged. Commits create snapshots of the staged files. Branches act as pointers to commits, with the default branch being master.
Do you know the basics of Git but wonder what all the hype is about? Do you want the ultimate control over your Git history? This tutorial will walk you through the basics of committing changes before diving into the more advanced and "dangerous" Git commands.
Git is an open source, distributed version control system used to track many different projects. You can use it to manage anything from a personal notes directory to a multi-programmer project.
This tutorial provides a short walk through of basic git commands and the Git philosophy to project management. Then we’ll dive into an exploration of the more advanced and “dangerous” Git commands. Watch as we rewrite our repository history, track bugs down to a specific commit, and untangle commits into an LKML-worthy patchset.
This document provides a summary of Git in 10 minutes. It begins with an overview and breakdown of the content which includes explanations of what Git is, how it works, the GitHub flow, frequently used commands, confusions around undoing changes, and useful links. The body then delves into each section providing more details on Distributed version control, local vs remote operations, the GitHub flow process, example commands for undoing changes, and resources for additional learning.
This slide discusses the most popular distributed version control system that is GIT and it's different commands that we need in our daily operations for project collaboration.
This document provides an overview of Git and its basic commands for beginners. It covers installing Git, creating repositories on Bitbucket and GitHub, tracking changes with commands like add, commit, push, pull, and resolving merge conflicts. It also discusses branching, tagging, reverting changes, and ignoring files. Key concepts explained include distributed version control, staging changes, commit histories, and setting up aliases and submodules.
Git 101 - Crash Course in Version Control using GitGeoff Hoffman
Find out why more and more developers are switching to Git - distributed version control. This intro to Git covers the basics, from cloning to pushing for beginners.
git est un outil essentiel pour la gestion des versions des codes sources des projets informatiques pour les développeurs travaillant en équipe comme ceux qui travaillent depuis plusieurs ordinateurs à la fois.
Utilisé conjointement à des systèmes d'intégration continue, il permet de générer des tests automatiques, des binaires, des versions de production comme de test de logiciels avec un minimum d'action de la part des développeurs.
Cependant il faut quand même maîtriser ses bases pour en tirer le meilleur : savoir comment gérer des branches, les commit et les fichiers qui doivent se trouver dans un "projet git".
Il est également bien de savoir créer et participer à des projets open source pour partager ses connaissances et compétences avec la communauté de développeurs. git est très utile pour accéder à GitHub et d'autres outils de stockage de sources et de gestion de projets logiciels.
Lors de cette présentation proposée le 22 décembre 2020, Patrick Prémartin explique le fonctionnement de base de git et comment s'en servir conjointement à l'IDE de RAD Studio utilisé pour du développement Delphi comme C++Builder.
Rediffusion de cette présentation et liens complémentaires sur https://serialstreameur.fr/webinaire-20201222.php
Cette présentation montre plusieurs outils gratuits qui peuvent être utilisés pour gérer plusieurs aspects de la gestion de projets, en particulier informatique, de manière collaborative. On y voit comment versioner son code avec Git, déployer son code avec Heroku, tester son code avec Travis, gérer et planifier son temps et ses tâches avec Trello, FreedCamp et Tom'splanner, comment communiquer avec Slack et comment rédiger sa documentation avec Read the Docs.
Depuis quelques années Git s'est imposé comme le système de gestion de sources de référence. Simple, rapide , souple, il convient à la fois aux workflows traditionnels et aux workflows distribués. Après une introductions aux principes fondateurs de Git le stagiaire aura l'occasion d'apprendre à créer son premier repository git et à le manipuler localement avant de le partager avec les autres. La formation insistera sur la gestions des branches et la résolution des conflits et sur les commandes permettant d'aborder ces problématiques sereinement. A l'issue de cette formation le stagiaire sera autonome pour utiliser Git aussi bien individuellement qu'au sein d'une équipe.
1. git pour les novices
Pierre Sudron
Association Atilla
10 aoˆut 2013
2. git est un syst`eme de gestion de sources
• g´erer l’´evolution d’un code
• partager efficacement son travail en ´equipe
• garder un historique de l’´evolution d’un projet
• travailler en parall`ele
2 / 96
3. Autres syst`emes existants
• Subversion (svn)
• Mercurial (Hg)
• Bazaar (bzr)
• autres syst`emes propri´etaires
3 / 96
4. Plus particuli`erement sur git
• cr´e´e pour le noyau Linux
• d´evelopp´e par Junio Hamano
• distribu´e et tr`es flexible
• adoption rapide et massive depuis 2005
4 / 96
5. Qu’est-ce que git peut m’apporter ?
• suivi pr´ecis de l’avancement d’un projet
• souplesse dans l’´evolution
• facilit´e de mise en commun
5 / 96
6. Int´egration douloureuse : un projet qui fait plouf
Bob et Bob travaillent sur un projet
et se r´epartissent les tˆaches
6 / 96
7. `A deux jours du livrable...
Bob a bien avanc´e sur sa partie
7 / 96
9. C’est l’heure de mettre en commun !
Et quelle surprise, ¸ca marche pas !
9 / 96
10. Et `a 24 heures du rendu, c’est un peu cuit...
10 / 96
11. L’int´egration progressive
• git incite `a mettre en commun tr`es r´eguli`erement
• en cas d’ennui, il est possible de revenir `a la derni`ere version
fonctionnelle
• de l`a, il est facile de voir les modifications ult´erieures et isoler le
code en cause
11 / 96
12. De quoi ai-je besoin ?
Ouvrir un terminal
(mais sous Linux, hein...)
12 / 96
13. Principes de fonctionnement
En local, on travaille avec 3 ´el´ements :
dossier de
travail
fichiers
index´es
d´epˆot local
13 / 96
14. Contenu d’un d´epˆot git
Succession de commits
Un commit est un jeu de modifications, c’est l’atome de git.
14 / 96
16. Partie 1 : C’est un voyage qu’il faut commencer seul
versionnage d’un simple fichier texte
16 / 96
17. Configuration de git : qui suis-je ?
git retrace l’´evolution du projet ainsi :
qui a fait quoi, et quand
Pour d´efinir qui est l’utilisateur :
g i t c o n f i g −−g l o b a l user . name ” Votre nom”
g i t c o n f i g −−g l o b a l user . email ” r o o t @ a t i l l a . org ”
Pour activer la couleur dans le terminal :
g i t c o n f i g −−g l o b a l c o l o r . ui auto
17 / 96
18. Pr´eparer le projet
Se placer dans le dossier de travail (le cr´eer si besoin) :
mkdir ˜/ f o r m a t i o n g i t
cd ˜/ f o r m a t i o n g i t /
Initialiser git dans ce r´epertoire :
g i t i n i t
18 / 96
19. Comment ¸ca se pr´esente
r´epertoire de travail : vide
fichiers index´es : vide
d´epˆot local : initialis´e et vide
19 / 96
20. Cr´eer un fichier
Sans changer de dossier, cr´eer un fichier README avec le contenu
suivant :
Formation g i t
Enregistrer le fichier
20 / 96
21. Comment ¸ca se pr´esente
r´epertoire de travail : README
fichiers index´es : vide
d´epˆot local : initialis´e et vide
21 / 96
22. Constater les changements avec git status
g i t s t a t u s
README n’est pas index´e, on nous propose d’utiliser git add
22 / 96
24. Comment ¸ca se pr´esente
r´epertoire de travail : README
fichiers index´es : README (nouveau fichier)
d´epˆot local : initialis´e et vide
24 / 96
25. Constater les changements avec git status
g i t s t a t u s
README est dans l’index en tant que nouveau fichier
25 / 96
26. Notre premier git commit
On va mettre `a jour le d´epˆot local et laisser une trace de la cr´eation
du fichier README
g i t commit −m ” Ajout du f i c h i e r README”
Tout commit est d´ecrit par un message, il doit ˆetre :
• pr´ecis
• concis
26 / 96
27. Comment ¸ca se pr´esente
r´epertoire de travail : README
fichiers index´es : vide
d´epˆot local : commit #1
(v´erifier avec git status)
27 / 96
29. Poursuivons le travail...
Ajouter une ligne `a la fin du fichier README :
Formation g i t
Avec l ’ a s s o c i a t i o n A t i l l a
Enregistrer le fichier
29 / 96
30. Comment ¸ca se pr´esente
r´epertoire de travail : README (modifi´e)
fichiers index´es : vide
d´epˆot local : commit #1
30 / 96
31. Constater les changements avec git status
g i t s t a t u s
Les fichiers modifi´es sont d´etect´es ; on propose de les indexer avec git
add
31 / 96
32. Indexation du fichier modifi´e
g i t add README
r´epertoire de travail : README (modifi´e)
fichiers index´es : README (modifi´e)
d´epˆot local : commit #1
(v´erifier avec git status)
32 / 96
33. Validation des changements
g i t commit −m ” M o d i f i c a t i o n du f i c h i e r README”
r´epertoire de travail : README (modifi´e)
fichiers index´es : vide
d´epˆot local : commit #1, commit #2
(v´erifier avec git status)
33 / 96
36. Export vers un d´epˆot git en ligne
Nous utiliserons une instance GitLab disponible `a l’adresse :
http://gitlab.etude.eisti.fr/
Il existe de nombreux sites permettant d’h´eberger vos projets git,
dont :
• GitHub
• Gitorious
36 / 96
39. Cr´eer une cl´e SSH
Ouvrez un nouveau terminal :
ssh−keygen −t rsa −C ” e m a i l @ t r o l l . com”
La cl´e SSH permet :
• de vous identifier formellement
• de crypter de transfert de code entre vous et le serveur
39 / 96
40. Indiquer la cl´e publique `a GitLab
Le RSA est un cryptage asym´etrique, et cr´e´e un jeu de deux cl´es
• une cl´e priv´ee
• une cl´e publique
Pour afficher la cl´e publique :
cat . ssh / i d r s a . pub
• ajouter la cl´e publique au trousseau GitLab
(vous pouvez fermer le second terminal et revenir au pr´ec´edent)
40 / 96
41. Ajouter le d´epˆot dans votre projet
g i t remote add o r i g i n [ ad r e ss e du depot ]
• origin : nom donn´e au serveur distant par convention
Vous trouverez l’adresse de votre d´epˆot sur sa page d’accueil.
41 / 96
42. Mettre le projet en ligne !
g i t push −u o r i g i n master
• origin : nom donn´e au serveur distant par convention
• master : nom donn´e au d´epˆot local par d´efaut
master origin
42 / 96
43. Voir le r´esultat sur GitLab
Il ne reste plus qu’`a constater le r´esultat avec satisfaction !
43 / 96
45. Partie 2 : Travailler `a plusieurs
d´ecouverte des fonctionnalit´es de partage
45 / 96
46. De quoi ai-je besoin ?
logiciel Meld
prenez un moment pour l’installer avant de continuer...
46 / 96
47. Acc`es aux projets
Un projet n’est visible que pour les membres de l’´equipe en charge.
Les ´equipes comportent diff´erents niveaux de responsabilit´e :
• Master
• Developer
• Reporter
• Guest
47 / 96
48. Cloner un d´epˆot existant
• r´ecup´erer l’adresse du d´epˆot
• cloner le d´epˆot (cette op´eration cr´e´e le r´epertoire du projet)
g i t clone [ a d re s s e ]
48 / 96
49. Cloner un d´epˆot existant
Le projet Participants formation contient un seul fichier dans lequel
chacun va ajouter son nom.
• assurez-vous que vous ˆetes inscrit au projet comme d´eveloppeur
• clonez le d´epˆot sur votre machine
• tout le monde doit ˆetre `a la mˆeme version
49 / 96
50. Allons y...
• ajoutez votre nom `a la fin du fichier
• faites un commit
• essayer de push...
oui, ¸ca veut dire
PA - TA - TRAS !
50 / 96
51. Qu’est-ce que j’ai fait pour m´eriter ¸ca ?
Si il y a un mot `a retenir dans le message d’erreur :
non-fast-forward signifie que vous ´ecraseriez les commits d’autres si
git vous laissait push.
51 / 96
52. Qu’est-ce qui s’est pass´e ?
Un fichier a ´et´e modifi´e et mis en ligne depuis votre dernier pull.
52 / 96
53. Comment s’en sortir ?
On souhaiterait appliquer nos commits `a la suite de ceux des autres.
C’est une op´eration de rebase.
53 / 96
54. Chacun son tour
• r´ecup´erer les derniers commits en ligne et rebaser nos commits `a
partir de l`a
g i t p u l l −−rebase
• cette op´eration peut soulever un conflit bloquant car plusieurs
personnes ont modifi´e le mˆeme fichier
54 / 96
55. Les conflits
Un conflit a lieu quand on cherche `a mettre en commun deux fichiers
dont les mˆemes sections ont ´et´e modifi´ees par deux personnes.
55 / 96
56. R´esoudre un conflit bloquant un rebase
Le message d’erreur du "pull –rebase nous indique les deux ´etapes `a
suivre :
• corriger les conflits dans les fichiers continus
• achever et valider le rebase avec
g i t rebase −−continue
56 / 96
57. G´erer les conflits avec une interface
Pour r´esoudre le conflit nous allons utiliser l’ONU Meld. Notez qu’il
existe ´enorm´ement de logiciels ´equivalents.
• d´efinir Meld comme outil de gestion de conflit
g i t c o n f i g −−g l o b a l merge . t o o l meld
• commencer `a g´erer le conflit
g i t mergetool
57 / 96
58. G´erer des conflits avec une interface
Meld (comme ses ´equivalents) pr´esente sur trois colonnes, trois
version du fichier :
• locale `a gauche : votre derni`ere version de la branche r´eceptrice
• remote `a droite : la derni`ere version de la branche `a fusionner
• origin au centre : la derni`ere version commune aux deux branches
Dans la pratique, on enregistrera le r´esultat voulu dans la colonne
centrale, c’est `a dire sur origin.
58 / 96
59. Finaliser la r´esolution de conflits
mergetool cr´e´e un fichier de sauvegarde <fichier>.orig, on peut
les supprimer une fois la session mergetool termin´ee
Il reste `a teminer l’op´eration de rebase
g i t rebase −−continue
59 / 96
60. Partager son travail
Il n’y a plus de probl`eme de fast forward : on peut d´esormais push.
60 / 96
61. Partie 3 : Comment ¸ca va vieille branche ?
d´evelopper en parall`ele
61 / 96
63. C’est l’histoire d’un prof...
Jean-Paul a fini de r´ediger le poly du cours de cette ann´ee, en LATEX
bien entendu !
Il souhaite continuer `a rajouter des parties pour l’ann´ee suivante tout
en gardant une version de cette ann´ee afin de corriger les coquilles
que ses ´el`eves lui signalent.
Mais comme Jean Paul n’est pas tr`es organis´e, nous allons l’aider `a
mieux g´erer son texte de cours avec git et les branches !
63 / 96
64. Le principe des branches
Fourche dans le processus de d´eveloppement du projet. Une branche
d´emarre `a partir d’un commit donn´e.
64 / 96
65. Le principe des branches
Nous allons cr´eer une branche d´edi´ee aux corrections des fautes
d’orthographe sur une branche partant de la version distribu´ee du poly.
65 / 96
66. Pr´eparation du projet
• cr´eer un dossier formation git branches
• d´eplacer le fichier cours.tex fourni dans ce dossier
cd f o r m a t i o n g i t b r a n c h e s
g i t i n i t
g i t g i t add cours . tex
g i t commit −m ” Version r e n t r e e ”
66 / 96
67. Cr´eer une branche
La branche est cr´e´ee `a partir du dernier commit local (HEAD).
g i t branch r e n t r e e s u i v a n t e
Pour lister les branches existantes :
g i t branch
67 / 96
68. Sauter de branche en branche
g i t checkout r e n t r e e s u i v a n t e
La commande git branch donne le r´esultat suivant :
68 / 96
69. Ajouter un nouveau paragraphe pour la rentr´ee
prochaine
Jean-Paul, studieux comme toujours, ne tarde pas `a rajouter du
contenu pour l’ann´ee prochaine.
´Editer le fichier cours.tex en ajoutant une ligne `a la fin.
Sauvegarder, fermer l’´editeur de texte et commiter.
g i t add cours . tex
g i t commit −m ”Nouveau paragraphe ”
69 / 96
70. Revenir sur la branche principale pour une correction
Mince ! On a signal´e la pr´esence de fautes d’orthographe dans le poly
de cette ann´ee.
Retourner sur la branche principale
g i t checkout master
Ouvrir le fichier cours.tex avec un ´editeur. V´erifier qu’il s’agit bien
de la version de cette rentr´ee.
Corriger les fautes, enregistrer, commiter.
70 / 96
71. Visualiser les commits selon leur branche
g i t log −−o n e l i n e −−graph −−a l l
le log se lit de bas en haut
71 / 96
72. Fusionner deux branches
La rentr´ee suivante est arriv´ee (¸ca passe vite), et Jean-Paul voudrait
int´egrer ses nouvelles parties tout en conservant les corrections faites
en cours d’ann´ee.
72 / 96
73. Fusionner deux branches
Se placer dans la branche qui va ”int´egrer” les commits de l’autre
g i t checkout master
R´ealiser la fusion
g i t merge r e n t r e e s u i v a n t e
... et l`a : Merge conflict !
Certains paragraphes ont un contenu diff´erent, il va falloir g´erer ¸ca `a
la main.
73 / 96
74. G´erer un merge conflict
Ouvrir le fichier cours.tex. git a modifi´e son contenu pour mettre en
´evidence le conflit.
<<<<<<< HEAD
ancien contenu
=======
nouveau contenu
>>>>>>> r e n t r e e s u i v a n t e
git status permet de voir sur quels fichiers il existe des conflits :
74 / 96
75. G´erer un merge conflict
La d´emarche `a suivre pour r´esoudre le conflit :
• corriger les conflits dans chaque fichier concern´e
• v´erifier que tous les conflits sont corrig´es avec git status
• indexer (git add) tous les fichiers modifi´es dans la manipulation
• commiter (git commit), on appelle ¸ca un ’merge commit’
75 / 96
76. Corriger des conflits dans un fichier plus facilement
Il est assez compliqu´e de s’en sortir avec ¸ca :
<<<<<<< HEAD
ancien contenu
=======
nouveau contenu
>>>>>>> r e n t r e e s u i v a n t e
On va utiliser un outil graphique : Meld (il existe ´enorm´ement
d’´equivalents)
76 / 96
77. Corriger des conflits dans un fichier plus facilement
g i t mergetool
mergetool va lancer Meld (ou ´equivalent) pour chaque fichier o`u il y a
un conflit.
77 / 96
78. Utiliser Meld
Meld (et ´equivalents) pr´esente sur trois colonnes, trois version du
fichier :
• locale `a gauche : votre derni`ere version de la branche r´eceptrice
• remote `a droite : la derni`ere version de la branche `a fusionner
• origin au centre : la derni`ere version commune aux deux branches
Dans la pratique, on enregistrera le r´esultat voulu dans la colonne
centrale, c’est `a dire sur origin.
78 / 96
79. Finaliser la r´esolution de conflits
mergetool cr´e´e un fichier de sauvegarde <fichier>.orig, on peut
les supprimer une fois la session mergetool termin´ee
Il faut faire un merge commit : valider la r´esolution des conflits au
sein d’un commit
g i t s t a t u s
g i t add cours . tex
g i t commit −m ”Merge dans master de r e n t r e e s u i v a n t e ”
79 / 96
80. Mettre en ligne votre branche
g i t push o r i g i n [ ma branche ]
ma branche origin
80 / 96
81. Terminer une branche
g i t branch −d r e n t r e e s u i v a n t e
Il possible de terminer seulement une branche qui a ´et´e merge et n’a
pas ´et´e modifi´ee depuis. Pour forcer la suppression d’une branche :
g i t branch −D r e n t r e e s u i v a n t e
81 / 96
82. Partie 4 : remonter le temps
C’est moi Doc ! Je suis de retour du futur...
82 / 96
83. Acc`es `a un commit
• HEAD : dernier commit de la branche courante
• nom branche/HEAD : dernier commit de la branche nom branche
• donner le nom d’une branche revient `a pointer vers le dernier
commit de cette branche
Il est possible de se ”d´eplacer” relativement `a un commit
• HEADˆ : un commit avant HEAD
• HEADˆˆ : deux commits avant HEAD
• HEAD˜42 : quarante deux commits avant HEAD
83 / 96
84. Acc`es `a un commit
• trouver l’identifiant court d’un commit
g i t log −−o n e l i n e
• master@{20/09/2012} : prendre un commit `a une date donn´ee
84 / 96
85. Voyager dans le temps
• mettre un fichier tel qu’il ´etait `a un commit donn´e
g i t checkout [ nom commit ] [ f i c h i e r ]
Cette manipulation modifie directement le fichier dans votre
r´epertoire de travail.
• remettre un fichier ”en l’´etat”
g i t checkout HEAD [ f i c h i e r ]
85 / 96
86. Annexe 1 : Quelques conseils
tout va bien se passer...
86 / 96
87. Commitez bien, commitez souvent
• segmentez les tˆaches, faites un commit d`es que possible
• ne commitez pas sciemment un code qui ne marche pas
87 / 96
88. Les branches c’est bon, mangez-en !
• s´eparez les tˆaches ind´ependantes
• n’h´esitez pas `a faire des exp´erimentations dans une branche d´edi´ee
• gardez une branche ”stable” `a tout moment de votre
d´eveloppement
88 / 96
89. Jouez collectif
• organisez-vous et concertez-vous avec vos partenaires
• donnez des titres compr´ehensibles `a vos commits
• suivez les avanc´ees des autres, donnez votre avis
• construisez votre cycle de d´eveloppement intelligemment : en
fonction de la taille et la nature de votre ´equipe, vos deadlines, etc.
89 / 96
90. Annexe 2 : Guide de survie
Comme Rambo, mais en mieux.
90 / 96
91. Au d´ebut de la journ´ee de travail
• je commence toujours par r´ecup´erer le travail des autres
g i t p u l l
• je v´erifie sur quelle branche je me trouve
g i t branch
g i t checkout
91 / 96
92. Quand je code
• j’ajoute mes fichier modifi´es `a l’index
g i t add
• je v´erifie mes modifications suivies
g i t s t a t u s
• je valide mes changements dans un commit
g i t commit
92 / 96
93. Partager mon travail
• je publie mon travail au moins en fin de journ´ee
g i t push
• en cas de fast-forward, j’applique mes modifications apr`es celles
des autres
g i t p u l l −−rebase
• en cas de conflit, je fait les modications `a la main
g i t mergetool
g i t rebase −−continue
93 / 96
94. Au secours, rien ne va plus !
• faire attention `a ce qu’on fait pour ´eviter les ennuis inutiles
• DON’T PANIC !
• prendre le temps de lire les messages d’erreur de git (ils donnent
souvent la solution)
• il existe de tr`es nombreuses ressources sur le net
94 / 96