web-dev-qa-db-fra.com

Comment cloner le dépôt git depuis son zip

J'essaie de cloner un dépôt distant sur github, mais il est grand et ma connexion ne semble pas assez stable, je ne peux donc pas le cloner avec succès.

Mais j'ai téléchargé avec succès le .Zip du référentiel.

Existe-t-il un moyen d’utiliser ce Zip tel qu’il a été créé par le clone git pour pouvoir appuyer, tirer, etc.?

gitgithubzipgit-clone
33
Lesto

Un article connexe ici fournit les informations nécessaires pour récupérer le répertoire .git et simplifier la réponse que umläute a fournie:

  • Saisissez le répertoire .git en clonant un référentiel nu

    $ mkdir repo
$ git clone --bare http://github/user/repo repo

  • Créez le répertoire .git et déplacez les fichiers clonés

    $ mkdir repo/.git
$ mv repo/* repo/.git

  • Décompressez le référentiel

    $ unzip repo.Zip

  • Réinitialiser le référentiel

    $ cd repo
$ git init

  • Vérifiez que vous êtes synchronisé

    $ git pull

  • Réinitialiser le HEAD pour nettoyer le statut

    $ git reset HEAD

  • Voici le journal pour le dépôt ... emplacement du dépôt - http://github.com/udacity/fullstack-nanodegree-vm

    $ git log
commit ebcbda650bc81d7f4856f5314a0689cea5b43086
Merge: 574774b b5b787e
Author: Karl Krueger <[email protected]>
Date:   Tue Apr 7 11:39:54 2015 -0700`

        Merge pull request #3 from pmallory/sharedDirAlert

        Add a login alert to explain how to access Vagrant's shared directory

commit b5b787efdb1ecec0c3c9c7f9c0fd4732f984fcb3
Author: Philip Mallory <[email protected]>
Date:   Mon Apr 6 15:40:32 2015 -0700`

       move the alert into the motd

commit b8012f33c86b0d19fc4c2b972af092e88d00978f
Author: Philip Mallory <[email protected]>
Date:   Mon Apr 6 14:32:01 2015 -0700`

       Add a login alert to explain how to access Vagrant's shared directory

commit 574774ba29ccd661154431d5600240f090440c37
Author: Lorenzo Brown <[email protected]>
Date:   Wed Mar 11 14:08:02 2015 -0700`

       Update pg_config.sh

       Added installs for Auth&Auth

commit 88fc5537b1a0017a1d76af4587a22412473809a4
Author: Lorenzo Brown <[email protected]>
Date:   Wed Mar 4 13:00:25 2015 -0800`

       Update and rename vagrant to vagrant/catalog/README.txt

commit f978cdc14c62b7295d8da1a95452faaa1bd108b8
Author: Lorenzo Brown <[email protected]>
Date:   Wed Feb 4 11:06:03 2015 -0800`

       Update Vagrantfile

       switched to port forwarding on 8080

commit d6a3a26578ef3c6d01d28abca76d817938892c7f
Author: Lorenzo Brown <[email protected]>
Date:   Tue Feb 3 14:52:34 2015 -0800`

       Update Vagrantfile

       Added:

       config.vm.network "forwarded_port", guest: 80, Host: 8080
       config.vm.network "forwarded_port", guest: 5000, Host: 5000

       FSF uses these two ports for lessons 2 & 3 respectively.

commit 752a79e408c7328ef7f1766d1b97bb468ffed90a
Author: Mike Wales <[email protected]>
Date:   Mon Feb 2 11:21:29 2015 -0800`

       Removed .vagrant directory

commit 5af9d19adf9ab19b1d886f6cc78e556f864b42dd
Author: Mike Wales <[email protected]>
Date:   Mon Feb 2 11:16:45 2015 -0800`

       Initial commit.
23
fracjackmac

Si vous avez téléchargé le référentiel (y compris le répertoire .git), c'est assez simple.

  • décompressez le référentiel

    $ unzip repo.Zip

  • configurer une remote dans votre référentiel qui pointe vers l'URI de clone

    $ cd repo
$ git init
$ git remote add Origin https://github.com/user/repo.git

  • resynchroniser les référentiels

    $ git pull

En pratique, il semble que le téléchargement "Zip" de github ne contient pas contienne le répertoire .git;

Le mieux que vous puissiez faire est probablement de créer un clone sur une machine disposant d'un accès stable, puis de compresser le répertoire .git et de le récupérer en quelque sorte ....

11
umläute

Bien que la réponse acceptée fasse l'affaire, cela semble un peu plus simple.

unzip <repo>.Zip
cd <repo>
git init
git add .
git remote add Origin https://github.com/<user>/<repo>.git
git remote update
git checkout master

Assurez-vous simplement de remplacer <user> & <repo> par votre nom d'utilisateur github et votre nom de dépôt;)

5
arctelix

La seule alternative au clonage semblable à Zip consiste à échanger "bundles" , mais je crains que github ne propose pas de création/téléchargement de bundles.

Une archive Zip téléchargeable à partir de github n'est qu'un instantané d'un commit particulier de l'historique de votre référentiel (généralement la pointe d'une branche), et ne contient aucun historique. Cette installation est conçue pour fournir automatiquement les utilisateurs de votre base de code ( pas les développeurs!) avec un moyen de télécharger facilement un instantané du code source du projet. Notez que les simples utilisateurs et, par exemple, les responsables en aval qui conditionnent votre logiciel pour les systèmes d'exploitation, ne clonent généralement pas des historiques entiers, mais travaillent plutôt avec des archives.

En d'autres termes, le téléchargement d'une archive Zip fonctionne comme si vous exécutiez git archive du côté distant, puis transmettez le fichier résultant.

Notez également que les référentiels hébergés sur github (et d'autres fournisseurs d'hébergement Git) sont "nus", c'est-à-dire qu'ils ne contiennent pas le sous-répertoire ".git".

Dans tous les cas, il semble que votre seul moyen de résoudre ce problème consiste à trouver un lien rapide et fiable et à effectuer votre téléchargement initial à l'aide de celui-ci.

Mais notez que les choses changent si vous êtes d'accord pour ne pas avoir l'historique complet. Vous pouvez ensuite utiliser le "clonage superficiel" en passant le paramètre de ligne de commande "--depth" à git clone.

1
kostix

L'initialisation peut ne pas être la solution, selon votre cas d'utilisation. Cela sera particulièrement fastidieux s’il ya un très grand référentiel (le mien était de 16 Go et il était inéluctable de le faire), et en fait il supprimera le refs+objects local qui ne sert à rien si vos archives représentent une archive pour laquelle une télécommande n’existe plus.

Le référentiel doit être copié en deux étapes:

  1. "Fichiers de données" (révision HEAD éventuellement non mise en scène)
  2. Indices et objets à savoir. history + refs + objects: Ceci enregistre votre ligne de base, vos deltas, vos pointeurs de branche et vos balises.

L’objectif est de réduire le nombre d’objets qui doivent être clonés à partir d’une télécommande ou qui ne peuvent pas être recréés à partir d’une télécommande qui n’existe plus. De plus, vous voulez que votre configuration ne soit pas en conflit avec les fichiers de configuration locaux de celui qui a initialement créé le référentiel 

Vous souhaitez conserver la structure du référentiel pour objects et refs, qui n'existent plus dans la télécommande ou que vous ne souhaitez pas copier (par exemple, ils sont de grands actifs d'image). Pour cette raison, vous ne voulez pas initier et tirer, surtout si vous n'avez plus de télécommande.

Au lieu de cela, le référentiel est déjà dans un état acceptable avec les références et les objets intacts. Les seuls problèmes peuvent être si les télécommandes ne sont plus configurées correctement et si votre configuration est mal configurée.

Exécutez git config --local -l pour vérifier que l'identité de la validation n'est pas définie localement dans le référentiel et modifiez les clés qui remplacent vos paramètres globaux d'une manière que vous ne souhaitez pas.

Maintenant qu'il est configuré, traitez le référentiel comme s'il s'agissait du vôtre (car il l'est), git est conçu pour fonctionner de manière distribuée. Ainsi, une fois que vous modifiez une configuration locale, elle n'est en réalité pas différente de celle d'un clonage. La seule chose qui reste à faire est de vous assurer que vos télécommandes sont correctement configurées.

Si vous n'avez pas de télécommande mais souhaitez en créer une, créez-la sur le serveur distant à l'aide de git init --bare, puis ajoutez une télécommande comme d'habitude et appuyez sur Toutes les références git Push --all. Rendre un référentiel nu signifie qu'il acceptera le premier Push sans se plaindre d'une histoire divergente.

Si vous avez un référentiel distant existant, ajoutez-le en tant que distant et extrayez-le. Les branches d’archive peuvent pointer vers la mauvaise URL en fonction de la date à laquelle l’archive a été créée. Si tel est le cas, utilisez git remote pour les affecter à de nouveaux emplacements ou supprimez les URL mortes.

Une fois les télécommandes configurées, récupérez et tirez pour vous mettre à jour. Si une tête est détachée, vérifiez la branche souhaitée. Si l'historique du référentiel archivé a divergé de celui du serveur distant, git générera un conflit de fusion, à résoudre normalement, en stockant les modifications si nécessaire.

0
awiebe