Full Circle Magazine FR

Outils pour utilisateurs

Outils du site

Piste : • an_intro_to_sqlite • python • an_intro_to_sqlite_suite
issue86:command_conquer

Différences

Ci-dessous, les différences entre deux révisions de la page.

Lien vers cette vue comparative

Les deux révisions précédentesRévision précédente
Prochaine révision		Révision précédente
issue86:command_conquer [2014/12/23 15:38] – d52frissue86:command_conquer [2014/12/27 10:17] (Version actuelle) – andre_domenech
Ligne 1: Ligne 1:
 **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 pour une 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
Ligne 9: Ligne 9:
 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
Ligne 18: Ligne 18:
 Créer un nouveau dépôt Créer un nouveau dépôt
  
-Partant de l'hypothèse d'un dépôt distant, vous avez besoin d'un accès SSH à votre machine (en utilisant le même identifiant que celui que vous prévoyez pour Git). Quand c'est fait, vous êtes prêt à créer le dépôt comme suit :+Partant de l'hypothèse d'un dépôt distant, vous avez besoin d'un accès SSH à la machine (en utilisant le même identifiant que celui que vous prévoyez pour git). Quand c'est fait, vous êtes prêt à créer le dépôt comme suit :
  
 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 depuis une autre machine, ça sera bien sans le commutateur <nowiki>--bare</nowiki>. Queqlue soit la solution choisie, vous ne devriez pas rencontrer de problèmes.+
  
 **Adding files to the repository **Adding files to the repository
Ligne 37: Ligne 36:
 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”
Ligne 52: Ligne 51:
 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 deux choses à la fois 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 vous ajouter 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.
  
Ligne 77: Ligne 76:
  
 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èse, 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éer 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. présumant 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:
- ssh://<user>@<host>:[port]<absolute path>+<nowiki> ssh://<user>@<host>:[port]<absolute path></nowiki>
  
 Replace <user> with the actual SSH username, <host> with the actual IP/Domain/Hostname, [port] with the port you're using (you can leave this out if you're using the standard port), and the <absolute path> must always be absolute – meaning it starts from the root filesystem directory: Replace <user> with the actual SSH username, <host> with the actual IP/Domain/Hostname, [port] with the port you're using (you can leave this out if you're using the standard port), and the <absolute path> must always be absolute – meaning it starts from the root filesystem directory:
Ligne 101: Ligne 100:
  
 However, it doesn't take much more effort to use the complete format, which may also help reduce errors when working with non-standard port values.** However, it doesn't take much more effort to use the complete format, which may also help reduce errors when working with non-standard port values.**
 +
 +Le format SSH pour git est le suivant :
 +<nowiki> ssh://<user>@<host>:[port]<absolute path></nowiki>
 +
 +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.
 +• 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 :
 +
 +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 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:
Ligne 107: Ligne 119:
  
 Typically, the <remote-target> will be origin, and the <branch> will be master. So, a typical command could be: Typically, the <remote-target> will be origin, and the <branch> will be master. So, a typical command could be:
 +
 +git push origin master **
 +
 +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>
 +
 +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
  
-If you run into an error (such as the remote origin not being defined), you'll need to add the target to your repository. To do this, change directory to the repository, and then run:+**If you run into an error (such as the remote origin not being defined), you'll need to add the target to your repository. To do this, change directory to the repository, and then run:
  
-git remote add origin ssh://gituser@git.example.com:21/home/gituser/git-repos/cc-example.git+<nowiki>git remote add origin ssh://gituser@git.example.com:21/home/gituser/git-repos/cc-example.git</nowiki>
  
 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'é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>
 +
 +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
Ligne 130: Ligne 156:
 git branch <branch> git branch <branch>
 git checkout <branch>** git checkout <branch>**
 +
 +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é de la version stable.
 +
 +Créer une nouvelle branche
 +
 +Assurez-vous que le répertoire courant est celui de votre dépôt puis tapez la commande suivante :
 +
 +git checkout -b <branch>
 +
 +Une nouvelle branche sera créée, appelée <branch>. Techniquement, ce n'est que la contraction des deux commandes suivantes :
 +
 +git branch <branch>
 +git checkout <branch>
  
 **As you can see, the short-hand is a lot less repetition. These two steps are also required only if you're creating branches – changing between branches is as simple as writing: **As you can see, the short-hand is a lot less repetition. These two steps are also required only if you're creating branches – changing between branches is as simple as writing:
Ligne 140: Ligne 181:
  
 To push your new branch to the remote host “origin”, you need to make sure you supply the correct branch name. Typically commands use master as a default value here, but that's true only if you're updating the master (i.e. stable) branch.** To push your new branch to the remote host “origin”, you need to make sure you supply the correct branch name. Typically commands use master as a default value here, but that's true only if you're updating the master (i.e. stable) branch.**
 +
 +Comme vous pouvez le voir, la commande raccourcie évite les répétitions. Ces deux étapes ne sont requises que si vous créez des branches - passer d'une branche à l'autre est aussi simple que :
 +
 +git checkout <branch>
 +
 +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>
 +
 +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:
Ligne 148: Ligne 199:
  
 git merge <branch>** git merge <branch>**
 +
 +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
 +
 +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>
  
 **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 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
Ligne 161: Ligne 222:
 git push origin :<branch> git push origin :<branch>
  
-git push origin --delete <branch>**+git push origin --delete <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.**
  
-Renaming a branch+Supprimer une branche 
 + 
 +Localement une vieille branche s'efface aussi simplement que : 
 + 
 +git branch -D <branch> 
 + 
 +Cependant, si vous voulez aussi l'effacer sur l'hôte distant, vous devrez faire l'une des commandes suivantes : 
 + 
 +git push origin :<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 dès la 1.5.0 et que la seconde est supportée uniquement à partir de la 1.7.0. 
 + 
 +**Renaming a branch
  
 If you want to rename a branch locally (i.e. from development to dev): If you want to rename a branch locally (i.e. from development to dev):
Ligne 176: Ligne 251:
  
 Also, if you want to rename the current branch, you can omit the <old> part of the command, i.e. git branch -m dev.** Also, if you want to rename the current branch, you can omit the <old> part of the command, i.e. git branch -m dev.**
 +
 +Renommer une branche
 +
 +Si vous voulez renommer une branche localement (par exemple de development à dev) :
 +
 +git branch -m <old> <new>
 +
 +Ainsi, pour notre exemple :
 +
 +git branch -m development dev
 +
 +Si vous voulez renommer la branche courante, vous pouvez omettre <old> dans la commande, par exemple git branch -m dev.
  
 **Renaming a local branch when pushing it to the remote server **Renaming a local branch when pushing it to the remote server
Ligne 185: Ligne 272:
  
 git push origin testing:mobile** git push origin testing:mobile**
 +
 +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 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>
 +
 +Ce qui donne dans notre exemple :
 +
 +git push origin testing:mobile
  
 **This will take our local testing repository and upload it to the server, while renaming that branch mobile. This may also help people to understand the deletion command in git 1.5.0: you're essentially pushing a NULL repository (i.e. one that doesn't exist) to the remote branch, which deletes it. **This will take our local testing repository and upload it to the server, while renaming that branch mobile. This may also help people to understand the deletion command in git 1.5.0: you're essentially pushing a NULL repository (i.e. one that doesn't exist) to the remote branch, which deletes it.
Ligne 196: Ligne 293:
  
 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'est-à-dire un qui n'existe pas) vers la branche distante, ce qui l'efface.
 +
 +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 :
 +
 +mkdir <folder>
 +
 +cd <folder>
 +
 +git --bare init
  
 **Alternatively, just run git --bare init <folder> **Alternatively, just run git --bare init <folder>
  
-git remote add origin ssh://gituser@git.example.com:21/home/gituser/git-repos/cc-example.git+<nowiki>git remote add origin ssh://gituser@git.example.com:21/home/gituser/git-repos/cc-example.git</nowiki>
  
 This is required in order to link the remote repository with the new local repository you just created, that will end up containing only the branch you want. This is required in order to link the remote repository with the new local repository you just created, that will end up containing only the branch you want.
  
 git fetch origin <branch>:refs/remotes/origin/<branch>** git fetch origin <branch>:refs/remotes/origin/<branch>**
 +
 +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>
 +
 +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>
  
 **There are a few things to note about this command: If your remote target is something other than origin, change both occurrences of origin in the command. Also, replace <branch> with the name of the branch. Do not change the part that reads “/refs/remotes/”. This essentially prepares the download of the specific branch you want from the repository. **There are a few things to note about this command: If your remote target is something other than origin, change both occurrences of origin in the command. Also, replace <branch> with the name of the branch. Do not change the part that reads “/refs/remotes/”. This essentially prepares the download of the specific branch you want from the repository.
Ligne 213: Ligne 330:
 Note: If you don't mind downloading all the existing branches, and simply want git to default to a different branch (i.e. if you plan to merge branches later), you can do it much easier with: Note: If you don't mind downloading all the existing branches, and simply want git to default to a different branch (i.e. if you plan to merge branches later), you can do it much easier with:
  
-git clone ssh://gituser@git.example.com:21/home/gituser/git-repos/cc-example.git -b <branch>**+<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 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> 
 + 
 +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 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>
  
 **This clones the repository as normal (including all branches), and then switches the default branch (i.e. master) to the branch you specify (i.e. testing). This would generally be my preference, as opposed to the complicated series of steps listed above. Most likely you'll eventually need access to at least some of the other branches, and this makes it relatively painless to switch between them. **This clones the repository as normal (including all branches), and then switches the default branch (i.e. master) to the branch you specify (i.e. testing). This would generally be my preference, as opposed to the complicated series of steps listed above. Most likely you'll eventually need access to at least some of the other branches, and this makes it relatively painless to switch between them.
  
 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 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.
 +
 +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.
 +
 +
 +
 +
 +
issue86/command_conquer.1419345533.txt.gz · Dernière modification : 2014/12/23 15:38 de d52fr