| Les deux révisions précédentesRévision précédente | |
| issue86:command_conquer [2014/12/26 15:41] – auntiee | issue86:command_conquer [2014/12/27 10:17] (Version actuelle) – andre_domenech |
|---|
| **Last month we covered a series of examples when it came to using Git in combination with Github. Within this article, I asked if there was any interest in an article on hosting/creating your own git repository host. Turns out… there is. As such, we'll be dedicating this month's article to creating and hosting your own git repositories, as well as discussing how to manage specific branches (such as: cloning a single branch from a repository, merging branches, creating a new one, etc.).** | **Last month we covered a series of examples when it came to using Git in combination with Github. Within this article, I asked if there was any interest in an article on hosting/creating your own git repository host. Turns out… there is. As such, we'll be dedicating this month's article to creating and hosting your own git repositories, as well as discussing how to manage specific branches (such as: cloning a single branch from a repository, merging branches, creating a new one, etc.).** |
| |
| Le mois dernier, nous avons passé en revue une série d'exemples sur l'utilisation de Git en combinaison avec Github. Dans l'article, je demandais si des gens seraient intéressés par un article qui décrirait l'hébergement/la création d'un dépôt hôte git. Il s'avère que .. oui. Donc, cet article va être consacré à la création et l'hébergement de vos propres dépôts git; il va aussi parler de comment gérer les branches spécifiques (comme : cloner une seule branche à partir d'un dépôt, fusionner des branches, en créer une nouvelle, etc.). | Le mois dernier, nous avons passé en revue une série d'exemples sur l'utilisation de Git en combinaison avec Github. Dans l'article, je demandais si des gens seraient intéressés par un article qui décrirait l'hébergement/la création d'un dépôt hôte git. Il s'avère que... oui. Donc, cet article va être consacré à la création et l'hébergement de vos propres dépôts git ; il va aussi parler de comment gérer les branches spécifiques (comme cloner une seule branche à partir d'un dépôt, fusionner des branches, en créer une nouvelle, etc.). |
| |
| **Git Server | **Git Server |
| Serveur Git | Serveur Git |
| |
| La façon la plus facile de configurer un serveur git serait de simplement installer git sur le serveur et de configurer un SSH. Comme c'est la méthode que j'ai utilisée, ce sera notre centre d'intérêt de ce mois et je vais supposer que vous avez déjà un serveur SSH en état de marche sur la machine distante. Si vous préférez le tester sur une machine locale et copier simplement des dossiers de l'un à l'autre et vice versa, vous pouvez utiliser les chemins de fichiers normaux plutôt que le format SSH. | La façon la plus facile de configurer un serveur git serait, simplement, d'installer git sur le serveur et de configurer un SSH. Comme c'est la méthode que j'ai utilisée, ce sera notre centre d'intérêt de ce mois et je vais supposer que vous avez déjà un serveur SSH en état de marche sur la machine distante. Si vous préférez le tester sur une machine locale et copier simplement des dossiers de l'un à l'autre et vice versa, vous pouvez utiliser les chemins de fichiers normaux plutôt que le format SSH. |
| |
| **Creating a new repository | **Creating a new repository |
| git --bare init <folder>.git | git --bare init <folder>.git |
| |
| Si le répertoire n'existe pas, il sera créé. Pour une bonne organisation du serveur, je vous recommanderais de placer tous les dépôts git dans un sous-répertoire de votre répertoire home personnel. Quelque chose comme /home/gituser/git-repos/. Pour ce qui est de la commande elle-même : <nowiki>--bare</nowiki> indique à git d'initialiser le dépôt sans répertoire .git séparé. Il semble que l'usage est d'utiliser un dépôt vide pour les dépôts partagés (c'est-à-dire ceux pour lesquels vous acceptez que les gens clonent/chargent/déchargent/récupèrent). Si vous créez ce dépôt sur une machine locale en ne prévoyant qu'un accès occasionnel à ce dépôt depuis une autre machine, il se peut que ce soit bien sans le commutateur <nowiki>--bare</nowiki>. Quelle que soit la solution choisie, vous ne devriez pas rencontrer de problèmes. | Si le répertoire n'existe pas, il sera créé. Pour une bonne organisation du serveur, je vous recommanderais de placer tous les dépôts git dans un sous-répertoire de votre répertoire home personnel. Quelque chose comme /home/gituser/git-repos/. Pour ce qui est de la commande elle-même : <nowiki>--bare</nowiki> indique à git d'initialiser le dépôt sans répertoire .git séparé. Il semble que l'usage est d'utiliser un dépôt vide pour les dépôts partagés (c'est-à-dire ceux pour lesquels vous acceptez que les gens clonent/chargent/déchargent/récupèrent). Si vous créez ce dépôt sur une machine locale en ne prévoyant qu'un accès occasionnel à ce dépôt depuis une autre machine, il se peut que ce soit bien sans le commutateur <nowiki>--bare</nowiki>. Quelle que soit la solution choisie, vous ne devriez pas rencontrer de problème. |
| |
| **Adding files to the repository | **Adding files to the repository |
| |
| Hypothèses : | Hypothèses : |
| * Vous utilisez le port normal ssh (21) | * Vous utilisez le port normal ssh (21). |
| * Votre identifiant est gituser | * Votre identifiant est gituser. |
| * Le domaine du serveur est git.example.com | * Le domaine du serveur est git.example.com. |
| * Le chemin est /home/gituser/git-repos | * Le chemin est /home/gituser/git-repos. |
| * Le dépôt lui-même s'appelle cc-example.git | * Le dépôt lui-même s'appelle cc-example.git. |
| |
| A partir de ces hypothèses, la commande de clonage de git devrait ressembler à ceci : | A partir de ces hypothèses, la commande de clonage de git devrait ressembler à ceci : |
| <nowiki>git clone ssh://gituser@git.example.com:21/home/gituser/git-repos/cc-example.git</nowiki> | <nowiki>git clone ssh://gituser@git.example.com:21/home/gituser/git-repos/cc-example.git</nowiki> |
| |
| Si vous créez votre dépôt sans .git à la fin (ou si vous le créez dans un ancien répertoire), vous aurez juste à adapter le chemin pour le reflèter (ainsi ça donnerait « cc-example » à la fin de notre exemple). En supposant que vous n'avez pas paramétré SSH avec des fichiers de clés, vous aurez un pop-up pour vérifier votre empreinte ou pour entrer votre mot de passe. | Si vous créez votre dépôt sans .git à la fin (ou si vous le créez dans un ancien répertoire), vous aurez juste à adapter le chemin pour le refléter (ainsi ça donnerait « cc-example » à la fin de notre exemple). En supposant que vous n'avez pas paramétré SSH avec des fichiers de clés, vous aurez un pop-up pour vérifier votre empreinte ou pour entrer votre mot de passe. |
| |
| **The SSH format for git is as follows: | **The SSH format for git is as follows: |
| |
| Remplacez <user> par votre vrai identifiant SSH, <host> par la bonne valeur IP/domaine/nom d'hôte, [port] par le port que vous utilisez (vous pouvez faire l'impasse si vous utilisez le port standard) et <absolute path> doit toujours être absolu - ce qui veut dire qu'il commence toujours par le répertoire racine du système de fichiers. | Remplacez <user> par votre vrai identifiant SSH, <host> par la bonne valeur IP/domaine/nom d'hôte, [port] par le port que vous utilisez (vous pouvez faire l'impasse si vous utilisez le port standard) et <absolute path> doit toujours être absolu - ce qui veut dire qu'il commence toujours par le répertoire racine du système de fichiers. |
| • Correct : /home/gituser/git-repos/cc-example.git | • Correct : /home/gituser/git-repos/cc-example.git. |
| • Erronés : ~/git-repos/cc-example.git, git-repos/cc-example.git, etc. | • Erronés : ~/git-repos/cc-example.git, git-repos/cc-example.git, etc. |
| |
| git clone <user>@<host>:<absolute path> | git clone <user>@<host>:<absolute path> |
| |
| Cependant, ça ne demande pas beaucoup plus d'effort d'utiliser le format complet, qui peut aussi aider à réduire le nombre d'erreurs si vous travaillez avec des valeurs de ports non-standard. | Cependant, ça ne demande pas beaucoup plus d'effort d'utiliser le format complet, qui peut aussi aider à réduire le nombre d'erreurs si vous travaillez avec des valeurs de ports non standards. |
| |
| **Once you've cloned the repository, you can git add, git commit, and then (in order to synchronize the changes) use git push. The format of this command (like last month) is: | **Once you've cloned the repository, you can git add, git commit, and then (in order to synchronize the changes) use git push. The format of this command (like last month) is: |
| <nowiki>git remote add origin ssh://gituser@git.example.com:21/home/gituser/git-repos/cc-example.git</nowiki> | <nowiki>git remote add origin ssh://gituser@git.example.com:21/home/gituser/git-repos/cc-example.git</nowiki> |
| |
| Ceci définira une cible distante appelée origin dans le dépôt et utilisera l'URL que vous avez fournie. Ca ne devrait pas être exigé (du moins dans mes tests je n'ai jamais eu besoin de définir l'hôte de cette façon). Vous pouvez aussi l'utiliser pour définir de multiples cibles distantes, au cas où vous auriez plusieurs serveurs de sauvegarde - bien que cela puisse facilement devenir très compliqué. | Ceci définira une cible distante appelée origin dans le dépôt et utilisera l'URL que vous avez fournie. Ca ne devrait pas être exigé (du moins dans mes tests je n'ai jamais eu besoin de définir l'hôte de cette façon). Vous pouvez aussi l'utiliser pour définir de multiples cibles distantes, au cas où vous auriez plusieurs serveurs de sauvegarde, bien que cela puisse facilement devenir très compliqué. |
| |
| **Branches | **Branches |
| Branches | Branches |
| |
| Le lecteur qui m'a contacté souhaitait aussi quelques informations sur la création, la fusion et clonage de branches particulières dans un dépôt. Toute personne qui envisage du développement sérieux avec git voudra apprendre ce que sont les branches, de façon à conserver l'image instantanée d'un développement séparée de la version stable. | Le lecteur qui m'a contacté souhaitait aussi quelques informations sur la création, la fusion et clonage de branches particulières dans un dépôt. Toute personne qui envisage du développement sérieux avec git voudra apprendre ce que sont les branches, de façon à conserver l'image instantanée d'un développement séparé de la version stable. |
| |
| Créer une nouvelle branche | Créer une nouvelle branche |
| **Make sure you enter the actual branch name. This type of merge uses the typical git approach to conflicts – if it can't automatically resolve the conflict, it will instead mark the changes in the file within the repository, and you need to resolve it manually, then re-add and commit the changes. See last month's article for more detail. If you typically develop in a linear way (i.e. the stable branch always points to an older point in the timeline, and the development branch is more recent), it shouldn't be an issue. However, if you have concurrent branches (i.e. you develop onwards normally after the most recent stable release, but also branch off into a mobile development from the same snapshot), it may cause some conflicts when merging.** | **Make sure you enter the actual branch name. This type of merge uses the typical git approach to conflicts – if it can't automatically resolve the conflict, it will instead mark the changes in the file within the repository, and you need to resolve it manually, then re-add and commit the changes. See last month's article for more detail. If you typically develop in a linear way (i.e. the stable branch always points to an older point in the timeline, and the development branch is more recent), it shouldn't be an issue. However, if you have concurrent branches (i.e. you develop onwards normally after the most recent stable release, but also branch off into a mobile development from the same snapshot), it may cause some conflicts when merging.** |
| |
| Assurez-vous de saisir le nom de branche correct. Ce type de fusion utilise l'approche des conflits typique de git - si le conflit ne peut pas être résolu automatiquement, les écarts sont marqués dans le fichier dans le dépôt et vous devez l'analyser manuellement, puis ajouter à nouveau et confirmer les changements. Voir l'article du mois dernier pour plus de détails. Si vous développez normalement de façon linéaire (c'est-à-dire que la branche stable pointe toujours vers un point un plus ancien de l'échelle de temps et que la branche de développement est plus récente), il ne devrait pas y avoir de problème. Cependant, si vous avez des branches concurrentes ( disons que vous développez normalement à partir de la version publiée stable la plus récente, mais qu'à partir de la même image vous avez un branche pour un développement pour le mobile), il peut y avoir quelques conflits au moment de la fusion. | Assurez-vous de saisir le nom de branche correct. Ce type de fusion utilise l'approche des conflits typique de git - si le conflit ne peut pas être résolu automatiquement, les écarts sont marqués dans le fichier dans le dépôt et vous devez l'analyser manuellement, puis ajouter à nouveau et confirmer les changements. Voir l'article du mois dernier pour plus de détails. Si vous développez normalement de façon linéaire (c'est-à-dire que la branche stable pointe toujours vers un point un plus ancien de l'échelle de temps et que la branche de développement est plus récente), il ne devrait pas y avoir de problème. Cependant, si vous avez des branches concurrentes ( disons que vous développez normalement à partir de la version publiée stable la plus récente, mais qu'à partir de la même image vous avez une branche pour un développement pour le mobile), il peut y avoir quelques conflits au moment de la fusion. |
| |
| **Deleting a branch | **Deleting a branch |
| Renommer une branche locale avant de la pousser vers le serveur distant | Renommer une branche locale avant de la pousser vers le serveur distant |
| |
| Disons, par exemple, que vous avez une branche appelée testing sur votre copie du dépôt. Problème : quelqu'un vous a coupé l'herbe sous les pieds et a créé une branche nommé testing avec plusieurs changements par rapport à la votre. Vous pouvez bien sûr renommer localement votre branche puis la pousser. Autrement, au moment de pousser la branche vers la cible distante, indiquez-lui comment la renommer par la commande : | Disons, par exemple, que vous avez une branche appelée testing sur votre copie du dépôt. Problème : quelqu'un vous a coupé l'herbe sous le pied et a créé une branche nommée testing avec plusieurs changements par rapport à la vôtre. Vous pouvez bien sûr renommer localement votre branche, puis la pousser. Autrement, au moment de pousser la branche vers la cible distante, indiquez-lui comment la renommer par la commande : |
| |
| git push origin <local>:<remote> | git push origin <local>:<remote> |
| git --bare init** | git --bare init** |
| |
| Notre dépôt testing va être pris et téléversé sur le serveur, avec le nom de branche mobile. Ceci aide peut-être à comprendre la commande de suppression dans git 1.5.0 : en fait, vous poussez un dépôt « null » (c-à-d, un qui n'existe pas) vers la branche distante, ce qui l'efface. | Notre dépôt testing va être pris et téléversé sur le serveur, avec le nom de branche mobile. Ceci aide peut-être à comprendre la commande de suppression dans git 1.5.0 : en fait, vous poussez un dépôt « null » (c'est-à-dire un qui n'existe pas) vers la branche distante, ce qui l'efface. |
| |
| Vérifier un branche spécifique | Vérifier une branche spécifique |
| |
| C'est la dernière question du mail que j'ai reçu. J'ai supposé qu'il voulait dire cloner une seule branche et ignorer tout le reste. C'est une tâche un peu plus compliquée que je vais décrire ci-dessous : | C'est la dernière question du mail que j'ai reçu. J'ai supposé qu'il voulait dire cloner une seule branche et ignorer tout le reste. C'est une tâche un peu plus compliquée que je vais décrire ci-dessous : |
