# Git/Premiers pas

* Principes
* Apprendre à travailler avec Git
** Avant de commencer : installation et configuration de Git
** Création de votre dépôt local
** Visualiser le contenu de votre dépôt local
** Premiers pas
** Gestion des branches
** Synchroniser le dépôt local avec le dépôt distant
* Fonctionnalités avancées
** Étiquetage (tags)
** Remise (stash)
** Recombinaison (rebase)
** Sous-modules et Super-projets
** Structure interne
** Pull-request
* Recettes
** Exclure des fichiers du dépôt
** Écrire des messages de commit
* Environnement
** Intégration dans les IDEs
** Améliorer sa productivité en configurant Git
** Git sous Linux
** Git sous Windows
** Forges
*** GitLab
*** GitHub
*** Bitbucket
* Git et Subversion (svn)
** Passer de Subversion à Git
** Travailler avec Git local et un dépôt Subversion distant
** Participer au développement de Wikimédia (Gerrit)
* Problèmes connus
* Ressources externes
* Principes
* Apprendre à travailler avec Git
** Avant de commencer : installation et configuration de Git
** Création de votre dépôt local
** Visualiser le contenu de votre dépôt local
** Premiers pas
** Gestion des branches
** Synchroniser le dépôt local avec le dépôt distant
* Fonctionnalités avancées
** Étiquetage (tags)
** Remise (stash)
** Recombinaison (rebase)
** Sous-modules et Super-projets
** Structure interne
** Pull-request
* Recettes
** Exclure des fichiers du dépôt
** Écrire des messages de commit
* Environnement
** Intégration dans les IDEs
** Améliorer sa productivité en configurant Git
** Git sous Linux
** Git sous Windows
** Forges
*** GitLab
*** GitHub
*** Bitbucket
* Git et Subversion (svn)
** Passer de Subversion à Git
** Travailler avec Git local et un dépôt Subversion distant
** Participer au développement de Wikimédia (Gerrit)
* Problèmes connus
* Ressources externes
[ Modifier le sommaire ]

## Préalable

Nous allons maintenant entrer dans le vif du sujet et faire une première modification dans le code source d'une application.
Cette première expérience va nous permettre de découvrir plusieurs notions importantes : l'espace de travail et l'index.
On reprend l'exemple précédent.
Faisons d'abord un
qui va nous répondre
Git nous indique qu'il existe une seule branche appelée master et que c'est sur cette branche que nous travaillons comme l'indique l'astérisque en face de master.
Cela nous est confirmé par
qui nous répond
Vous pouvez faire un
Pour voir quel est l'auteur et la date de la dernière modification : cela nous servira de repère pour la suite.

## Ajouter un fichier dans la zone de transit

Commençons par une modification simple : l'ajout d'un fichier dans la staging area (la zone de transit vers la sauvegarde). Cela peut être une première étape si vous avez créer un dépôt vide.
Par exemple, créons un fichier mon_nouveau_fichier.txt avec un petit texte dedans.
Voyons la façon dont git perçoit ce nouveau fichier
Il nous indique qu'on est toujours sur la branche master, qu'il y a un fichier mon_nouveau_fichier.txt mais qu'il n'est pas suivi (« untracked ») par git.
Comme nous voulons intégrer ce fichier au projet, on ne peut pas encore faire le commit, car commit n'envoie que les fichiers qui sont *tracked*, c'est à dire dans l'index (*staging*). Ajoutons le fichier, comme git nous le suggère, avec add
On refait un
Et, cette fois, git nous répond
Le fichier mon_nouveau_fichier.txt sera bien intégré dans notre prochain commit. Allons-y :
Remarquons ici qu'avec -m, nous avons choisi de préciser le message de commit directement sur la ligne de commande. En lançant git commit tout court, l'éditeur de texte ($EDITOR) s'ouvre automatiquement pour inviter à saisir un commentaire de soumission.
Constatons immédiatement l'effet de ce commit :
Notre dernier commit apparaît, en premier de la liste (c'est le plus récent).
Avec
On voit clairement que notre commit est lié au commit précédent.

## Modifier un fichier

Faisons une autre modification. Par exemple, modifions le fichier mon_nouveau_fichier.txt en ajoutant une ligne.
Voyons ce que git nous dit :

### diff

Git nous indique bien que le fichier a été modifié, voyons le résumé de ces modifications telles qu'elles sont perçues par git :
Git nous montre la ligne qui a été ajoutée (le « + » en début de ligne).
Pour comparer une branche distante avec une locale, utiliser ".." :
sinon :

### add

On va maintenant faire le commit. Comme précédemment, il faut ajouter le fichier au *staging* :
Si vous voulez ajouter au staging tous les changements qui ont été effectués (fichiers ajoutés, modifiés, supprimés), il vous suffit de faire
ou

### commit

Remarquez le code « 5556307 » : il s'agit d'une abréviation de l'identifiant unique de l'objet Git (en l'occurrence une soumission). Chaque objet est haché en SHA-1. L'identifiant complet est en fait 5556307824d8d0425b38c9da696b84430e30f09f, mais généralement les huit premiers caractères suffisent à l'identifier à coup sûr.
On voit bien que nos deux commits se succèdent.

## Supprimer un fichier

Il n'est pas nécessaire de faire un add.

### Annuler une suppression

Certains outils comme PyCharm sont dotés d'un historique local (en plus de celui de Git) qui permet d'annuler un "git rm". Il est accessible via un clic droit sur le dossier à restaurer.

## Regrouper des modifications

Il est possible de fusionner une soumission avec la dernière révision, via l'argument amend, sans avoir à réécrire leur résumé avec no-edit :
Généralement on l'utilise pour mettre à jour un commit :
Si la cible n'est pas la dernière révision, on peut annuler les intermédiaires (via git reset) jusqu'à ce qu'elle le devienne, puis ensuite, replacer les commits annulés avec :
* git cherry-pick xxx (où xxx est l'ID du commit)
Par ailleurs, certains logiciels clients Git permettent de rassembler plusieurs révisions sélectionnées depuis une liste, comme la fonction cherry-pick de SmartGit ou NetBeans qui permet de sélectionner des commits existant pour les intégrer à sa branche, ou git blame pour afficher les auteurs de chaque passage.
En console, annuler ou modifier un commit peut être réalisé de plusieurs manières :
* git commit --amend --no-edit
* git reset HEAD~1
* git rebase -i (puis squash)
En cas de réécriture d'historique, le hash du commit change, ce qui ne pose pas de problème en local mais complexifie considérablement les rebases des branches issues de celle réécrite, car Git voit des conflits entre le commit original et celui réécrit.
Pour modifier le résumé d'un ancien commit (xxx) : git rebase --interactive 'xxx^'
Il faut donc éviter de les multiplier : ne pas en enchainer plusieurs avec le même résultats, ou en créer des “fix” du précédent. Il faut les casser et les regrouper. Ainsi les rebase auront moins de conflit, les git blame seront parlant et les git revert de feature deviendront possibles. Dans cette optique, il faut d'ailleurs préférer les rebases aux merges pour éviter l'ajout d'un commit de merge inutile nuisant à la lisibilité et à la taille du dépôt.

## Recherche dans l'historique

Pour rechercher un mot dans tous les historiques de tous les fichiers (du répertoire et des sous-répertoires du script) :
Par ailleurs, git bisect permet de rechercher dans l'historique des révisions en définissant les mauvais et bon commits.

## Continuer

Vous maîtrisez désormais le strict minimum pour travailler avec git. Vous pouvez ajouter, modifier et supprimer des fichier et enregistrer les changements dans votre dépôt local ainsi que consulter l'historique des modifications. Cela reste toutefois une vision simpliste de la gestion de projet et nous verrons dans la suite comment exploiter les branches locales et comment partager votre travail avec d'autres contributeurs en publiant vos modifications sur un dépôt distant et en récupérant les modifications des autres contributeurs.

## Références

* ↑ http://git-scm.com/docs/git-add
* ↑ « Rewriting Git History », Git’s now confused
* ↑ https://git-scm.com/docs/git-bisect
* https://learngitbranching.js.org/ : explications schématisées