Les deux révisions précédentesRévision précédenteProchaine révision | Révision précédente |
doc:formations:hebergement:service:gitolite [2021/12/14 17:16] – [Configuration initiale] jeremie | doc:formations:hebergement:service:gitolite [2022/08/09 09:03] (Version actuelle) – [Principes] jeremie |
---|
''git'' est le système de versioning de source le plus utilisé et probablement le plus performant à l'heure actuelle. Il repose sur une approche distribuée de "patches" (modifications incrémentales) stockés sous forme arborescente. | ''git'' est le système de versioning de source le plus utilisé et probablement le plus performant à l'heure actuelle. Il repose sur une approche distribuée de "patches" (modifications incrémentales) stockés sous forme arborescente. |
| |
On appelle un "repository" un lieu commun qui permet à un ou plusieurs développeurs de récupérer et pousser des modifications dans des projets git, mais cette notion même de "dépot" est subjective. En effet, ajouter un localement un ou plusieurs "remote", n'est rien d'autre que d'indiquer un ou plusieurs lieu tiers où se trouvent d'autres copies de l'arborescence que l'on a chez soi. Et ''git'' excelle pour comparer, réconcilier et créer diverses versions d'un projet. | Voyez [[doc:formations:git|cette page]] pour une introduction progressive et plus précise à l'usage de git. |
| |
| On appelle un "repository" un lieu commun qui permet à un ou plusieurs développeurs de récupérer et pousser des modifications dans des projets git, mais cette notion même de "dépot" est subjective. En effet, ajouter un ou plusieurs "remote", n'est rien d'autre qu'indiquer un ou plusieurs lieu tiers où se trouvent des *copies* de l'arborescence que l'on a chez soi, qui servent de points de comparaison et d'approvisionnement pour d'autres développeurs. Et précisément, git excelle pour comparer, réconcilier et créer diverses versions d'un projet. |
| |
Sans aller hors-sujet, et dans tous les cas, il est utile d'avoir un "dépot central" qui sert de point d'échange principal pour le code source d'un projet. Cela sert aussi comme sauvegarde lorsqu'il se trouve sur un serveur indépendant du poste client. | Sans aller hors-sujet, et dans tous les cas, il est utile d'avoir un "dépot central" qui sert de point d'échange principal pour le code source d'un projet. Cela sert aussi comme sauvegarde lorsqu'il se trouve sur un serveur indépendant du poste client. |
Dans le cas d'un email mal formé, on peut cependant spécifier l'utilisateur par son nom seulement ("joe" ici, mais ce n'est pas idéal). Explications [[https://stackoverflow.com/questions/13957954/gitolite-usernames-in-authorized-keys-file|ici]] ("l'idée du @suffix est de permettre à l'administrateur d'ajouter facilement plusieurs clés pour un même utilisateur"). | Dans le cas d'un email mal formé, on peut cependant spécifier l'utilisateur par son nom seulement ("joe" ici, mais ce n'est pas idéal). Explications [[https://stackoverflow.com/questions/13957954/gitolite-usernames-in-authorized-keys-file|ici]] ("l'idée du @suffix est de permettre à l'administrateur d'ajouter facilement plusieurs clés pour un même utilisateur"). |
| |
| ==== Configuration coté client de son .ssh/config pour gitolite ==== |
| |
| A propos de SSH, voyez les bénéfices de configurer votre ''$HOME/.ssh/config'' sur [[https://wiki.tecrd.com/doku.php?id=doc:formations:hebergement:serveur:ssh#options_du_cote_client|la page ssh]]. |
====== Usage de git ====== | ====== Usage de git ====== |
| |