Réponses:
Je pense que vous créez un référentiel nu sur le côté distant git init --bare, ajoutez le côté distant comme tracker push / pull pour votre référentiel local ( git remote add origin URL), puis localement, vous dites simplement git push origin master. Désormais, tout autre référentiel peut à pullpartir du référentiel distant.
git push origin masteréchec avec l'erreur "référentiel introuvable", essayez git update-server-infodu côté distant, où vous l'avez faitgit init --bare
git update-server-infomais j'obtiens l'erreur fatal: Unable to look up Volumes (port 9418) (nodename nor servname provided, or not known)
Afin de configurer initialement un serveur Git, vous devez exporter un référentiel existant dans un nouveau référentiel nu - un référentiel qui ne contient pas de répertoire de travail. C'est généralement simple à faire. Afin de cloner votre référentiel pour créer un nouveau référentiel nu, vous exécutez la commande clone avec l' --bareoption. Par convention, les répertoires du référentiel nu se terminent .gitcomme suit:
$ git clone --bare my_project my_project.git
Initialized empty Git repository in /opt/projects/my_project.git/
Cette commande prend le référentiel Git seul, sans répertoire de travail, et crée un répertoire spécialement pour lui seul.
Maintenant que vous avez une copie nue de votre référentiel, il vous suffit de la mettre sur un serveur et de configurer vos protocoles. Disons que vous avez configuré un serveur appelé git.example.comauquel vous avez accès SSH et que vous souhaitez stocker tous vos référentiels Git dans le /opt/gitrépertoire. Vous pouvez configurer votre nouveau référentiel en copiant votre référentiel nu sur:
$ scp -r my_project.git user@git.example.com:/opt/git
À ce stade, les autres utilisateurs qui ont un accès SSH au même serveur qui a un accès en lecture au /opt/gitrépertoire peuvent cloner votre référentiel en exécutant
$ git clone user@git.example.com:/opt/git/my_project.git
Si un utilisateur SSH se connecte à un serveur et a un accès en écriture au /opt/git/my_project.gitrépertoire, il aura également automatiquement un accès push. Git ajoutera automatiquement les autorisations d'écriture de groupe à un référentiel correctement si vous exécutez la commande git init avec l' --sharedoption.
$ ssh user@git.example.com
$ cd /opt/git/my_project.git
$ git init --bare --shared
Il est très facile de prendre un référentiel Git, de créer une version nue et de la placer sur un serveur auquel vous et vos collaborateurs avez accès SSH. Vous êtes maintenant prêt à collaborer sur le même projet.
scpsolution fonctionne mieux dans la pratique que l'OMI init --bare. Cela ressemble toujours à un hack laid, mais d'abord cloner localement, puis copier sur le serveur ... J'aimerais que git ait une commande pour le faire en une seule fois.
--sharedfonctionné pour moi. Je me demande ce qui se passe si vous utilisez git init --sharedsans en faire un --bare...
scpcela à une télécommande fonctionne mieux si la télécommande ne prend pas en charge git init --bare(comme ce fut le cas pour moi avec git 1.5.5, 2008). Je pense que cela devrait fonctionner même si la télécommande n'a aucun git.
Une note pour les personnes qui ont créé la copie locale sur Windows et qui souhaitent créer un référentiel distant correspondant sur un système de ligne Unix, où les fichiers texte obtiennent des terminaisons LF sur d'autres clones par des développeurs sur des systèmes de type Unix, mais des terminaisons CRLF sur Windows.
Si vous avez créé votre référentiel Windows avant de configurer la traduction de fin de ligne, vous avez un problème. Le paramètre par défaut de Git n'est pas de traduction, donc votre ensemble de travail utilise CRLF mais votre référentiel (c'est-à-dire les données stockées sous .git) a également enregistré les fichiers en CRLF.
Lorsque vous poussez vers la télécommande, les fichiers enregistrés sont copiés tels quels, aucune traduction de fin de ligne ne se produit. (La traduction de fin de ligne se produit lorsque les fichiers sont validés dans un référentiel, pas lorsque les référentiels sont poussés). Vous vous retrouvez avec CRLF dans votre référentiel de type Unix, ce qui n'est pas ce que vous voulez.
Pour obtenir LF dans le référentiel distant, vous devez d'abord vous assurer que LF se trouve dans le référentiel local, en normalisant à nouveau votre référentiel Windows . Cela n'aura aucun effet visible sur votre ensemble de travail Windows, qui a toujours des terminaisons CRLF, cependant lorsque vous poussez vers la télécommande, la télécommande obtiendra LF correctement.
Je ne sais pas s'il existe un moyen facile de dire quelles fins de ligne vous avez dans votre référentiel Windows - je suppose que vous pouvez le tester en définissant core.autocrlf = false puis en clonant (si le dépôt a des fins LF, le clone aura LF aussi).
Il existe une différence intéressante entre les deux solutions populaires ci-dessus:
Si vous créez le référentiel nu comme ceci:
cd / outside_of_any_repo mkdir my_remote.git cd my_remote.git git init --bare
puis
cd /your_path/original_repo
git remote add origin /outside_of_any_repo/my_remote.git
git push --set-upstream origin master
Ensuite, git configure la configuration dans 'original_repo' avec cette relation:
original_repo origin --> /outside_of_any_repo/my_remote.git/
avec ce dernier comme télécommande en amont. Et la télécommande en amont n'a pas d'autres télécommandes dans sa configuration.
Cependant, si vous le faites dans l'autre sens:
(à partir du répertoire original_repo) cd .. git clone --bare original_repo /outside_of_any_repo/my_remote.git
puis 'my_remote.git' se termine avec sa configuration ayant 'origin' pointant vers 'original_repo' en tant que distant, avec un remote.origin.url équivalant au chemin du répertoire local, ce qui pourrait ne pas être approprié s'il doit être déplacé à un serveur.
Bien que cette référence «distante» soit facile à supprimer plus tard si elle n'est pas appropriée, «original_repo» doit toujours être configuré pour pointer vers «my_remote.git» en tant que télécommande en amont (ou vers où qu'elle aille) à partager). Donc, techniquement, vous pouvez arriver au même résultat avec quelques étapes supplémentaires avec l'approche # 2. Mais le n ° 1 semble une approche plus directe pour créer un «référentiel partagé central nu» provenant d'un local, approprié pour passer à un serveur, avec moins d'étapes impliquées. Je pense que cela dépend du rôle que vous voulez que le dépôt à distance joue. (Et oui, cela est en conflit avec la documentation ici .)
Attention: j'ai appris ce qui précède (au moment de la rédaction de ce document au début du mois d'août 2019) en effectuant un test sur mon système local avec un véritable référentiel, puis en effectuant une comparaison fichier par fichier entre les résultats. Mais! J'apprends toujours, donc il pourrait y avoir un moyen plus correct. Mais mes tests m'ont aidé à conclure que # 1 est ma méthode actuellement préférée.
Un référentiel distant est généralement un référentiel nu - un référentiel Git qui n'a pas de répertoire de travail. Étant donné que le référentiel n'est utilisé que comme point de collaboration, il n'y a aucune raison de faire extraire un instantané sur le disque; ce sont juste les données Git. Dans les termes les plus simples, un référentiel nu est le contenu du répertoire .git de votre projet et rien d'autre.
Vous pouvez créer un référentiel bare git avec le code suivant:
$ git clone --bare /path/to/project project.git
Une option pour avoir un référentiel git distant utilise le protocole SSH:
Un protocole de transport commun pour Git lorsque l'auto-hébergement se fait via SSH. C'est parce que l'accès SSH aux serveurs est déjà configuré dans la plupart des endroits - et si ce n'est pas le cas, c'est facile à faire. SSH est également un protocole réseau authentifié et, parce qu'il est omniprésent, il est généralement facile à configurer et à utiliser.
Pour cloner un référentiel Git sur SSH, vous pouvez spécifier une
ssh://URL comme celle-ci:$ git clone ssh://[user@]server/project.gitOu vous pouvez utiliser la syntaxe de type scp plus courte pour le protocole SSH:
$ git clone [user@]server:project.gitDans les deux cas ci-dessus, si vous ne spécifiez pas le nom d'utilisateur facultatif, Git suppose que l'utilisateur sous lequel vous êtes actuellement connecté est.
Les avantages
Les avantages d'utiliser SSH sont nombreux. Tout d'abord, SSH est relativement facile à configurer - les démons SSH sont courants, de nombreux administrateurs réseau ont de l'expérience avec eux et de nombreuses distributions de système d'exploitation sont configurées avec eux ou disposent d'outils pour les gérer. Ensuite, l'accès via SSH est sécurisé - tous les transferts de données sont cryptés et authentifiés. Enfin, comme les protocoles HTTPS, Git et Local, SSH est efficace, rendant les données aussi compactes que possible avant de les transférer.
Les inconvénients
L'aspect négatif de SSH est qu'il ne prend pas en charge l'accès anonyme à votre référentiel Git. Si vous utilisez SSH, les gens doivent avoir un accès SSH à votre machine, même en lecture seule, ce qui ne rend pas SSH propice aux projets open source pour lesquels les gens pourraient simplement vouloir cloner votre référentiel pour l'examiner. Si vous l'utilisez uniquement au sein de votre réseau d'entreprise, SSH peut être le seul protocole dont vous avez besoin. Si vous souhaitez autoriser un accès anonyme en lecture seule à vos projets et que vous souhaitez également utiliser SSH, vous devrez configurer SSH pour que vous puissiez le pousser, mais autre chose pour les autres.
Pour plus d'informations, consultez la référence: Git sur le serveur - Les protocoles
Vous devez créer un répertoire sur un serveur distant. Utilisez ensuite la commande "git init" pour le définir comme référentiel. Cela devrait être fait pour chaque nouveau projet que vous avez (chaque nouveau dossier)
En supposant que vous avez déjà configuré et utilisé git en utilisant les clés ssh, j'ai écrit un petit script Python qui, lorsqu'il est exécuté à partir d'un répertoire de travail, configurera une télécommande et initialisera le répertoire en tant que dépôt git. Bien sûr, vous devrez modifier le script (une seule fois) pour lui indiquer le serveur et le chemin d'accès racine pour tous les référentiels.
Vérifiez ici - https://github.com/skbobade/ocgi
Normalement, vous pouvez configurer un dépôt git en utilisant simplement la initcommande
git init
Dans votre cas, il existe déjà un repo sur une télécommande disponible. Selon la façon dont vous accédez à votre référentiel distant (avec un nom d'utilisateur dans l'URL ou une clé ssh qui gère la vérification), utilisez simplement la clonecommande:
git clone git@[my.url.com]:[git-repo-name].git
Il existe également d'autres façons de cloner le dépôt. De cette façon, vous l'appelez si vous avez une configuration de clé ssh sur votre machine qui vérifie en tirant votre référentiel. Il existe d'autres combinaisons de l'URL si vous souhaitez inclure votre mot de passe et votre nom d'utilisateur à l'intérieur pour vous connecter à votre référentiel distant.