| Les deux révisions précédentesRévision précédenteProchaine révision | Révision précédente |
| issue86:command_conquer [2014/12/26 08:53] – d52fr | 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 cet article, je me posais la question de l'intérêt d'un article qui décrirait l'hébergement / la création d'un dépôt hôte git. Il s'avère que .. le voici. Donc, l'article de ce mois va être consacré à la création et l'hébergement de vos propres dépôts git et aussi de débattre 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 les fichiers aller et retour, 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> | 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. |
| 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, ça sera bien sans le commutateur <nowiki>--bare</nowiki>. Quelque soit la solution choisie, vous ne devriez pas rencontrer de problèmes. | |
| |
| **Adding files to the repository | **Adding files to the repository |
| Ajouter des fichiers dans un dépôt | Ajouter des fichiers dans un dépôt |
| |
| Sans se soucier de savoir si vous avez initialisé un répertoire vide ou utilisé un répertoire déjà rempli, rien n'est ajouté au répertoire choisi par défaut. Vous aurez besoin de lancer : | Sans se soucier de savoir si vous avez initialisé le dépôt dans un répertoire vide ou utilisé un répertoire déjà rempli, par défaut rien n'est ajouté au dépôt. Vous aurez besoin de lancer : |
| |
| git add | git add |
| |
| Avant rien n'était ajouté. Un fois que vous l'avez ajouté, vous devrez aussi confirmer (commit) les changements par : | avant d'y ajouter quoi que ce soit. Une fois que vous l'avez ajouté, vous devrez aussi confirmer (commit) les changements par : |
| |
| git commit -m “Message” | git commit -m “Message” |
| Now that the repository is created and contains content, it's time to clone it to a new machine.** | Now that the repository is created and contains content, it's time to clone it to a new machine.** |
| |
| Remplacez « message » par votre vrai message de confirmation. Autre solution, vous pouvez faire les deux actions d'un coup avec : | Remplacez « message » par votre vrai message de confirmation. Autre solution : vous pouvez faire les deux actions d'un coup avec : |
| |
| git commit -a -m “Message” | git commit -a -m “Message” |
| |
| Le commutateur <nowiki>-a</nowiki> indique à git de tout ajouter et confirmer dans le répertoire. Par conséquent, si vous voulez n'ajouter que quelques fichiers, soit vous créez un .gitignore, soit vous ajoutez les fichiers séparément avec la commande git add. | Le commutateur <nowiki>-a</nowiki> indique à git de tout ajouter et confirmer tout ce qui se trouve dans le répertoire. Par conséquent, si vous voulez n'ajouter que quelques fichiers, soit vous créez un .gitignore, soit vous ajoutez les fichiers séparément avec la commande git add. |
| Maintenant que le dépôt est créé et contient du contenu, il est temps de le cloner sur une nouvelle machine. | Maintenant que le dépôt est créé et contient du contenu, il est temps de le cloner sur une nouvelle machine. |
| |
| |
| 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 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é: ~/git-repos/cc-example.git, git-repos/cc-example.git, etc. | • Erronés : ~/git-repos/cc-example.git, git-repos/cc-example.git, etc. |
| |
| Si vous utilisez le port standard, vous pouvez réduire un peu le format en écrivant la commande comme ceci : | Si vous utilisez le port standard, vous pouvez réduire un peu le format en écrivant la commande comme ceci : |
| 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: |
| git push origin master ** | git push origin master ** |
| |
| Une fois que vous avez cloné le dépôt, vous pouvez faire git add, git commit et ensuite (de façon à synchroniser les changements) utilisez git push. Le format de cette commande (comme le mois dernier) est : | Une fois le dépôt cloné, vous pouvez faire git add, git commit et ensuite (de façon à synchroniser les changements) utilisez git push. Le format de cette commande (comme le mois dernier) est : |
| |
| git push <remote-target> <branch> | git push <remote-target> <branch> |
| |
| Typiquement, <remote-target> sera l'origine, et <branch> sera le maître. Aussi, une commande typique pourrait être : | Typiquement, <remote-target> sera l'origine et <branch> sera le maître. Aussi, une commande typique pourrait être : |
| |
| git push origin master | git push origin master |
| This will define a remote target called origin in the repository, and use the URL you supplied. This shouldn't typically be required (at least, in my testing I never needed to define a host like this). You can also use it to define multiple remote targets, in case you have various backup servers – though that could easily end up being very complex.** | This will define a remote target called origin in the repository, and use the URL you supplied. This shouldn't typically be required (at least, in my testing I never needed to define a host like this). You can also use it to define multiple remote targets, in case you have various backup servers – though that could easily end up being very complex.** |
| |
| Si vous rencontrez une erreur (comme l'origine distante n'est pas définie), vous devrez ajouter la cible à votre dépôt. Pour ce faire, changez de répertoire pour être dans votre dépôt et lancez : | Si vous rencontrez une erreur (comme l'origine distante n'étant pas définie), vous devrez ajouter la cible à votre dépôt. Pour ce faire, changez de répertoire pour être dans votre dépôt et lancez : |
| |
| <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 ça 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 une 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 |
| git checkout <branch> | git checkout <branch> |
| |
| Quand vous aurez changé pour la branche dans laquelle vous voulez travailler, agissez de la même manière qu'habituellement (éditer des fichiers, en ajouter et les confirmer). Cependant il y a un gros changement pour l'étape du push : | Quand vous aurez changé pour la branche dans laquelle vous voulez travailler, continuez votre travail comme d'habitude (éditer des fichiers, en ajouter et les confirmer). Cependant il y a un gros changement pour l'étape du push : |
| |
| git push origin <branch> | git push origin <branch> |
| |
| Pour pousser (push) la nouvelle branche vers l'hôte distant « origin », vous avez besoin de vous assurer que vous fournissez le bon nom de branche. Typiquement, les commandes utilisent ici le maître comme valeur par défaut, mais ce n'est juste que si vous mettez à jour la branche maître (c'est-à-dire la branche stable). | Pour pousser (push) la nouvelle branche vers l'hôte distant « origin », vous avez besoin de vous assurer que vous fournissez le bon nom de branche. Typiquement, les commandes utilisent ici maître comme valeur par défaut, mais ce n'est correct que si vous mettez à jour la branche maître (c'est-à-dire la branche stable). |
| |
| **Assuming you've completed development in the development branch, and are ready to merge it back into the stable (master) branch, then you would need to do the following: | **Assuming you've completed development in the development branch, and are ready to merge it back into the stable (master) branch, then you would need to do the following: |
| git merge <branch>** | git merge <branch>** |
| |
| Supposons que vous avez réalisé le développement dans la branche development, et que vous êtes prêt à la fusionner dans la branche stable (le maître), alors vous utiliseriez la commande suivante : | Supposons que vous avez terminé le développement dans la branche development et que vous êtes prêt à la fusionner dans la branche stable (le maître), alors vous utiliseriez la commande suivante : |
| |
| git checkout master | git checkout master |
| |
| Cette commande vous ramène dans la branche maître - quand vous fusionnez, vous avez besoin de vérifier la branche cible. Ensuite fusionnez les branches avec : | Cette commande vous ramène dans la branche maître - quand vous fusionnez, il est nécessaire d'avoir vérifié la branche cible. Ensuite fusionnez les branches avec : |
| |
| git merge <branch> | git merge <branch> |
| **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 classiquement de façon linéaire (c'est-à-dire que la branche stable pointe toujours vers le point le 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 |
| The difference is that the top command is supported in versions of git as of 1.5.0, and the second one is supported only as of 1.7.0.** | The difference is that the top command is supported in versions of git as of 1.5.0, and the second one is supported only as of 1.7.0.** |
| |
| Effacer une branche | Supprimer une branche |
| |
| Localement une vieille branche s'efface aussi simplement que : | Localement une vieille branche s'efface aussi simplement que : |
| git push origin --delete <branch> | git push origin --delete <branch> |
| |
| La différence vient de ce que la commande du haut est supportée dans les versions de git comme la 1.5.0 et que la seconde est supportée uniquement par la 1.7.0. | La différence vient de ce que la commande du haut est supportée dans les versions de git dès la 1.5.0 et que la seconde est supportée uniquement à partir de la 1.7.0. |
| |
| **Renaming a branch | **Renaming 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 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 à la cible distante 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 vide (par exemple, 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 un 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 : |
| |
| mkdir <folder> | mkdir <folder> |
| git fetch origin <branch>:refs/remotes/origin/<branch>** | git fetch origin <branch>:refs/remotes/origin/<branch>** |
| |
| Ou d'une autre façon, simplement git --bare init <folder> | Ou d'une autre façon, lancez simplement git --bare init <folder> |
| |
| <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 est nécessaire de façon à relier le dépôt distant et le nouveau dépôt local que vous venez de créer, qui ne contiendra que la branche que vous voulez. | Ceci est nécessaire pour relier le dépôt distant au nouveau dépôt local que vous venez de créer, qui ne contiendra que la branche que vous voulez. |
| |
| git fetch origin <branch>:refs/remotes/origin/<branch> | git fetch origin <branch>:refs/remotes/origin/<branch> |
| <nowiki>git clone ssh://gituser@git.example.com:21/home/gituser/git-repos/cc-example.git -b <branch></nowiki>** | <nowiki>git clone ssh://gituser@git.example.com:21/home/gituser/git-repos/cc-example.git -b <branch></nowiki>** |
| |
| Il y a quelques points à noter à propos de cette commande : si votre cible distante est quelque chose d'autre qu'origin, modifiez les deux occurrences d'origin dans la commande. De même, remplacez <branch> par le nom de la branche. ne changez pas la partie « /refs/remote/ ». C'est essentiel pour préparer le déchargement de la branche spécifique que voulez depuis le dépôt. | Il y a quelques points à noter à propos de cette commande : si votre cible distante est différente d'origin, modifiez les deux occurrences d'origin dans la commande. De même, remplacez <branch> par le nom de la branche. Ne changez pas la partie « /refs/remote/ ». Ceci est important pour préparer le téléchargement de la branche spécifique que vous voulez à partir du dépôt. |
| |
| git checkout -b <branch> --track origin/<branch> | git checkout -b <branch> --track origin/<branch> |
| |
| Ceci crée maintenant la branche dans votre dépôt local ent ensuite la relie avec la branche de la cible distante - en fait un dépôt ne contenant que cette branche est créé. | Ceci crée maintenant la branche dans votre dépôt local et ensuite la relie à la branche de la cible distante - en fait un dépôt ne contenant que cette branche est créé. |
| |
| Note : Si vous ne pensez pas télécharger toutes les branches existantes, et que vous souhaitez seulement que git point vers une autre branche par défaut (par exemple si vous prévoyez de fusionner des branches plus tard), vous le faire beaucoup plus simplement avec : | Note : Si cela ne vous dérange pas de télécharger toutes les branches existantes et que vous souhaitez seulement que git pointe par défaut vers une autre branche (par exemple si vous prévoyez de fusionner des branches plus tard), vous pouvez le faire beaucoup plus simplement avec : |
| |
| <nowiki>git clone ssh://gituser@git.example.com:21/home/gituser/git-repos/cc-example.git -b <branch></nowiki> | <nowiki>git clone ssh://gituser@git.example.com:21/home/gituser/git-repos/cc-example.git -b <branch></nowiki> |
| Hopefully this has helped explain some of the intricacies of managing git branches and servers. If you have any follow-up questions, or ran into any issues with the examples in the article, feel free to email me at lswest34+fcm@gmail.com. You're also very welcome to email me with requests for articles, or if you want to offer your 2 cents on any of the steps outlined here.** | Hopefully this has helped explain some of the intricacies of managing git branches and servers. If you have any follow-up questions, or ran into any issues with the examples in the article, feel free to email me at lswest34+fcm@gmail.com. You're also very welcome to email me with requests for articles, or if you want to offer your 2 cents on any of the steps outlined here.** |
| |
| Avec cette commande, le dépôt est cloné normalement (avec toutes les branches) et il commute ensuite de la branche par défaut (c'est-à-dire le maître) vers la branche que vous spécifiez (par exemple testing). Ceci aurait généralement ma préférence, par rapport à la série compliquée d'étapes listées plus haut. Probablement, vous avez besoin d'un éventuel accès à quelques unes des autres branches et ça permet une commutation sans peine de l'une à l'autre. | Avec cette commande, le dépôt est cloné normalement (avec toutes ses branches) et il commute ensuite de la branche par défaut (c'est-à-dire le maître) vers la branche que vous spécifiez (par exemple testing). Ceci aurait généralement ma préférence, par rapport à la série compliquée d'étapes listées plus haut. Probablement, vous aurez besoin d'un éventuel accès à quelques-unes des autres branches et ça permet une commutation sans peine de l'une à l'autre. |
| Heureusement, ceci a aidé à expliquer quelques subtilités de gestion des branches et des seveurs git. Si vous avez la moindre question de suivi, ou si vous avez des problèmes en utilisant les exemples de cet articles, n'hésitez pas à m'envoyer un mail à lswest34+fcm@gmail.com. Vous êtes aussi les bienvenus pour m'envoyer des suggestions d'articles par mail, si vous voulez ajouter votre grain de sel sur les étapes décrites ici. | |
| | J'espère que cet article vous a aidé à comprendre quelques subtilités de la gestion des branches et des serveurs git. Si vous avez la moindre question de suivi, ou si vous avez des problèmes en utilisant les exemples de cet article, n'hésitez pas à m'envoyer un mail à lswest34+fcm@gmail.com. Merci de bien vouloir m'envoyer des suggestions d'articles par mail ou si vous voulez ajouter votre grain de sel sur les étapes décrites ici. |
| |
| |
