Comment puis-je cloner le dépôt git avec une révision spécifique, quelque chose comme je le fais habituellement dans Mercurial:
hg clone -r 3 /path/to/repository
Comment puis-je cloner le dépôt git avec une révision spécifique, quelque chose comme je le fais habituellement dans Mercurial:
hg clone -r 3 /path/to/repository
Réponses:
MISE À JOUR 2 Depuis Git 2.5.0, la fonctionnalité décrite ci-dessous peut être activée côté serveur avec une variable de configuration uploadpack.allowReachableSHA1InWant
, ici la demande de fonctionnalité GitHub et le commit GitHub activant cette fonctionnalité . Notez que certains serveurs Git activent cette option par défaut, par exemple Bitbucket Server l'a activée depuis la version 5.5+ . Voir cette réponse sur Stackexchange pour un exemple de comment activer l'option de configuration.
UPDATE 1 Pour les versions de Git, 1.7 < v < 2.5
utilisez git clone et git reset, comme décrit dans la réponse de Vaibhav Bajpai
Si vous ne souhaitez pas récupérer le référentiel complet, vous ne devriez probablement pas utiliser clone
. Vous pouvez toujours utiliser fetch pour choisir la branche que vous souhaitez récupérer. Je ne suis pas un expert en hg donc je ne connais pas les détails -r
mais en git vous pouvez faire quelque chose comme ça.
# make a new blank repository in the current directory
git init
# add a remote
git remote add origin url://to/source/repository
# fetch a commit (or branch or tag) of interest
# Note: the full history up to this commit will be retrieved unless
# you limit it with '--depth=...' or '--shallow-since=...'
git fetch origin <sha1-of-commit-of-interest>
# reset this repository's master branch to the commit of interest
git reset --hard FETCH_HEAD
git fetch origin <sha1>
fonctionne; il semble que vous ayez besoin de passer une référence nommée telle qu'une balise ou un nom de branche. Voir kerneltrap.org/mailarchive/git/2009/1/13/4707444
git fetch origin <SHA1>
pour passer à n'importe quelle révision que je voulais après avoir récupéré le maître de la télécommande et fait l' reset --hard
instanciation réelle de la branche localement. Je n'ai pas pu récupérer directement les révisions individuelles. Avec git 1.7, git fetch origin <SHA1>
n'a pas fonctionné, comme indiqué par @artur; vous devez utiliser git checkout <SHA1>
suivi d'un reset --hard
.
$ git clone $URL
$ cd $PROJECT_NAME
$ git reset --hard $SHA1
Pour revenir à nouveau au commit le plus récent
$ git pull
--depth
ce qui est très important pour les grands dépôts. Cette solution nécessite de retirer tous les objets, puis de réinitialiser une révision antérieure. Cela prend beaucoup de temps et gaspille de la bande passante réseau.
Le clonage d'un référentiel git, à juste titre, clone l'intégralité du référentiel: il n'y a pas moyen de sélectionner une seule révision à cloner. Cependant, une fois que vous avez effectué git clone
, vous pouvez extraire une révision spécifique en faisant checkout <rev>
.
git clone
saisit l'ensemble du référentiel. Une fois que vous l'avez, vous pouvez alors extraire une révision spécifique.
git clone --single-branch ...
Pour cloner une seule validation spécifique sur une branche ou une balise particulière, utilisez:
git clone --depth=1 --branch NAME https://github.com/your/repo.git
Malheureusement, NAME
ne peut être que le nom de la branche ou le nom de la balise (pas de validation SHA).
Omettez le --depth
drapeau pour télécharger l'historique complet, puis vérifiez cette branche ou cette balise:
git clone --branch NAME https://github.com/your/repo.git
Cela fonctionne avec la version récente de git (je l'ai fait avec la version 2.18.0
).
Si vous voulez dire que vous voulez tout récupérer du début à un point particulier, la réponse de Charles Bailey est parfaite. Si vous voulez faire l'inverse et récupérer un sous-ensemble de l'historique remontant à la date actuelle, vous pouvez utiliser git clone --depth [N]
où N est le nombre de tours de l'historique que vous souhaitez. Toutefois:
--profondeur
Créez un clone superficiel avec un historique tronqué au nombre de révisions spécifié. Un référentiel superficiel a un certain nombre de limitations (vous ne pouvez pas le cloner ou le récupérer, ni le pousser ni le pénétrer), mais il est adéquat si vous n'êtes intéressé que par l'histoire récente d'un grand projet avec une longue histoire et que vous souhaitez envoyer des correctifs sous forme de correctifs.
Juste pour résumer les choses (git v. 1.7.2.1):
git clone
où vous voulez le repo (obtient tout à ce jour - je sais, pas ce que l'on veut, nous y arrivons) git checkout <sha1 rev>
du régime que vous voulezgit reset --hard
git checkout -b master
master
et y bascule.
git reset --hard
? Les documents pour cela disent "Réinitialise l'index et l'arborescence de travail. Toutes les modifications apportées aux fichiers suivis dans l'arborescence de travail depuis <commit> [qui par défaut est HEAD, qui est maintenant <sha1 rev>
] sont ignorées." Mais à ce stade, nous n'avons apporté aucun changement depuis le clonage, alors quel est le but? Tronque-t-il la branche actuelle à <sha1 rev>
?
TL; DR - Créez simplement une balise dans le référentiel source par rapport à la validation que vous souhaitez cloner et utilisez la balise dans la commande fetch. Vous pouvez supprimer la balise du référentiel d'origine plus tard pour nettoyer.
Eh bien, c'est 2014 et il semble que la réponse acceptée par Charles Bailey de 2010 soit bel et bien dépassée à l'heure actuelle et la plupart (toutes?) Des autres réponses impliquent le clonage, que beaucoup de gens espèrent éviter.
La solution suivante atteint ce que l'OP et bien d'autres recherchent, ce qui est un moyen de créer une copie d'un référentiel, y compris l'historique, mais uniquement jusqu'à un certain commit.
Voici les commandes que j'ai utilisées avec git version 2.1.2 pour cloner un dépôt local (c'est-à-dire un référentiel dans un autre répertoire) jusqu'à un certain point:
# in the source repository, create a tag against the commit you want to check out
git tag -m "Temporary tag" tmptag <sha1>
# create a new directory and change into that directory
cd somewhere_else;mkdir newdir;cd newdir
# ...and create a new repository
git init
# add the source repository as a remote (this can be a URL or a directory)
git remote add origin /path/to/original/repo
# fetch the tag, which will include the entire repo and history up to that point
git fetch origin refs/tags/tmptag
# reset the head of the repository
git reset --hard FETCH_HEAD
# you can now change back to the original repository and remove the temporary tag
cd original_repo
git tag -d tmptag
Espérons que cette solution fonctionne encore quelques années! :-)
Vous pouvez utiliser simplement git checkout <commit hash>
dans cette séquence
bash
git clone [URLTORepository]
git checkout [commithash]
le hachage de validation ressemble à ceci "45ef55ac20ce2389c9180658fdba35f4a663d204"
L'utilisation de 2 des réponses ci-dessus ( Comment cloner le référentiel git avec une révision / un ensemble de modifications spécifique? Et Comment cloner un référentiel git avec une révision / un ensemble de modifications spécifique? ) M'a aidé à trouver une définition. Si vous voulez cloner jusqu'à un point, alors ce point doit être une balise / branche et pas simplement un SHA ou le FETCH_HEAD se confond. Après le git fetch set, si vous utilisez un nom de branche ou de tag, vous obtenez une réponse, si vous utilisez simplement un SHA-1, vous n'obtenez pas de réponse.
Voici ce que j'ai fait: - créer un clone de travail complet du repo complet, à partir de l'origine réelle
cd <path to create repo>
git clone git@<our gitlab server>:ui-developers/ui.git
Ensuite, créez une branche locale, au point qui est intéressant
git checkout 2050c8829c67f04b0db81e6247bb589c950afb14
git checkout -b origin_point
Ensuite, créez mon nouveau référentiel vierge, avec ma copie locale comme origine
cd <path to create repo>
mkdir reduced-repo
cd reduced-repo
git init
git remote add local_copy <path to create repo>/ui
git fetch local_copy origin_point
À ce stade, j'ai obtenu cette réponse. Je le note parce que si vous utilisez un SHA-1 à la place de la branche ci-dessus, rien ne se passe, donc la réponse signifie que cela a fonctionné
/ var / www / html / ui-hacking $ git fetch local_copy origin_point à distance: comptage d'objets: 45493, terminé. à distance: compression des objets: 100% (15928/15928), fait. à distance: Total 45493 (delta 27508), réutilisé 45387 (delta 27463) Réception d'objets: 100% (45493/45493), 53,64 Mio | 50,59 Mio / s, fait. Résolution des deltas: 100% (27508/27508), fait. Depuis / var / www / html / ui * branche origin_point -> FETCH_HEAD * [nouvelle branche] point_origine -> point d'origine / origine
Maintenant, dans mon cas, je devais ensuite remettre cela sur gitlab, comme un nouveau repo, donc je l'ai fait
git remote add origin git@<our gitlab server>:ui-developers/new-ui.git
Ce qui signifiait que je pouvais reconstruire mon référentiel à partir du point d'origine en utilisant git --git-dir=../ui/.git format-patch -k -1 --stdout <sha1> | git am -3 -k
pour sélectionner à distance puis utiliser git push origin
pour télécharger le lot dans sa nouvelle maison.
J'espère que cela aide quelqu'un
git fetch local_copy origin_point
diffère-t-on des JamesG git fetch origin refs/tags/tmptag
?
git fetch local_copy origin_point
vous laisser dans un état avec un reduced-repo
répertoire vide , contenant uniquement un .git
. Il manque quelque chose à ces instructions ...
Ma version était une combinaison de réponses acceptées et les plus votées. Mais c'est un peu différent, parce que tout le monde utilise SHA1 mais personne ne vous dit comment l'obtenir
$ git init
$ git remote add <remote_url>
$ git fetch --all
vous pouvez maintenant voir toutes les branches et les commits
$ git branch -a
$ git log remotes/origin/master <-- or any other branch
Enfin, vous connaissez SHA1 du commit souhaité
git reset --hard <sha1>
J'utilise cet extrait avec GNU make pour fermer toute balise de révision, branche ou hachage
il a été testé sur git version 2.17.1
${dir}:
mkdir -p ${@D}
git clone --recursive --depth 1 --branch ${revison} ${url} ${@} \
|| git clone --recursive --branch ${revison} ${url} ${@} \
|| git clone ${url} ${@}
cd ${@} && git reset --hard ${revison}
ls $@
git clone https://github.com/ORGANIZATION/repository.git
(cloner le référentiel)
cd repository (navigate to the repository)
git fetch origin 2600f4f928773d79164964137d514b85400b09b2
git checkout FETCH_HEAD
# clone special tag/branch without history
git clone --branch=<tag/branch> --depth=1 <repository>
# clone special revision with minimal histories
git clone --branch <branch> <repository> --shallow-since=yyyy-MM-ddTHH:mm:ss # get the commit time
cd <dir>
git reset --hard <revision>
vous ne pouvez pas obtenir une révision sans historique si elle n'est pas définie uploadpack.allowReachableSHA1InWant=true
côté serveur, tandis que vous pouvez créer une balise pour celle-ci et cloner la balise spéciale à la place.
git clone -o <sha1-of-the-commit> <repository-url> <local-dir-name>
git
utilise le mot origin
au lieu de populairement connurevision
Voici un extrait du manuel $ git help clone
--origin <name>, -o <name>
Instead of using the remote name origin to keep track of the upstream repository, use <name>.
--depth=1
n'est pas mentionné dans la réponse, alors pourquoi diriez-vous que cette réponse a fonctionné si vous avez ajouté plus de choses qui ne sont pas mentionnées ici? Je suis heureux que cela ait fonctionné pour vous, mais cette réponse est trompeuse et ne répond pas à la question même en partie. D'où les downvotes.
git clone <url> <local_dir_name>
, essayez-le par vous-même. La seule différence est que la télécommande (représentée en utilisant git remote
) sera appelée une séquence cryptique sha1 au lieu du nom "origine" qui est habituel. En d'autres termes, les éléments <sha1-of-the-commit>
mentionnés dans cette réponse n'ont aucune incidence sur les révisions extraites du serveur ou sur la branche à extraire.
git clone -o 896066ee1cf4d653057dac4e952f49c96ad16fa7 https://github.com/torvalds/linux.git linux --depth=1
. Cela me donne une révision 8a28d674
et non pas 896066ee
comme vous et cette réponse le prétend.
git clone -b 10.1 https://github.com/MariaDB/server.git --depth=1 mariadb-server-src