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ôts qui correspondent à des copies locales. En réalité, comme un entrepôt peut avoir plusieurs entrepôts remote, il est possible de choisir d’autres organisations.

Il est par exemple possible d’utiliser comme remote un entrepôt Git géré par Redmine et de pousser automatiquement les modifications vers un entrepôt géré par Github. 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és automatiquement lors de certaines actions 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 moins fréquemment et dont la validation est plus poussée.

Il est aussi possible de travailler sur des entrepôts “synchronisés”. Le cas simple est celui où l’un des entrepôts pousse les modification vers un autre. On dispose d’une (ou de plusieurs) sauvegardes. En cas de défaillance de l’entrepôt d’origine, il suffit de travailler (push/pull/clone) sur l’un des miroirs.

Pour Redmine/GitHub : Dans Redmine dans les paramètres du dépôt l’onglet “Miroirs du dépôt” donne une clé ssh à ajouter par exemple aux “Deploy keys” dans les paramètres d’un entrepôt GitHub. Il suffit ensuite d’ajouter dans les paramètres du dépôt Redmine un miroir complet et de lui donner l’adresse de l’entrepôt GitHub. A partir de là, les modifications sur l’entrepôt Redmine sont propagées automatiquement vers GitHub. Par contre, il n’est pas possible de faire un push directement depuis GitHub. Il faut mettre en place un pull externe qui pourra être déclenché par un webhook (GitHub peut accéder à une URL donnée à chaque modification).

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 l’intégration d’un projet tout en favorisant le travail collaboratif 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. Cette approche est particulièrement adaptée aux projets opensource : pour participer il suffit de cloner l’entrepôt d’origine et quand les modifications apportées sont suffisament intéressante de demander au mainteneur du projet d’origine de faire un pull (pull request).

—- dataentry page —- type : Howto technologie_tags : Git theme_tags : VCS