| Prochaine révision | Révision précédente |
| git:gitavance [2014/04/11 10:38] – créée Emmanuel Bruno | git:gitavance [2023/09/20 18:52] (Version actuelle) – modification externe 127.0.0.1 |
|---|
| </WRAP> | </WRAP> |
| ====== Organisation des entrepôts ====== | ====== Organisation des entrepôts ====== |
| Dans la page sur [[git:gitminimal|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. | Dans la page sur [[git:gitminimal|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. |
| |
| ===== Plusieurs remotes pour un clone ===== | ===== Plusieurs remotes pour un clone ===== |
| overlap=false; | overlap=false; |
| } | } |
| </graphviz>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. | </graphviz>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. |
| |
| ===== Propagation entre remotes ===== | ===== Propagation entre remotes ===== |
| edge [fontsize=11]; | edge [fontsize=11]; |
| |
| "Autre entrepôt \"d'origine\" (GitHub)" -> "Entrepôt d'origine (Redmine)" [ label = "push" ]; | "Entrepôt d'origine" -> "Autre entrepôt \"d'origine\"" [ label = "push" ]; |
| "Entrepôt d'origine (Redmine)" -> "Autre entrepôt \"d'origine\" (GitHub)" [ label = "push" ]; | |
| |
| "Clone 1" -> "Entrepôt d'origine (Redmine)" [ label = "pull" ]; | "Clone 1" -> "Entrepôt d'origine" [ label = "pull" ]; |
| "Clone 1" -> "Entrepôt d'origine (Redmine)" [ label = "push" ]; | "Clone 1" -> "Entrepôt d'origine" [ label = "push" ]; |
| |
| |
| "Clone 2" -> "Autre entrepôt \"d'origine\" (GitHub)" [ label = "push" ]; | "Clone 2" -> "Autre entrepôt \"d'origine\"" [ label = "push" ]; |
| "Clone 2" -> "Autre entrepôt \"d'origine\" (GitHub)" [ label = "pull" ]; | "Clone 2" -> "Autre entrepôt \"d'origine\"" [ label = "pull" ]; |
| |
| "Clone 1" -> "Clone 1" [ label = "commit" ]; | "Clone 1" -> "Clone 1" [ label = "commit" ]; |
| overlap=false; | overlap=false; |
| } | } |
| </graphviz>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. | </graphviz>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). |
| |
| ===== Validation "manuelle" des commit ===== | ===== Validation "manuelle" des commit ===== |
| overlap=false; | overlap=false; |
| } | } |
| </graphviz>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. | </graphviz>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 |
| | ---- |