Dans la page sur Git de base, nous avons vu comment mettre en place une organisation hiérarchique (comme celle de SVN) avec un entrepôt central et des entrepôt qui correspondent à des copies locales. En réalité, comme un entrepôt peut avoir plusieurs entrepôt remote, il est possible de choisir d’autres organisation.

Il est par exemple possible d’utiliser comme remotes un entrepôt Git géré par Redmine et une entrepôt géré par Github. Les push et pull peuvent être fait sur l’un ou l’autre des entrepôts. Cela, permet par exemple de disposer d’un entrepôt distant privé (Redmine) pour le travail au jour le jour et de pousser moins fréquemment les modifications vers l’entrepôt public (GitHub). Cela peut être automatisé à l’aide de scripts appelé automatiquement lors de certains action côté client (cf. Hooks dans http://git-scm.com/book/en/Customizing-Git-Git-Hooks). Cette organisation peut être généralisée de la façon suivante : chaque développeur d’un même projet dispose de son propre entrepôt Git (sur Redmine) qui lui sert pour le développement courant et il ne pousse dans l’entrepôt commun au projet que les groupes de modifications validées.

Si l’on souhaite avoir des entrepôts “synchronisés”, il est possible de réaliser cette opération entre les entrepôts distants. On peut ainsi ajouter la clé publique de Redmine dans les utilisateurs de Github et paramétré le dépôt redmine pour que chaque commit soit poussé vers GitHub. On peut faire de même avec GitHub. Des utilisateurs peuvent donc indifférement travailler en clonant l’un ou l’autre et l’on dispose d’une sauvegarde.

Dans les cas que nous avons vu jusque là chaque développeur qui a le droit de faire des commit peut modifier le projet global. Une solution (parmis d’autres) pour contrôler les dépôts dans un projet est de faire que chaque développeur dispose de son propre entrepôt mais qu’il ne dispose pas du droit de commit sur l’entrepôt commun. C’est le responsable de l’intégration qui réalise des pull sur les entrepôt locaux.