git-clone - En ligne dans le Cloud

PROGRAMME:

Nom

git-clone - Clone un référentiel dans un nouveau répertoire

SYNOPSIS

jet cloner [--modèle= ]
[-l] [-s] [--no-hardlinks] [-q] [-n] [--bare] [--mirror]
[-o ] [-b ] [-u ] [--référence ]
[--dissocier] [--separer-git-dir ]
[--profondeur ] [--[pas-]branche unique]
[--récursif | --recurse-submodules] [--]
[ ]

DESCRIPTION

Clone un référentiel dans un répertoire nouvellement créé, crée des branches de suivi à distance pour
chaque branche dans le référentiel cloné (visible à l'aide de git branch -r), et crée et vérifie
une branche initiale qui est dérivée de la branche actuellement active du référentiel cloné.

Après le clonage, un simple git fetch sans arguments mettra à jour tout le suivi à distance
branches, et un git pull sans arguments fusionnera en plus la branche maître distante
dans la branche principale actuelle, le cas échéant (cela est faux lorsque "--single-branch" est donné ;
voir ci-dessous).

Cette configuration par défaut est obtenue en créant des références aux têtes de branche distantes
sous refs/remotes/origin et en initialisant remote.origin.url et remote.origin.fetch
variables de configuration.

OPTIONS

--local, -l
Lorsque le référentiel à partir duquel cloner se trouve sur une machine locale, cet indicateur contourne le
mécanisme de transport "Gitware" et clone le référentiel en faisant une copie de HEAD et
tout sous les répertoires objects et refs. Les fichiers sous le répertoire .git/objects/
sont liés en dur pour économiser de l'espace lorsque cela est possible.

Si le référentiel est spécifié en tant que chemin local (par exemple, /chemin/vers/dépôt), c'est le
par défaut, et --local est essentiellement un no-op. Si le référentiel est spécifié en tant qu'URL,
alors ce drapeau est ignoré (et nous n'utilisons jamais les optimisations locales). En précisant
--no-local remplacera la valeur par défaut lorsque /path/to/repo est donné, en utilisant le
Git transporte à la place.

--pas de liens physiques
Forcer le processus de clonage à partir d'un référentiel sur un système de fichiers local pour copier les fichiers
sous le répertoire .git/objects au lieu d'utiliser des liens physiques. Cela peut être souhaitable si
vous essayez de faire une sauvegarde de votre référentiel.

--partagé, -s
Lorsque le référentiel à cloner se trouve sur la machine locale, au lieu d'utiliser des liens physiques,
configurer automatiquement .git/objects/info/alternates pour partager les objets avec la source
dépôt. Le référentiel résultant démarre sans aucun objet propre.

REMARQUE: il s'agit d'une opération potentiellement dangereuse ; faire ne sauraient l'utiliser à moins que vous ne compreniez ce que
Cela fait. Si vous clonez votre référentiel à l'aide de cette option, puis supprimez les branches (ou
utiliser toute autre commande Git qui rend tout commit existant non référencé) dans la source
référentiel, certains objets peuvent devenir non référencés (ou suspendus). Ces objets peuvent être
supprimé par les opérations Git normales (telles que git commit) qui appellent automatiquement git gc
--auto. (Voir git-gc(1).) Si ces objets sont supprimés et ont été référencés par le
référentiel cloné, le référentiel cloné deviendra corrompu.

Notez que l'exécution de git repack sans l'option -l dans un référentiel cloné avec -s
copier les objets du référentiel source dans un pack du référentiel cloné, en supprimant
les économies d'espace disque de clone -s. Cependant, il est sûr d'exécuter git gc, qui utilise le
-l option par défaut.

Si vous voulez casser la dépendance d'un dépôt cloné avec -s sur sa source
référentiel, vous pouvez simplement exécuter git repack -a pour copier tous les objets de la source
référentiel dans un pack dans le référentiel cloné.

--référence
Si le référentiel de référence se trouve sur la machine locale, configurez automatiquement
.git/objects/info/alternates pour obtenir des objets du référentiel de référence. À l'aide d'un
référentiel déjà existant comme alternative nécessitera moins d'objets à copier
du référentiel en cours de clonage, ce qui réduit les coûts de réseau et de stockage local.

REMARQUE: voir la NOTE pour l'option --shared, ainsi que l'option --dissociate.

--dissocier
Emprunter les objets des référentiels de référence spécifiés avec les options --reference
uniquement pour réduire le transfert réseau et arrêter de leur emprunter une fois qu'un clone a été créé par
faire les copies locales nécessaires des objets empruntés. Cette option peut également être utilisée lorsque
clonage local à partir d'un référentiel qui emprunte déjà des objets à un autre
référentiel - le nouveau référentiel empruntera des objets du même référentiel, et cela
L'option peut être utilisée pour arrêter l'emprunt.

--silencieux, -q
Fonctionne tranquillement. La progression n'est pas signalée au flux d'erreurs standard. Ce drapeau est
également passé à la commande 'rsync' lorsqu'elle est donnée.

--verbeux, -v
Exécutez verbeux. N'affecte pas le rapport de l'état d'avancement à l'erreur standard
ruisseau.

--le progrès
L'état d'avancement est signalé par défaut sur le flux d'erreurs standard lorsqu'il est
attaché à un terminal, sauf si -q est spécifié. Ce drapeau force le statut de progression même
si le flux d'erreur standard n'est pas dirigé vers un terminal.

--pas de paiement, -n
Aucune vérification de HEAD n'est effectuée une fois le clonage terminé.

--nu
Faites une nu Dépôt Git. C'est-à-dire qu'au lieu de créer et en plaçant le
dossiers administratifs dans /.git, faites le lui-même le $GIT_DIR.
Cela implique évidemment le -n car il n'y a nulle part où vérifier l'arbre de travail.
De plus, les têtes de branche à distance sont copiées directement dans la branche locale correspondante
têtes, sans les mapper sur refs/remotes/origin/. Lorsque cette option est utilisée, ni
les branches de suivi à distance ni les variables de configuration associées ne sont créées.

--miroiter
Configurez un miroir du référentiel source. Cela implique --bare. Par rapport à --bare,
--mirror mappe non seulement les branches locales de la source vers les branches locales de la cible,
il mappe toutes les références (y compris les branches de suivi à distance, les notes, etc.) et met en place un
refspec configuration telle que toutes ces références sont écrasées par une mise à jour à distance git
dans le référentiel cible.

--origine , -o
Au lieu d'utiliser l'origine du nom distant pour garder une trace du référentiel en amont, utilisez
.

--branche , -b
Au lieu de pointer le HEAD nouvellement créé vers la branche pointée par le cloné
HEAD du référentiel, pointez sur branche à la place. Dans un référentiel non nu, c'est
la branche qui sera extraite. --branch peut également prendre des balises et détache le
HEAD à ce commit dans le référentiel résultant.

--upload-pack , -u
Lorsqu'il est donné et que le référentiel à partir duquel cloner est accessible via ssh, cela spécifie un
chemin autre que celui par défaut pour la commande exécutée à l'autre extrémité.

--modèle=
Spécifiez le répertoire à partir duquel les modèles seront utilisés ; (Voir le "RÉPERTOIRE DES MODÈLES"
l'article de git-init(1).)

--config = , -c =
Définissez une variable de configuration dans le référentiel nouvellement créé ; cela prend effet
immédiatement après l'initialisation du référentiel, mais avant que l'historique distant ne soit
récupérés ou des fichiers extraits. La clé est dans le même format que prévu par git-
config(1) (par exemple, core.eol=true). Si plusieurs valeurs sont données pour la même clé, chaque
valeur sera écrite dans le fichier de configuration. Cela permet, par exemple, d'ajouter en toute sécurité
fetch refspecs supplémentaires à la télécommande d'origine.

--profondeur
Créer un peu profond clone avec un historique tronqué au nombre de commits spécifié.
Implique --single-branch sauf si --no-single-branch est donné pour récupérer les historiques à proximité
les pointes de toutes les branches.

--[no-]simple-branche
Cloner uniquement l'historique menant à la pointe d'une seule branche, soit spécifié par le
--branch option ou le HEAD de la branche principale distante pointe vers. Plus loin dans
le référentiel résultant ne mettra à jour que la branche de suivi à distance pour la branche
cette option a été utilisée pour le clonage initial. Si la TÊTE de la télécommande n'a pas pointé
à n'importe quelle branche lorsque --single-branch clone a été créé, aucune branche de suivi à distance n'est
créé.

--récursif, --recurse-submodules
Une fois le clone créé, initialisez tous les sous-modules à l'intérieur, en utilisant leur valeur par défaut
Les paramètres. Cela équivaut à exécuter git submodule update --init --recursive
immédiatement après la fin du clonage. Cette option est ignorée si le cloné
le référentiel n'a pas d'arbre de travail/d'extraction (c'est-à-dire si l'un des éléments --no-checkout/-n, --bare,
ou --mirror est donné)

--separate-git-dir=
Au lieu de placer le référentiel cloné là où il est censé être, placez le
référentiel dans le répertoire spécifié, puis créez un Git agnostique pour le système de fichiers symbolique
lien vers là. Le résultat est que le référentiel Git peut être séparé de l'arbre de travail.


Le référentiel (éventuellement distant) à partir duquel cloner. Voir la section URL ci-dessous pour plus
informations sur la spécification des référentiels.


Le nom d'un nouveau répertoire dans lequel cloner. La partie "humaine" de la source
référentiel est utilisé si aucun répertoire n'est explicitement donné (repo pour /path/to/repo.git et
foo pour host.xz:foo/.git). Le clonage dans un répertoire existant n'est autorisé que si le
le répertoire est vide.

GIT URL

En général, les URL contiennent des informations sur le protocole de transport, l'adresse du
serveur distant et le chemin d'accès au référentiel. Selon le protocole de transport, certains
de ces informations peuvent être absentes.

Git prend en charge les protocoles ssh, git, http et https (de plus, ftp et ftps peuvent être utilisés
pour l'extraction et rsync peuvent être utilisés pour l'extraction et le push, mais ceux-ci sont inefficaces et
obsolète ; ne les utilisez pas).

Le transport natif (c'est-à-dire l'URL git://) n'effectue aucune authentification et doit être utilisé avec
prudence sur les réseaux non sécurisés.

Les syntaxes suivantes peuvent être utilisées avec :

· ssh://[user@]host.xz[:port]/path/to/repo.git/

· git://host.xz[:port]/path/to/repo.git/

· http[s]://host.xz[:port]/path/to/repo.git/

· ftp[s]://host.xz[:port]/chemin/vers/repo.git/

· rsync://host.xz/path/to/repo.git/

Une syntaxe alternative de type scp peut également être utilisée avec le protocole ssh :

· [utilisateur@]host.xz:chemin/vers/repo.git/

Cette syntaxe n'est reconnue que s'il n'y a pas de barres obliques avant le premier deux-points. CA aide
différencier un chemin local qui contient un deux-points. Par exemple, le chemin local foo:bar pourrait
être spécifié comme un chemin absolu ou ./foo:bar pour éviter d'être mal interprété comme une URL ssh.

Les protocoles ssh et git prennent également en charge l'extension ~username :

· ssh://[user@]host.xz[:port]/~[user]/path/to/repo.git/

· git://host.xz[:port]/~[user]/path/to/repo.git/

· [utilisateur@]host.xz :/~[utilisateur]/chemin/vers/repo.git/

Pour les référentiels locaux, également pris en charge par Git nativement, les syntaxes suivantes peuvent être
utilisé:

· /chemin/vers/repo.git/

· file:///chemin/vers/repo.git/

Ces deux syntaxes sont pour la plupart équivalentes, sauf que la première implique l'option --local.

Lorsque Git ne sait pas comment gérer un certain protocole de transport, il essaie d'utiliser le
à distance- assistant à distance, s'il existe. Pour demander explicitement un assistant à distance,
la syntaxe suivante peut être utilisée :

· ::

où peut être un chemin, un serveur et un chemin, ou une chaîne arbitraire de type URL
reconnu par l'assistant à distance spécifique invoqué. Voir aides-gitremote(1) pour
détails.

S'il existe un grand nombre de référentiels distants portant le même nom et que vous souhaitez utiliser un
format différent pour eux (de sorte que les URL que vous utilisez seront réécrites en URL qui
travail), vous pouvez créer une section de configuration du formulaire :

[url " "]
au lieu de =

Par exemple, avec ceci :

[url "git://git.host.xz/"]
placeOf = host.xz:/chemin/vers/
au lieu de = travail :

une URL comme "work:repo.git" ou comme "host.xz:/path/to/repo.git" sera réécrite dans n'importe quel
contexte qui prend une URL pour être "git://git.host.xz/repo.git".

Si vous souhaitez réécrire les URL pour le push uniquement, vous pouvez créer une section de configuration du
forme:

[url " "]
pushInsteadOf =

Par exemple, avec ceci :

[url "ssh://example.org/"]
pushInsteadOf = git://example.org/

une URL comme "git://example.org/path/to/repo.git" sera réécrite vers
"ssh://example.org/path/to/repo.git" pour les push, mais les pulls utiliseront toujours l'original
URL.

EXEMPLES

· Cloner depuis l'amont :

$ git clone git://git.kernel.org/pub/scm/.../linux.git mon-linux
$ cd mon-linux
Faire $

· Faire un clone local qui emprunte au répertoire courant, sans vérifier les choses
Départ:

$ git clone -l -s -n . ../copie
$ cd ../copie
$ git show-branche

· Cloner depuis l'amont en empruntant à un répertoire local existant :

$ git clone --référence /git/linux.git \
git://git.kernel.org/pub/scm/.../linux.git\
mon-linux
$ cd mon-linux

· Créez un référentiel nu pour publier vos modifications au public :

$ git clone --bare -l /home/proj/.git /pub/scm/proj.git

GIT

Une partie de l' jet(1) Suite

Utilisez git-clone en ligne en utilisant les services onworks.net