Git on Jean-Christophe Gay

Fusion de dépôts Git

Sun, 07 Feb 2016 13:37:00 +0200

Comment fusionner de multiples dépôts Git en un seul ?

What ?!
#

Récemment j’ai eu besoin de fusionner tout un tas de dépôts Git en un seul. Une collection d’applications et de socles métier répartis sur 6 dépôts. Bien sûr des dépendances binaires entre tout ce petit monde et toujours sur la dernière version en cours de développement. Observant que le cycle de vie des projets étaient toujours le même on a voulu simplifier nos processus (branches, gestion de dépendances, build, release, etc.) sans aller jusqu’à la pratique du mono dépôt (comme chez Google par exemple).

Mise en place
#

On veut bien entendu garder l’historique de tous nos projets, il n’est pas question de repartir de zéro 😅.

Il existe un projet, git-merge-repos qui permet de faire le travail en essayant de préserver les branches et les tags.

Le résultat attendu est un dépôt unique contenant tous les projets désirés :

new-repo
├── project-1
├── project-2
├── project-3
└── project-4

On peut utiliser deux stratégies pour faire ce merge :

Réaliser un merge (avec n parents) et déplacer chaque projet dans son sous-dossier dans le commit de merge
Réécrire l’histoire de chaque dépôt pour déplacer chaque contenu de commit dans un sous-dossier et réaliser le merge à la fin.

J’ai d’abord testé avec la première option, le problème est qu’on ne voit plus l’historique d’une ressource après le commit de merge global.

Par exemple :

> git log -- project-1

ne retourne qu’une seule entrée, le commit de merge.

La solution 2 est donc vendue !

Par contre comme on doit réécrire l’historique de chaque dépôt, il faut trouver un moment où une seule branche est en cours de développement (dans mon cas master).

Pour chaque dépôt :

 > git clone --mirror git@example.com:project-1.git
 > cd project-1
 > git filter-branch --index-filter \
 'tab=$(printf "\t") && git ls-files -s --error-unmatch . >/dev/null 2>&1; [ $? != 0 ] || (git ls-files -s | sed "s-$tab\"*-&project1/-" | GIT_INDEX_FILE=$GIT_INDEX_FILE.new git update-index --index-info && mv "$GIT_INDEX_FILE.new" "$GIT_INDEX_FILE")' \
 --tag-name-filter cat \
 -- --all

où project1 doit être remplacé par le sous-dossier dans lequel on veut transférer le projet.

J’en ai profité aussi pour renommer les tags, git-merge-repos s’occupe aussi de recréer les tags dans le dépôt final sur la base de leurs noms. Dans mon cas je ne le voulais pas vraiment, des tags sur différents dépôts portaient le même nom mais n’étaient pas forcément équivalents.

> git tag | xargs -I '{}' sh -c 'git tag project-1-{} {} && git tag -d {}'

L’opération finale est le lancement la fusion :

> git clone git@github.com:robinst/git-merge-repos.git
> cd git-merge-repos
> ./run.sh /absolute/path/to/project-1:. /absolute/path/to/project-2:.

Le résultat se trouve dans un dossier merged à la racine de git-merge-repos.

Avantages
#

L’intendance est plus facile (création de branches, merge, etc)
On a aujourd’hui de vrais commits atomiques pour la réalisation d’une fonctionnalité. Avant on se retrouvait tout le temps avec des commits sur différents dépôts et ce n’était pas toujours facile à tracer ou pour investiguer sur des régressions
La gestion des dépendances est plus simple, tout le code est dans le même dépôt
Maintenant qu’on est capable de builder nos projets sans dépendances binaires sur des SNAPSHOT, on a mis en place le build de nos Pull Request avec GH Pull Request Builder pour Jenkins

Dans la case inconvénient on peut noter :

Allongement du temps de build, même si ce n’est pas totalement vrai, mais avant avec les dépôts séparés on ne reconstruisait pas forcément tous les projets pour valider nos changements
On utilise Maven pour construire nos projets, notre projet multi-modules géant demande un peu plus de gymnastique intellectuelle pour lancer un build. Une fois qu’on a assimilé l’utilisation des options -pl et -am(d) c’est tout de même faisable 😇

Publier son site Maven sur GitHub Pages

Sat, 17 Aug 2013 18:10:00 +0200

Tout fier de son projet hébergé sur GitHub, il existe un mécanisme de publication de site statique, les GitHub Pages. Petit tour de piste pour configurer le déploiement de site Maven sur cet espace.

The Maven way
#

Le maven-site-plugin permet de déployer les sites via différents protocoles configurables avec des providers wagon. Coup de chance il existe une section pour l’utilisation des gh-pages: Deploying your Maven site to GitHub’s gh-pages.
Malheureusement je n’ai pas réussi à le faire fonctionner… Je suis tombé sur ce ticket qui donne des pistes (enfin pas sûr que ça fonctionne au final) mais qui indique surtout qu’il faut utiliser Maven SCM Publish Plugin.
Par contre ce n’est pas intégré à la fonctionalité de reporting de Maven, pas de mvn site-deploy out of the box.
Je ne l’ai pas testé, je me suis plutôt rabattu sur le plugin maven développé par GitHub qui avait l’air de répondre à mes attentes.

Plugin GitHub
#

Dans le repository officiel de GitHub est disponible le Site Plugin.
Un petit peu de configuration :

<plugin>
 <artifactId>maven-site-plugin</artifactId>
 <version>3.3</version>
 <configuration>
	 <skipDeploy>true</skipDeploy>
 </configuration>
</plugin>
<plugin>
 <groupId>com.github.github</groupId>
 <artifactId>site-maven-plugin</artifactId>
 <version>0.8</version>
 <configuration>
	 <message>Creating site for ${project.version}</message>
	 <repositoryOwner>_</repositoryOwner>
 <repositoryName>_</repositoryName>
 <server>github</server>
 </configuration>
 <executions>
	 <execution>
 	 <phase>site-deploy</phase>
 <goals>
 	 <goal>site</goal>
 </goals>
 </execution>
 </executions>
</plugin>

avec
repositoryOwner: nom d’utilisateur,
repositoryName: nom du repository,
server: identifiant du serveur dans settings.xml

<servers>
 <server>
 <id>github</id>
 <username>GitHubLogin</username>
 <password>GitHubPassw0rd</password>
 </server>
</servers>

Et voilà mvn site-deploy génère et publie le site sur vos gh-pages (peut prendre une dizaine de minutes avant qu’il ne soit disponible).

Si vous ne l’avez pas encore fait, pensez à utiliser le skin maven-fluido-skin qui modernise le rendu de votre site !

Git mergetool avec P4Merge sous MacOS

Sat, 09 Mar 2013 12:40:00 +0200

Quelque soit le gestionnaire de sources que l’on utilise, vient toujours le moment où des conflits apparaissent lors des merge. Dans ces cas là, chacun sa technique, personnellement, que ce soit pour l’affichage d’un diff ou un merge, je préfère les outils graphiques. J’ai longtemps utilisé les outils de tortoise sous Windows, mais à force de papillonner entre différents OS, j’ai cherché un outil disponible sur toutes les plateformes. Et je me suis finalement arrêté sur P4Merge…

Malgré un rendez-vous manqué avec Perforce (git-p4), l’outil de merge disponible au sein de la distribution de Perforce est plutôt réussi (une fois que l’on a compris le mécanisme de sélection à l’aide des trois coquillages).

Installation
#

Télécharger une distribution Perforce : http://www.perforce.com/downloads/complete_list
Copier p4merge dans /Applications

Direction /usr/local/bin, créer un script nommé p4merge avec le contenu :

#!/bin/sh

/Applications/p4merge.app/Contents/Resources/launchp4merge "$@"

Rendre le script exécutable : chmod +x p4merge

Configuration de git
#

[merge]
 conflictStyle = diff3
	tool = p4merge
[mergetool]
	keepBackup = false
	keepTemporaries = false
	prompt = false

Utilisation
#

Et voilà, git difftool et git mergetool utiliseront maintenant P4Merge !

git-p4 au secours de Perforce

Sun, 18 Mar 2012 18:10:00 +0200

A la manière d’un git-svn, il est possible d’utiliser git pour se synchroniser avec un dépôt Perforce (ouf). On peut profiter de la souplesse de git en local et continuer de travailler avec ses collègues sur le dépot central Perforce.

Principe de fonctionnement
#

Git-p4 permet de cloner un dépot Perforce dans un repository git.

Le script va parcourir chaque révision des fichiers et peupler un répository git via la commande p4 print. On peut importer la totalité de l’historique, enfin si on a le temps surtout, le premier import peut-être assez long en fonction de la taille du dépot Perforce.

La phase un peu plus compliquée est le report des changements dans Perforce (à cause des spécificités de ce SCM). Il faut pour celà passer par un workspace Perforce différent de l’emplacement du répository git.

Les commits git sont alors reportés par le script dans le workspace Perforce via des git diff/format-patch… | git apply puis p4 submit s’occupe de transférer les changements dans Perforce.

Git-p4 utilise git-notes sur chaque commit pour repérer ceux déjà synchroniser avec Perforce.

Installation
#

git
#

Après l’installation classique des binaires, on ajoute quelques propriétés spécifiques à git-p4 dans le fichier de configuration .gitconfig :

[git-p4]
detectRename=true
detectCopy=true

Celà permettra à git-p4 de détecter les fichiers déplacés lors du submit dans Perforce (le copy ne semble pas utilisé…).

perforce
#

Après l’installation des binaires, exposer la variable d’environnement P4CONFIG.

Par la suite j’utilise un fichier .p4config pour configurer les accès Perforce.

python 2.x
#

git-p4 est écrit en python, installation.

git-p4
#

Télécharger le script Pour windows, créer le fichier git-p4.bat avec le contenu suivant:

@python "%~d0%~p0git-p4" %*

Copier ces deux fichiers dans le répertoire d’installation de git /libexec/git-core/

Vérification de l’installation
#

git --version
p4 help
python --version
git p4 help

Utilisation
#

Structure d’un projet
#

Le dossier git contiendra le repository git, et p4 le workspace Perforce.

Contenu du fichier .p4config :

P4USER=nom d’utilisateur
P4PASSWD=mot de passe
P4CHARSET=encoding du serveur
P4COMMANDLINE=encoding du CLI
P4CLIENT=nom du workspace

Création du client Perforce
#

Dans le dossier p4, utiliser la commande p4 client pour créer un nouveau workspace. Les données du fichier .p4config sont automatiquement utilisées, il suffit donc seulement de renseigner le mapping vers le projet.

Penser à créer l’arborescence complète du mapping côté client avant de tenter votre premier commit.

Import initial du projet
#

Dans le dossier git, utiliser la commande git p4 clone //depot/chemin/projet . (attention au point à la fin de la commande).

Par défaut seule la dernière révision sera importée, pour importer l’historique complet il suffit de suffixer le chemin du dépôt par @all.

Voilà on peut maintenant travailler dans le répository git !

Mise à jour incrémentale
#

Une fois le premier import effectué, git p4 rebase permet de récupérer les dernières changelist depuis Perforce.

Pour ceux qui préfèrent voir les changements distants avant de les intégrer dans les commit locaux git p4 sync puis git rebase p4/master

Report des changements locaux dans Perforce
#

Penser à toujours faire un git p4 rebase avant de soumettre les changements locaux dans Perforce sinon les possibles conflits devront être résolus depuis le workspace Perforce, et c’est quand même plus simple de les gérer dans git. En oubliant l’update avant le submit il est également possible de se retrouver avec des changelists Perforce non importées dans git (pas cool).

git p4 submit permet de reporter les changements sur le serveur Perforce.

Utiliser l’option --auto pour que Perforce ne demande pas de modifier le commentaire des commits. Il utilisera automatiquement ceux de git.

Précautions
#

Comme lorsque l’on travaille uniquement avec git, ne pas réécrire l’historique de changements déjà synchroniser avec Perforce,
Penser à toujours rebaser les modifications Perforce sur les changements locaux de git avant de tenter un submit,
Éviter les merge entre branches locales, de toute façon il faudra rebaser les modifications au final. Celà pourrait amener à régler les mêmes conflits plusieurs fois.

Workflow
#

git p4 clone
Modifier des fichiers
git commit
Modifier des fichiers
git commit
git p4 rebase
git p4 submit

Pour aller plus loin
#

Utiliser le même répository git pour gérer plusieurs branches du dépot Perforce (Pour le moment j’utilise un repository git par branche),
Repasser sur le script maintenu sur le repository git officiel, j’ai eu des problèmes sous windows avec ce dernier il y a quelques mois quand j’ai commencé à utiliser git-p4.

Git on Jean-Christophe Gay

Fusion de dépôts Git

What ?! #

Mise en place #

Avantages #

Publier son site Maven sur GitHub Pages

The Maven way #

Plugin GitHub #

Git mergetool avec P4Merge sous MacOS

Installation #

Configuration de git #

Utilisation #

git-p4 au secours de Perforce

Principe de fonctionnement #

Installation #

git #

perforce #

python 2.x #

git-p4 #

Vérification de l’installation #

Utilisation #

Structure d’un projet #

Création du client Perforce #

Import initial du projet #

Mise à jour incrémentale #

Report des changements locaux dans Perforce #

Précautions #

Workflow #

Pour aller plus loin #

What ?!
#

Mise en place
#

Avantages
#

The Maven way
#

Plugin GitHub
#

Installation
#

Configuration de git
#

Utilisation
#

Principe de fonctionnement
#

Installation
#

git
#

perforce
#

python 2.x
#

git-p4
#

Vérification de l’installation
#

Utilisation
#

Structure d’un projet
#

Création du client Perforce
#

Import initial du projet
#

Mise à jour incrémentale
#

Report des changements locaux dans Perforce
#

Précautions
#

Workflow
#

Pour aller plus loin
#