Partagez

Si vous ne disposez pas déjà d'un compte Bitbucket, vous devez en créer un. Si vous ne disposez pas déjà d'un compte Bitbucket, vous devez en créer un. Si vous ne disposez pas déjà d'un compte Bitbucket, vous devez en créer un. L'hébergement est gratuit jusqu'à 5 utilisateurs, de sorte que vous pouvez commencer à explorer les Flux de travail Git immédiatement.

Pour créer le référentiel hébergé, soumettez le formulaire en cliquant sur le bouton Créer un référentiel. Pour créer le référentiel hébergé, soumettez le formulaire en cliquant sur le bouton Créer un référentiel. Pour créer le référentiel hébergé, soumettez le formulaire en cliquant sur le bouton Créer un référentiel. Une fois que votre référentiel est configuré, une page Étapes suivantes décrit quelques commandes utiles pour importer un projet existant. Une fois que votre référentiel est configuré, une page Étapes suivantes décrit quelques commandes utiles pour importer un projet existant. Une fois que votre référentiel est configuré, une page Étapes suivantes décrit quelques commandes utiles pour importer un projet existant. Le reste de cette page vous guide à travers ces instructions pas à pas.

Pour pousser facilement les commits depuis votre référentiel Git local vers le référentiel Bitbucket que vous venez de créer, vous devriez enregistrer l'URL du référentiel Bitbucket dans un distant. Un distant est simplement un raccourci pratique pour une URL. Techniquement, vous pouvez choisir le raccourci de votre choix, mais si le référentiel distant fait office de base de code officielle pour le projet, on le désigne conventionnellement par origin. Techniquement, vous pouvez choisir le raccourci de votre choix, mais si le référentiel distant fait office de base de code officielle pour le projet, on le désigne conventionnellement par origin. Techniquement, vous pouvez choisir le raccourci de votre choix, mais si le référentiel distant fait office de base de code officielle pour le projet, on le désigne conventionnellement par origin. Exécutez ce qui suit dans votre référentiel local Git pour ajouter votre nouveau référentiel Bitbucket en tant qu'origin distante. Exécutez ce qui suit dans votre référentiel local Git pour ajouter votre nouveau référentiel Bitbucket en tant qu'origin distante. Exécutez ce qui suit dans votre référentiel local Git pour ajouter votre nouveau référentiel Bitbucket en tant qu'origin distante.

N'oubliez pas de remplacer ＜username＞ par votre nom d'utilisateur Bitbucket, ＜workspace-id＞ par l'identifiant de votre espace de travail et ＜repo＞ par le nom du dépôt Bitbucket. Vous devriez également pouvoir copier/coller l'URL complète depuis l'interface web Bitbucket.

Après avoir exécuté la commande ci-dessus, vous pouvez utiliser l'origine dans d'autres commandes Git pour référer à votre référentiel Bitbucket. Après avoir exécuté la commande ci-dessus, vous pouvez utiliser l'origine dans d'autres commandes Git pour référer à votre référentiel Bitbucket. Après avoir exécuté la commande ci-dessus, vous pouvez utiliser l'origine dans d'autres commandes Git pour référer à votre référentiel Bitbucket.

Ensuite, vous devez envoyer le contenu de votre dépôt Git local vers votre dépôt Bitbucket. On appelle cela « pusher » ou « faire un push » et cela peut être fait grâce à la commande suivante :

L'option -u demande à Git de suivre les branches en amont. L'option -u demande à Git de suivre les branches en amont. L'option -u demande à Git de suivre les branches en amont. Git peut alors vous dire si l'historique du commit du référentiel distant est devant ou derrière vos historiques locaux. L'option --all pousse toutes les branches locales vers le référentiel distant. L'option -u demande à Git de suivre les branches en amont. L'option -u demande à Git de suivre les branches en amont.

You also need to push your local tags to the Bitbucket repository with the --tags option:

Votre dépôt Bitbucket est maintenant un clone de votre dépôt local. Dans l'interface web Bitbucket, vous devriez pouvoir explorer l'historique des commits de toutes vos branches.

Il ne vous reste plus qu'à partager l'URL de votre dépôt Bitbucket avec les autres développeurs qui ont besoin d'y accéder. L'URL de tout dépôt Git peut être copiée/collée depuis la page d'accueil Bitbucket de ce dernier :

Si votre référentiel est privé, vous aurez besoin d'accorder un accès aux membres de votre équipe dans l'onglet Administration de l'interface web Bitbucket. Si votre référentiel est privé, vous aurez besoin d'accorder un accès aux membres de votre équipe dans l'onglet Administration de l'interface web Bitbucket. Si votre référentiel est privé, vous aurez besoin d'accorder un accès aux membres de votre équipe dans l'onglet Administration de l'interface web Bitbucket. Il est possible de gérer les utilisateurs et les groupes en cliquant sur le lien Access management dans la barre latérale. Il est possible de gérer les utilisateurs et les groupes en cliquant sur le lien Access management dans la barre latérale. Il est possible de gérer les utilisateurs et les groupes en cliquant sur le lien Access management dans la barre latérale.

Vous avez également la possibilité d'utiliser la fonction d'invitation intégrée à Bitbucket pour inviter d'autres développeurs à forker le dépot. Les utilisateurs invités recevront automatiquement un accès à celui-ci, ce qui vous dispense d'avoir à leur accorder des permissions.

Une fois qu'il connaît l'URL de votre dépôt, un autre développeur peut copier le dépôt sur sa machine locale à l'aide de git clone et commencer à travailler sur le projet. Par exemple, après avoir exécuté la commande suivante sur sa machine locale, un autre développeur trouverait un nouveau dépôt Git contenant le projet dans le répertoire nommé ＜repo＞.

Vous devriez maintenant être en mesure de pusher votre projet local vers un dépôt distant. Votre équipe devrait, elle, pouvoir utiliser ce dépôt distant pour cloner le projet sur ses machines locales. Ce sont tous les outils dont vous avez besoin pour commencer à collaborer avec Git. Cependant, votre équipe et vous devrez continuer à faire des commits des changements en utilisant SVN jusqu'à ce que tout le monde soit prêt pour la transition.

Les seuls changements apportés au dépôt Git doivent provenir du dépôt SVN d'origine via le process de synchronisation mentionné dans la page précédente. À toutes fins utiles, cela signifie que tous vos dépôts Git (locaux et distants) sont en lecture seule. Vos développeurs peuvent les tester, et vous pouvez commencer à les intégrer à votre process de build. Vous devez toutefois éviter de faire des commits de changements permanents à l'aide de Git.

Dans cette étape, vous configurez un dépôt Bitbucket pour partager votre dépôt Git converti avec d'autres développeurs. Vous devriez maintenant disposer de tous les outils dont vous avez besoin pour implémenter les workflows Git décrits dans la section Workflows Git. Vous pouvez continuer la synchronisation avec le dépôt SVN et partager les commits Git qui en résultent via Bitbucket pendant que votre équipe de développement se familiarise avec Git. Ensuite, vous pouvez terminer la migration en retirant votre dépôt SVN.