# Git/Travailler avec Git local et un dépôt Subversion distant

* 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 ]
Git permet de participer à de nombreux autres systèmes de contrôle de version, comme git-svn ou git-cvsimport.

## SVN

La compatibilité entre Git et Subversion est assurée par git-svn qui autorise un utilisateur à accéder et participer à un dépôt SVN. Les utilisateurs peuvent générer des patchs locaux pour les envoyer par liste de diffusion, ou soumettre leurs changements aux dépôts d'origine.

### Premiers pas

Pour commencer à utiliser Git avec des projets sur des serveurs Subversion, il faut créer un dépôt local, et configurer git-svn :
Le paramètre "première révision" peut être "1", mais pour gagner du temps il est possible de ne prendre que les 10 dernières révisions. svn info indique alors ces révisions.
Généralement quand on travaille avec des dépôts Subversion, on communique l'URL du projet complète. Pour déterminer l'URL du dépôt racine :
Une ligne du résultat indique le dépôt racine. Le chemin du tronc est simplement le reste de l'URL qui suit.
Il est possible de simplement donner à git-svn l'URL complète du projet, mais cela peut stopper la possibilité de travailler sur des branches SVN.

#### Exemples

Obtenir Pywikipedia :
Récupérer AWB (AutoWikiBrowser) :
Cette opération de téléchargement peut prendre une heure.

### Interagir avec le dépôt

L'avantage de travailler avec Git sur des dépôts SVN est l'utilisation en local. Dans ce cas :
* Ne pas lancer git pull
* Dans une branche mieux vaut éviter de lancer git-svn dcommit car les soumissions fusionnées ont tendance à embrouiller git-svn. Par contre, combiner les changements avec ceux de Subversion en amont est équivalent à svn update :
La première et la dernière ligne ne sont pas nécessaires si l'arbre est propre.
Le git rebase trunk laisse les soumissions locales au dessus du HEAD SVN.

### Changements locaux

Pour éviter de propager des modifications locales indésirables (débogages, tests...), avec git svn dcommit, sans les perdre peut passer par deux approches.
Premièrement, maintenir une branche locale pour chacune qui devra contenir des changements locaux. Par exemple faire un rebase sur "branche1" au-dessus de "branche1-locale". Exemple :
Deux choix sont ensuite possibles, effectuer directement les changements sur la branche locale, ce qui est plus rapide que de les soumettre à la branche distante avant de les récupérer dans la locale. Ensuite il est possible d'utiliser git reset pour les retirer de la branche distante.
Comme une alternative à l'approche centrée recombinaison, il existe une méthode basée sur la fusion. Tout en conservant les changements sur une branche locale, mais sans avoir à conserver la branche au dessus de la branche locale par recombinaison.
C'est un avantage car :
* Sinon il y a plus à écrire.
* Historiquement, la recombinaison a souvent demandé de résoudre le même conflit deux fois, s'il survient pendant la première recombinaison.
Donc à la place des recombinaisons, on crée une nouvelle branche servant à la construction. Il faut la démarrer avec la soumission à tester. Ensuite git merge fusionne la branche locale, apportant tous les changements dans un seul arbre. La raison de cette fusion dans une branche reconstruction est pour dissuader l'utilisation de git-svn dcommit (qui soumettrait les tests indésirables sur le serveur).
Cette approche peut même rendre facultative la recombinaison quotidienne la branche avec le tronc. En cas de branches multiples, les recombinaisons permanentes peuvent s'avérer chronophages :
La construction contient ensuite les changements du tronc, branche1 et branche1-locale !
Il est possible de conserver plusieurs branches locales dont une avec les tests. Cette approche peut être développée avec une branche par sujet dans un arbre :
Malheureusement, la fusion de cette pieuvre ne résout pas les conflits. Dans ce cas il faut appliquer les fusions une par une :

### Envoyer des changements en amont

Éventuellement, pour soumettre au serveur des branches sujet avec un accès commit, on peut lancer git-svn dcommit. Cela prendra chaque soumission locale dans la branche courante et le soumettra à subversion. Par exemple avec trois soumissions locales, après dcommit il y aura trois nouvelles soumissions dans subversion.
Sans accès commit, le patch devra probablement être soumis via une liste de diffusion ou un logiciel de suivi de problèmes (bug tracker). Pour cela on peut utiliser git-format-patch. Par exemple pour trois soumissions locales :
Le résultat sera trois fichiers en $PWD, 0001-commit-name.patch, 0002-commit-name.patch, et 0003-commit-name.patch, qui pourront être attachés à des emails ou joint à Bugzilla. Remarque : il existe git-send-email pour envoyer les emails directement :
Si les séries de patchs ne sont pas dans l'ordre, voir git rebase -i.

## Références

* ↑ git-rebase
* ↑ http://www.kernel.org/pub/software/scm/git/docs/git-reset.html