# Git/Branches

* 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écédemment, nous avons vu comment apporter des modifications à une branche telles que ajouter, modifier ou supprimer un fichier et commit nos modifications. Cela fonctionne parfaitement et cela peut suffire pour travailler seul sur un petit projet. Toutefois, ce n'est pas la meilleure façon de procéder sous git qui propose des mécanismes plus élaborés pour développer sur un projet.
L'approche de git est de favoriser l'utilisation de branche pour toute modification du code de l'application.
Ainsi, il ne faut jamais travailler directement sur la branche *master* : cette branche doit rester stable et ne doit être utilisée que pour baser son travail dans d'autres branches.
Pour mieux comprendre, nous allons refaire, pas à pas, exactement les mêmes modifications que celles que nous avons faites précédemment mais, cette fois, nous allons utiliser une branche afin de nous familiariser avec ce concept.
Reprenons notre dépôt d'exemple :

### Créer une première branche

D'abord, demandons à git de nous indiquer où nous en sommes au niveau des branches :
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.
Créons une nouvelle branche que nous allons appeler ma-branche.
Constatons les effets :
Il y a maintenant deux branches : *master* et *ma-branche*. Actuellement, nous travaillons toujours sur *master* comme l'indique toujours l'astérisque.
On peut voir, sur la première ligne que *master* et *ma-branche* sont au même niveau, sur le même commit. Nous allons maintenant demander à git de nous basculer sur *ma-branche* afin de pouvoir travailler sur celle-ci et non sur *master*.
On a basculé, et git branch nous le confirme.
git checkout . supprime le code non commité.

### Faire les modifications

On peut désormais faire les modifications dans ma-branche que l'on peut développer, sans prendre le risque de modifier master.
Faisons les mêmes modifications que précédemment :
Et ainsi de suite. Vous pouvez commiter et faire autant de commits que vous voulez dans ma-branche.
L'idée est que pour chaque évolution du logiciel développé, il faut créer une branche. Ainsi, on peut garder la branche aussi longtemps que nécessaire et continuer de travailler dessus tant qu'on a pas fini la fonctionnalité.
Regardons le log que cela produit :
Examinons ce graphique : master est en retard tandis que ma-branche est en avance de trois commits.

### Fusionner la branche dans master (merge)

Supposons que nous sommes satisfaits du travail réalisé dans notre branche. Nous avons fait plusieurs commits, nous avons vérifié que nous n'avons pas créé de bogue, etc. Supposons que notre branche est prête et qu'on peut intégrer les modifications dans master.
D'abord, se placer sur master :
Puis demander à git de fusionner la branche ma-branche, sans fast forward pour éviter de perdre la topologie de la branche :
Git va faire un commit pour intégrer les changements. Comme précédemment, nous avons choisi d'utiliser -m pour préciser le message de commit mais on aurait pu ne rien mettre et git nous aurait ouvert l'éditeur de texte.
Examinons
On retrouve bien quatre commits nous appartenant (symbolisés par une * dans le graphe). On retrouve les trois premières modifications et un quatrième commit pour le merge. On voit que les branches ont convergé sur le graphique et que master est de nouveau sur la première ligne tout en haut du graphe. Nos changements ont bien été intégré à master.

### Effacer une branche
#### Locale

Nos changements sont intégrés à master, la branche est désormais inutile. Supprimons-la :
La suppression de la branche peut échouer si la branche à supprimer n'a pas été fusionnée dans master :
Git se prémunit donc d'effacer des changements potentiellement non vérifiés. Comme git l'indique, on peut forcer la suppression malgré tout :
NB : une branche ne peut pas être supprimée si on n'a pas fait le dernier commit.

#### Supprimer les veilles branches

Lorsque l'on tape "git branch" après un certain temps, la branche active apparait au milieu d'une multitude d'anciennes branches généralement fusionnées, et donc inutile de conserver en local. Pour les nettoyer on utilise donc :
Mais parfois il reste encore un paquet de branches locales qui ont été mergées sur le serveur. Pour éviter d'avoir à les supprimer une par une :
Sinon, nommer la branche dans laquelle elles furent fusionnées. Par exemple, pour supprimer les branches mergées dans "master" :

## Renommer une branche

Il faut renommer la locale, supprimer la distante, puis pusher la locale :
L'option --set-upstream (alias -u) s'utilise uniquement à la création de la branche sur le serveur distant. Elle doit ensuite être mise à jour avec push tout court.

## Continuer

Vous pouvez à tout moment créer des nouvelles branches depuis master et ce, à chaque nouvelle fonctionnalité ou nouvelle modification qu'il faudrait apporter au projet. Git vous permet de gérer plusieurs branches en parallèle et ainsi de cloisonner vos travaux et d'éviter de mélanger des modifications du code source qui n'ont rien à voir entre elles.
En gardant une branche master saine, vous vous laissez la possibilité de créer de nouvelles branches simplement et vous conservez ainsi une version du logiciel prête à être livrée à tout instant (puisqu'on ne merge dedans que lorsque le développement est bien terminé.
git log vous permet de retrouver dans l'historique les branches qui ont été créées, et les différents commits réalisés pour une même fonctionnalité sont bien regroupés entre eux.

## Références

* ↑ http://stackoverflow.com/questions/9069061/what-is-the-difference-between-git-merge-and-git-merge-no-ff