Close

Créer un dépôt

Ce tutoriel donne un aperçu de la procédure à suivre pour configurer un dépôt avec le contrôle de version Git. Il vous explique comment initialiser un dépôt Git pour un projet (nouveau ou existant). Vous trouverez ci-dessous des exemples de workflow pour des dépôts créés en local et clonés à partir de dépôts distants. Ce guide part du principe que vous maîtrisez les bases de l'interface de ligne de commande.

Ce guide couvre les grands points suivants :

  • Initialiser un nouveau dépôt Git
  • Cloner un dépôt Git existant
  • Commiter une version modifiée d'un fichier dans le dépôt
  • Configurer un dépôt Git pour la collaboration à distance
  • Commandes de contrôle de version Git courantes

À l'issue de ce module, vous serez en mesure de créer un dépôt Git, d'utiliser des commandes Git courantes, de commiter un fichier modifié, d'afficher l'historique de votre projet et de configurer une connexion avec un service d'hébergement Git (Bitbucket).


Qu'est-ce qu'un dépôt Git ?


Un dépôt Git est un entrepôt virtuel de votre projet. Il vous permet d'enregistrer les versions de votre code et d'y accéder au besoin.

Initialisation d'un nouveau dépôt : git init


Pour créer un dépôt, utilisez la commande git init. git init est une commande unique que vous utilisez durant la configuration initiale du nouveau dépôt. Lorsque vous exécutez cette commande, un sous-répertoire .git est créé dans votre répertoire de travail actuel. De même, une branche principale est créée.

Contrôle de version d'un projet existant avec un nouveau dépôt Git

Cet exemple part du principe que vous disposez déjà d'un dossier de projet et que vous aimeriez créer un dépôt dans celui-ci. Lancez d'abord cd dans le dossier de projet racine, puis exécutez la commande git init.

branche git
Ressource connexe

branche git

Logo Bitbucket
DÉCOUVRIR LA SOLUTION

Découvrir Git avec Bitbucket Cloud

cd /path/to/your/existing/code 
git init

Lorsque vous pointez git init vers un répertoire de projet existant, l'étape d'initialisation présentée ci-dessus est également exécutée. Elle est toutefois circonscrite à ce répertoire de projet.

git init <project directory>

Pour de plus amples informations sur git init, reportez-vous à la page git init.

Cloner un dépôt existant : git clone


Si un projet est déjà configuré dans un dépôt centralisé, la commande clone est la plus courante pour obtenir un clone de développement local. À l'instar de git init, le clonage est généralement une opération ponctuelle. Lorsqu'un développeur obtient une copie de travail, toutes les opérations de contrôle de version sont gérées par l'intermédiaire de son dépôt local.

git clone <repo url>

git clone permet de créer une copie ou un clone de dépôts distants. Vous transmettez une URL de dépôt à git clone. Git prend en charge quelques protocoles réseau différents et les formats d'URL correspondants. Dans cet exemple, nous utiliserons le protocole SSH de Git. Les URL SSH de Git suivent ce modèle : git@NOM_HOTE:NOM_UTILISATEUR/NOM_DEPOT.git

Exemple d'URL SSH de Git : git@bitbucket.org:rhyolight/javascript-data-store.git où les valeurs de modèle désignent :

  • NOM_HOTE: bitbucket.org
  • USERNAME: rhyolight
  • NOM_DEPOT: javascript-data-store

Cette commande récupère la dernière version des fichiers du dépôt distant sur la branche principale et les ajoute à un nouveau dossier. Le nom du nouveau dossier correspond à celui du dépôt, dans ce cas javascript-data-store. Le dossier contient tout l'historique du dépôt distant ainsi qu'une nouvelle branche principale.

Pour de plus amples informations sur l'utilisation de git clone et les formats d'URL Git pris en charge, reportez-vous à la pqge git clone.

Enregistrer des changements dans le dépôt : git add et git commit


Maintenant que vous avez cloné ou initialisé un dépôt, vous pouvez commiter les changements de version de fichier dans celui-ci. L'exemple suivant part du principe que vous avez configuré un projet dans /path/to/project. Dans cet exemple, les étapes à effectuer sont les suivantes :

  • Redéfinissez les répertoires sur /path/to/project
  • Créez un nouveau fichier CommitTest.txt avec pour contenu ~"contenu test pour le tutoriel Git"~
  • Ajoutez le fichier CommitTest.txt à la zone de staging du dépôt avec la commande git add
  • Créez un nouveau commit ; son message doit décrire le travail effectué dans le commit
cd /path/to/project 
echo "test content for git tutorial" >> CommitTest.txt 
git add CommitTest.txt 
git commit -m "added CommitTest.txt to the repo"

Après avoir exécuté cet exemple, le fichier CommitTest.txt est désormais ajouté à l'historique de votre dépôt, et ce dernier suit les futures mises à jour apportées au fichier.

Cet exemple a introduit deux commandes Git supplémentaires : add et commit. Cet exemple est très restreint, mais les deux commandes sont abordées plus en détail sur les pages git add et git commit. Autre cas d'usage courant de git add : l'option --all. Lorsque vous exécutez git add --all, tous les fichiers modifiés et non trackés du dépôt sont ajoutés, et l'arborescence de travail du dépôt est mise à jour.

Collaboration dépôt à dépôt : git push


Il est essentiel de comprendre que le concept de « copie de travail » de Git est très différent de la copie de travail que vous obtenez en faisant un check-out du code source à partir d'un dépôt SVN. Contrairement à SVN, Git ne fait aucune distinction entre les copies de travail et le dépôt centralisé. Ce sont des dépôts Git à part entière.

Cela rend la collaboration avec Git fondamentalement différente d'avec SVN. Alors que SVN dépend de la relation entre le dépôt centralisé et la copie de travail, le modèle de collaboration de Git repose sur l'interaction de dépôt à dépôt. Au lieu de checker une copie de travail dans le dépôt centralisé de SVN, vous pouvez faire un push ou un pull des commits d'un dépôt à un autre.

Bien entendu, rien ne vous empêche de donner un sens spécial à certains dépôts Git. Par exemple, en désignant simplement un dépôt Git comme le dépôt « centralisé », il est possible de répliquer un workflow centralisé avec Git. Cette opération s'effectue selon des conventions et non par raccordement câblé au logiciel de contrôle de version lui-même.

Comparaison des dépôts bruts et clonés

Si vous avez utilisé git clone dans la section « Initialisation d'un nouveau dépôt » précédente pour configurer votre dépôt local, ce dernier est déjà défini pour la collaboration à distance. git clone configure automatiquement votre dépôt avec une branche remote qui pointe vers l'URL Git à partir de laquelle vous l'avez cloné. Cela signifie qu'une fois les changements apportés à un fichier commités, vous pouvez lancer une commande git push pour pusher ces changements vers le dépôt distant.

Si vous avez utilisé la commande git init pour créer un nouveau dépôt, vous ne disposerez pas de dépôt distant vers lequel pusher vos changements. Lors de l'initialisation d'un nouveau dépôt, un modèle courant consiste à accéder à un service d'hébergement Git comme Bitbucket pour y créer un dépôt. Le service fournit une URL Git que vous pouvez ensuite ajouter à votre dépôt Git local avant de faire un git push vers le dépôt hébergé. Après avoir créé un dépôt distant auprès du service de votre choix, vous devrez mettre à jour votre dépôt local par le biais d'un mappage. Nous aborderons ce processus dans le guide de configuration et d'installation ci-dessous.

Si vous préférez héberger votre propre dépôt distant, vous devrez configurer un dépôt brut. Les commandes git init et git clone prennent toutes deux en charge l'argument --bare. Le cas d'usage le plus courant pour les dépôts bruts consiste à créer un dépôt Git distant centralisé.

Configuration et installation : git config


Une fois le dépôt distant configuré, vous devrez ajouter une URL de dépôt distant à votre commande git config locale et définir une branche upstream pour vos branches locales. La commande git remote vous offre un tel utilitaire.

git remote add <remote_name> <remote_repo_url>

Cette commande mappe le répertoire distant qui se trouve dans <URL_dépôt_distant> vers une réf de votre dépôt local disponible sous <nom_dépôt_distant>. Après avoir mappé le dépôt distant, vous pouvez pusher les branches locales vers celui-ci.

git push -u <remote_name> <local_branch_name>

Cette commande fait un push de la branche du dépôt local sous < local_branch_name > vers le dépôt distant < remote_name >.

Pour plus de détails sur la commande git remote, reportez-vous à la page git remote.

Outre configurer une URL de dépôt local, vous devrez peut-être aussi définir des options de configuration Git globales comme username ou email. La commande git config vous permet de configurer votre installation Git (ou un dépôt individuel) à partir de la ligne de commande. Elle est capable de définir les informations relatives à l'utilisateur, les préférences ou encore le comportement d'un dépôt. Vous trouverez plusieurs options de configuration courantes ci-dessous.

Git enregistre les options de configuration dans trois fichiers distincts, ce qui vous permet de définir l'étendue des options sur des dépôts individuels (local), des utilisateurs (global) ou le système global (système) :

  • Local : /.git/config – paramètres spécifiques du dépôt.
  • Global : /.gitconfig – paramètres spécifiques de l'utilisateur. Les options contenant le flag --global sont stockées à cet endroit.
  • Système : $(prefix)/etc/gitconfig – paramètres à l'échelle du système.

Définissez le nom d'auteur à utiliser pour tous les commits dans le dépôt actuel. Typiquement, vous utiliserez le flag --global afin de définir les options de configuration pour l'utilisateur actuel.

git config --global user.name <name>

Définissez le nom de l'auteur à utiliser pour tous les commits par l'utilisateur courant.

Lorsque vous ajoutez l'option --local ou que vous ne transmettez pas d'option de niveau de configuration, user.name sera défini pour le dépôt local courant.

git config --local user.email <email>

Définissez l'adresse e-mail de l'auteur à utiliser pour tous les commits par l'utilisateur courant.

git config --global alias.<alias-name> <git-command>

Créez un raccourci pour une commande Git. Cet utilitaire très performant permet de créer des raccourcis personnalisés pour des commandes Git fréquemment utilisées. Exemple simpliste :

git config --global alias.ci commit

Cela crée une commande ci que vous pouvez exécuter comme un raccourci de la commande git commit. Pour en savoir plus sur les alias Git, reportez-vous à la page git config.

it config --system core.editor <editor>

Cette commande définit l'éditeur de texte utilisé par des commandes comme git commit pour tous les utilisateurs de la machine actuelle. L'argument devrait être la commande qui lance l'éditeur souhaité (par ex., vi). Cet exemple présente l'option --system. L'option --system définit la configuration de tout le système, c'est-à-dire tous les utilisateurs et les dépôts sur une machine. Pour de plus amples informations sur les niveaux de configuration, consultez la page git config.

git config --global --edit

Ouvrez le fichier de configuration globale dans un éditeur de texte pour le modifier manuellement. Vous trouverez un guide détaillé qui vous explique la procédure à suivre pour configurer un éditeur de texte pour Git sur la page git config.

Discussion

Toutes les options de configuration sont stockées dans des fichiers en texte brut. La commande git config n'est donc qu'une interface de ligne de commande pratique. Généralement, vous devez uniquement configurer une installation Git quand vous commencez à travailler sur une nouvelle machine de développement. Dans la plupart des cas, vous utiliserez le flag --global. Exception importante : lorsque vous écrasez l'adresse e-mail de l'auteur. Vous souhaiterez peut-être définir votre adresse e-mail personnelle pour les dépôts source personnels et ouverts et votre adresse e-mail professionnelle pour les dépôts professionnels.

Git enregistre les options de configuration dans trois dossiers distincts, ce qui vous permet de définir l'étendue des options sur des dépôts individuels, des utilisateurs ou le système global :

  • /.git/config – Paramètres spécifiques du dépôt.
  • ~/.gitconfig – paramètres spécifiques de l'utilisateur. Les options contenant le flag --global sont stockées à cet endroit.
  • $(prefix)/etc/gitconfig – Paramètres à l'échelle du système.

Si les options de ces fichiers entrent en conflit, les paramètres locaux remplacent les paramètres utilisateur (s'appliquent à l'échelle du système). Si vous ouvrez l'un de ces fichiers, vous obtiendrez quelque chose de semblable à ce qui suit :

[user] name = John Smith email = john@example.com [alias] st = status co = checkout br = branch up = rebase ci = commit [core] editor = vim

Vous pouvez modifier manuellement ces valeurs de sorte qu'elles aient le même effet que git config.

Exemple

La première chose que vous devez faire après avoir installé Git est lui indiquer votre nom/e-mail et personnaliser certains des paramètres par défaut. Une configuration initiale type peut ressembler à ceci :

Dites à Git qui vous êtes avec git config

git --global user.name "John Smith" git config --global user.email john@example.com

Sélectionnez votre éditeur de texte préféré

git config --global core.editor vim

Ajoutez des alias de type SVN

git config --global alias.st status 
git config --global alias.co checkout 
git config --global alias.br branch 
git config --global alias.up rebase 
git config --global alias.ci commit

Cette commande génère le fichier ~ /.gitconfig de la section précédente. Pour plus de détails sur la commande git config, reportez-vous à la page git config.

Résumé


Nous y présentons comment créer un dépôt Git à l'aide de deux méthodes : git init et git clone. Ce guide peut être appliqué pour gérer le code source du logiciel ou d'autres contenus qui nécessitent un contrôle de version. git add, git commit, git push et git remote sont également présentées et utilisées dans les grandes lignes.

Lisez notre guide pour déterminer le système de dépôt de code adapté à votre équipe !


Partager cet article
Thème suivant

Lectures recommandées

Ajoutez ces ressources à vos favoris pour en savoir plus sur les types d'équipes DevOps, ou pour les mises à jour continues de DevOps chez Atlassian.

Des personnes qui collaborent à l'aide d'un mur rempli d'outils

Le blog Bitbucket

Illustration DevOps

Parcours de formation DevOps

Démos Des démos avec des partenaires d'Atlassian

Fonctionnement de Bitbucket Cloud avec Atlassian Open DevOps

Inscrivez-vous à notre newsletter DevOps

Thank you for signing up