| ... | ... | @@ -15,11 +15,11 @@ L'objectif de ce qui suit est de prendre en main l'outil de gestion de versions |
|
|
|
|
|
|
|
[<small>_Table of contents generated with markdown-toc_</small>](http://ecotrust-canada.github.io/markdown-toc/)
|
|
|
|
|
|
|
|
> ⚠️ _Les manipulations suivantes sont effectuées depuis un terminal Linux-compatible, les commandes ont des équivalents sous Windows._
|
|
|
|
> :warning:️ _Les manipulations suivantes sont effectuées depuis un terminal Linux-compatible, les commandes ont des équivalents sous Windows._
|
|
|
|
|
|
|
|
## Création d'un dépôt local
|
|
|
|
|
|
|
|
> ⚠️ _Dans la suite, on suppose que l'on se trouve dans un répertoire local `4git` (vide) où l'on souhaite commencer à développer_. Il est donc nécessaire de créer ce répertoire au besoin et de s'y déplacer.
|
|
|
|
> :warning:️ _Dans la suite, on suppose que l'on se trouve dans un répertoire local `4git` (vide) où l'on souhaite commencer à développer_. Il est donc nécessaire de créer ce répertoire au besoin et de s'y déplacer.
|
|
|
|
|
|
|
|
```
|
|
|
|
sebastienjean@MacBook-Air-749 ~ % mkdir 4git
|
| ... | ... | @@ -96,7 +96,7 @@ MacBook-Air-749:.git sebastienjean$ |
|
|
|
> - **comment ?** (_les changements opérés dans cette version_)
|
|
|
|
> - **où ?** (à quel commit, précédente version, ce commit est raccroché
|
|
|
|
|
|
|
|
Le fichier de configuration locale permet de paramétrer l'**identité de l'auteur** des commits, de sorte que l'outil _git_ les utilise automatiquement. Ceci se fait en ajoutant la section `\\\\\\\[user\\\\\\\]` à la suite de la section `\\\\\\\[core\\\\\\\]` déjà présente :
|
|
|
|
Le fichier de configuration locale permet de paramétrer l'**identité de l'auteur** des commits, de sorte que l'outil _git_ les utilise automatiquement. Ceci se fait en ajoutant la section `\[user\]` à la suite de la section `\[core\]` déjà présente :
|
|
|
|
|
|
|
|
```
|
|
|
|
[user]
|
| ... | ... | @@ -153,13 +153,13 @@ Cette situation est illustrée ci-dessous : |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
> 👀 Ces changements observés n'entrainent pas automatiquement la création d'une nouvelle version.
|
|
|
|
> :eyes: Ces changements observés n'entrainent pas automatiquement la création d'une nouvelle version.
|
|
|
|
|
|
|
|
### Préparation d'une nouvelle version
|
|
|
|
|
|
|
|
La **sélection des changements à intégrer** à la future nouvelle version est explicite et s'effectue s'effectue via la commande [`git add`](https://git-scm.com/docs/git-add) :
|
|
|
|
|
|
|
|
> ℹ️ On peut utiliser des _jokers_ pour ajouter simultanément plusieurs fichiers, un répertoire, ...
|
|
|
|
> :information_source:️ On peut utiliser des _jokers_ pour ajouter simultanément plusieurs fichiers, un répertoire, ...
|
|
|
|
|
|
|
|
```
|
|
|
|
MacBook-Air-749:4git sebastienjean$ git add unFichier.txt
|
| ... | ... | @@ -175,17 +175,17 @@ Changes to be committed: |
|
|
|
MacBook-Air-749:4git sebastienjean$
|
|
|
|
```
|
|
|
|
|
|
|
|
> 👀 Dans le cas d'un nouveau fichier (_untracked_), la commande `git add` étiquette automatiquement le fichier comme étant dorénavant suivi (_tracked_)
|
|
|
|
> :eyes: Dans le cas d'un nouveau fichier (_untracked_), la commande `git add` étiquette automatiquement le fichier comme étant dorénavant suivi (_tracked_)
|
|
|
|
|
|
|
|
La situation résultante est illustrée ci-dessous :
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Les changements pris en compte sont déplacés par _git_ dans une zone nommée `staged`. :warning: Cette prise en compte n'entraine pas automatiquement la création d'une nouvelle version.
|
|
|
|
Les changements pris en compte sont déplacés par _git_ dans une zone nommée `staged`.
|
|
|
|
|
|
|
|
La validation de la nouvelle version proprement dite est également une opération explicite.
|
|
|
|
|
|
|
|
**N.B**. : On peut annuler la prise en compte des changements pour un fichier via la commande `git rm --cached` (de fait, le changement est rebasculé dans la zone `unstaged`).
|
|
|
|
> :warning: Cette prise en compte n'entraine pas automatiquement la création d'une nouvelle version. La validation de la nouvelle version proprement dite est également une opération **explicite**.
|
|
|
|
>
|
|
|
|
> :information_source:️ On peut annuler la prise en compte des changements pour un fichier via la commande `git rm --cached` (de fait, le changement est rebasculé dans la zone `unstaged`).
|
|
|
|
|
|
|
|
### Création d'une nouvelle version
|
|
|
|
|
| ... | ... | @@ -199,7 +199,9 @@ MacBook-Air-749:4git sebastienjean$ git commit -m "ajout d'un fichier" |
|
|
|
MacBook-Air-749:4git sebastienjean$
|
|
|
|
```
|
|
|
|
|
|
|
|
L'option `-m` permet ici de spécifier le message de commit. Celui-ci répond à la question _Pourquoi ?_ de la nouvelle version (les changements pris en compte répondent à la question _Comment ?_, la date d'exécution de la commande répond à la question _Quand ?_, les propriétés de la section `\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\[user\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\]` du fichier de configuration répondent quant à eux à la question _Qui ?_).
|
|
|
|
L'option `-m` permet ici de spécifier le **message** de commit.
|
|
|
|
|
|
|
|
Celui-ci répond à la question _`Pourquoi ?`_ de la nouvelle version (les changements pris en compte répondent à la question _`Comment ?`_, la date d'exécution de la commande répond à la question _`Quand ?`_, les propriétés de la section `\[user\]` du fichier de configuration répondent quant à eux à la question _`Qui ?`_).
|
|
|
|
|
|
|
|
Le message de commit est constitué d'un **résumé** qui doit tenir **sur une ligne** et une **description détaillée optionnelle**, de longueur variable et séparée du résumé par une **ligne vide**. L'option `-m` permet d'indiquer rapidement et facilement un message sans description détaillée. De façon plus générale, sans l'option `-m`, l'exécution de la commande est déroutée vers un éditeur de texte qui permet de rédiger un message adapté à la situation.
|
|
|
|
|
| ... | ... | @@ -335,7 +337,7 @@ index ee051bd..53c5f7f 100644 |
|
|
|
MacBook-Air-749:4git sebastienjean$
|
|
|
|
```
|
|
|
|
|
|
|
|
- `HEAD` Vs `HEAD\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\~1` (la version parente de `HEAD`) :
|
|
|
|
- `HEAD` Vs `HEAD\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\~1` (la version parente de `HEAD`) :
|
|
|
|
|
|
|
|
```diff
|
|
|
|
MacBook-Air-749:4git sebastienjean$ git diff HEAD~1 HEAD unFichier.txt
|
| ... | ... | @@ -348,7 +350,7 @@ index 927b61b..ee051bd 100644 |
|
|
|
+Une autre ligne de texte
|
|
|
|
```
|
|
|
|
|
|
|
|
- _Working Tree_ Vs `HEAD\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\~1` :
|
|
|
|
- _Working Tree_ Vs `HEAD\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\~1` :
|
|
|
|
|
|
|
|
```diff
|
|
|
|
MacBook-Air-749:4git sebastienjean$ git diff HEAD~1 unFichier.txt
|
| ... | ... | @@ -361,7 +363,7 @@ index 927b61b..53c5f7f 100644 |
|
|
|
+Encore une autre ligne de texte
|
|
|
|
```
|
|
|
|
|
|
|
|
**N.B.** : On peut aussi utiliser en paramètre les _hash_ des commits (abbréviés ou non) mais il est parfois plus simple de se répérer par rapport à `HEAD` (`\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\~1` pour le commit parent, `\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\~2` pour le commit grand-parent, ...) ou même par rapport à `Master` (de la même manière).
|
|
|
|
**N.B.** : On peut aussi utiliser en paramètre les _hash_ des commits (abbréviés ou non) mais il est parfois plus simple de se répérer par rapport à `HEAD` (`\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\~1` pour le commit parent, `\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\~2` pour le commit grand-parent, ...) ou même par rapport à `Master` (de la même manière).
|
|
|
|
|
|
|
|
### Restauration de versions
|
|
|
|
|
| ... | ... | |
