– l –local
wanneer de repository waarvan gekloond moet worden op een lokale machine,omzeilt deze vlag het normale “Git aware” transportmechanisme en kloont de repository door een kopie te maken van head en alles onder objecten en refs directory ‘ s.De bestanden onder .git/objects/ directory zijn hardlinkom ruimte te besparen indien mogelijk.
als de repository is opgegeven als een lokaal pad (bijvoorbeeld /path/to/repo),is dit de standaard, en –local is in wezen een no-op., Als therepository is opgegeven als een URL, dan wordt deze vlag genegeerd (en we gebruiken nooit de lokale optimalisaties). Het specificeren van --no-local zal de standaardwaarde overschrijven wanneer /path/to/repo wordt gegeven, waarbij in plaats daarvan het regularGit-transport wordt gebruikt.
— no-hardlinks
forceer het kloonproces van een repository op een lokaal bestandssysteem om de bestanden onder de .git/objectsmap te kopiëren in plaats van hardlinks te gebruiken. Dit kan desirablei zijn als je probeert een back-up te maken van je repository.,
-S –shared
wanneer de te klonen repository op de lokale machine staat,in plaats van harde koppelingen te gebruiken, wordt.git/objects/info/alternates automatisch ingesteld om de objectenmet de bron repository te delen. De resulterende repositorystart zonder enig object van zijn eigen.
Opmerking: Dit is een mogelijk gevaarlijke operatie; gebruik het niet tenzij u begrijpt wat het doet. Als je yourrepository kloont met behulp van deze optie en dan branches verwijdert (of een ander Git commando gebruikt dat een bestaande commit niet verwijst) in de bron repository, kunnen sommige objecten niet verwijzen (of bungelen).,Deze objecten kunnen worden verwijderd door normale Git operaties (zoals git commit)die automatisch git maintenance run --autoaanroepen. (Seegit-onderhoud.) Als deze objecten worden verwijderd en werden verwezen door de gekloonde repository, dan zal de gekloonde repository corrupt worden.
merk op dat het uitvoeren vangit repack zonder de--local optie in een repositorycleed met--shared objecten van de bron repository naar een packin de gekloonde repository zal kopiëren, waarbij de schijfruimte-besparing van.,Het is echter veilig om git gc uit te voeren, die de optie --local van Default gebruikt.
Als u de afhankelijkheid wilt verbreken van een repository die gekloond is met --shared onits bron repository, kunt u eenvoudig git repack -a uitvoeren om allobjects van de bron repository naar een pack in de gekloonde repository te kopiëren.,
–reference <repository>
als de referentie repository zich op de lokale machine bevindt,wordt .git/objects/info/alternates automatisch ingesteld op objecten uit de referentie repository. Het gebruik van een reeds bestaande repository als alternatief zal minder objecten vereisen die gekloond moeten worden van de repository, waardoor de netwerk-en lokale opslagkosten worden verminderd.Bij gebruik van de --reference-if-able, wordt een niet-bestaande map overgeslagen met een waarschuwing in plaats van de kloon af te breken.,
opmerking: Zie de noot voor de --shared optie, en ook de--dissociate optie.
— distantieer
Leen de objecten uit referentie repositories die specifiek zijnMet de--reference opties alleen om netwerkoverdracht te verminderen, en stop met lenen van hen nadat een kloon is gemaakt door het maken van noodzakelijke lokale kopieën van geleende objecten., Deze optie kan ook worden gebruikt bij het lokaal klonen van een depot dat al objecten leent van een ander Depot—de nieuwe repository zal objecten lenen van dezelfde repository, en deze optie kan worden gebruikt om de borrowing te stoppen.
– q — quiet
rustig werken. Voortgang wordt niet gerapporteerd aan de standaardfoutstream.
– v –verbose
uitgebreid uitvoeren. Heeft geen invloed op de rapportage van voortgang statusto de standaard foutstroom.,
— progress
voortgangsstatus wordt standaard gerapporteerd op de standaard foutenstream wanneer deze aan een terminal is gekoppeld, tenzij --quietis opgegeven. Deze vlag dwingt de voortgangsstatus af, zelfs als de standaardfoutstream niet naar een terminal wordt geleid.
–server-option=<option>
zend de gegeven tekenreeks naar de server wanneer u communiceert met Protocol versie 2. De gegeven string mag geen NUL-of LF-teken bevatten. De afhandeling van Serveropties door de server, inclusief Onbekende, is serverspecifiek.,Wanneer meerdere --server-option=<option> worden gegeven, worden ze allemaal naar de andere kant gestuurd in de volgorde die op de commandoregel wordt vermeld.
-n –no-checkout
Er wordt geen checkout van HEAD uitgevoerd nadat de kloon is voltooid.
–bare
Maak een kale Git repository. Dat wil zeggen, in plaats van <directory> aan te maken en de administratieve bestanden in <directory>/.git te plaatsen, maak de <directory>zelf de $GIT_DIR. Dit impliceert duidelijk de --no-checkoutomdat er nergens is om de werkboom te controleren.,Ook worden de branch heads op de remote direct gekopieerd naar overeenkomstige lokale branch heads, zonder ze te koppelen aan refs/remotes/origin/. Als deze optie wordt gebruikt, worden noch remote-tracking branches noch de gerelateerde configuratie variabelen aangemaakt.
— sparse
Initialiseer het sparse-checkout bestand zodat de workingdirectory begint met alleen de bestanden in de root van de repository. Het sparse-checkout bestand kan worden gewijzigd om de werkmap te laten groeien als dat nodig is.,
–filter=<filter-spec>
Gebruik de gedeeltelijke kloon functie en verzoek dat de server sendsa subset van bereikbare objecten volgens een bepaald object filter.Bij gebruik van --filter wordt de meegeleverde <filter-spec> gebruikt voor het partiële kloonfilter. Bijvoorbeeld, --filter=blob:none filtert alle blobs (bestandsinhoud) totdat Git ze nodig heeft. Ook filtert--filter=blob:limit=<size> alle blobs met de kleinste grootte uit <size>., Voor meer details over filterspecificaties, zie de --filter optie in git-rev-list.
— mirror
een mirror van de bronrepository instellen. Dit impliceert --bare.Vergeleken met --bare, --mirror geeft niet alleen lokale branches van de bron aan lokale branches van het doel, het brengt alle refs in kaart (Inclusief remote-tracking branches, notities enz.) en stelt een refspec-configuratie in, zodat al deze refs worden overschreven door een git remote update in het doel repository.,
-o <name> –origin <name>
Instead of using the remote name origin to keep track of the upstreamrepository, use <name>. Overrides clone.defaultRemoteName from theconfig.,
-b <naam> –branch <naam>
in plaats van de nieuw aangemaakte HEAD te wijzen naar de branch waarnaar de head van de gekloonde repository verwijst, wijs naar <name> branchin plaats. In een niet-kale repository is dit de branch die uitgecheckt zal worden.--branch kan ook tags nemen en de HEAD losmaken bij die commitin de resulterende repository.,
-u <upload-pack> –upload-pack <upload-pack>
indien gegeven, en de repository waarvan moet worden gekloond via ssh, specificeert dit een niet-standaard pad voor de opdrachtrun op de andere kant.
–template = <template_directory>
specificeer de map van waaruit sjablonen zullen worden gebruikt;(zie de sectie” TEMPLATE DIRECTORY ” van git-init.,)
-c <toets>=<waarde> –config <toets>=<waarde>
Stel een configuratie variabele in het nieuw-archief;dit wordt direct van kracht na de gegevensopslagruimte isinitialized, maar voordat de externe geschiedenis wordt opgehaald of anyfiles gecontroleerd. De sleutel is in hetzelfde formaat als verwacht bygit-config (bijvoorbeeld core.eol=true)., Als multiplevalues worden gegeven voor dezelfde sleutel, zal elke waarde naar het configuratiebestand worden geschreven. Dit maakt het bijvoorbeeld veilig om refspecs toe te voegen aan de origin remote.
vanwege beperkingen van de huidige implementatie, worden sommige configuratievariables pas van kracht na de eerste fetch en checkout.Configuratievariabelen waarvan bekend is dat ze geen effect hebben, zijn:remote.<name>.mirror en remote.<name>.tagOpt. Gebruik in plaats daarvan de opties corresponding --mirror en --no-tags.,
–depth <depth>
Maak een ondiepe kloon met een geschiedenis ingekort tot het gespecificeerde aantal commits. Impliceert --single-branch tenzij--no-single-branch wordt gegeven om de geschiedenissen bij thetips van alle branches op te halen. Als u submodules oppervlakkig wilt klonen,geeft u ook --shallow-submodulesdoor.
–shallow-since=<date>
Maak een ondiepe kloon met een geschiedenis na de opgegeven tijd.,
–shallow-exclude=<revision>
Maak een ondiepe kloon met een geschiedenis, met uitzondering van commits die bereikbaar zijn vanuit een opgegeven remote branch of tag. Deze optie kan meerdere keren worden opgegeven.
–single-branch
kloon alleen de geschiedenis die leidt naar de punt van een enkele branch,ofwel gespecificeerd door de --branch optie of de primarybranch remote ‘ s HEAD wijst op.Verdere fetches in de resulterende repository zullen alleen de remote-tracking branch updaten voor de branch die deze optie werd gebruikt voor het oorspronkelijke klonen., Als de HEAD op de remote niet naar anybranch wees toen --single-branch kloon werd gemaakt, wordt er geen remote-trackingbranch gemaakt.
— no-tags
kan gebruikt worden in combinatie met --single-branch om een branch te klonen en te onderhouden met geen andere referenties dan een enkele gekloonde Branch. Dit is bijvoorbeeld handig om minimale klonen van de defaultbranch van een repository te behouden voor zoekindexering.
— recurse-submodules
nadat de kloon is gemaakt, initialiseer en kloon submodules within op basis van de opgegeven pathspec., Als er geen pathspec wordt verstrekt, worden alle submodules geïnitialiseerd en gekloond.Deze optie kan meerdere keren worden gegeven voor pathspecs bestaande uit meerdere items. De resulterende kloon heeft submodule.active ingesteld op de opgegeven pathspec, of”.”(betekent alle submodules) als nopathspec wordt verstrekt.
Submodules worden geïnitialiseerd en gekloond met hun standaardinstellingen. Dit is equivalent aan het draaien vangit submodule update --init --recursive <pathspec> onmiddellijk nadat de kloon is voltooid. Deze optie wordt genegeerd als de gekloonde repository geen worktree/checkout heeft (d.w.z., als een van --no-checkout/-n, --bare,of --mirror wordt gegeven)
–shallow-submodules
alle submodules die worden gekloond zullen ondiep zijn met een diepte van 1.
–remote-submodules
alle submodules die gekloond worden zullen de status van de remote-tracking branch van de submodule gebruiken om de submodule bij te werken, in plaats van de opgenomen SHA-1 van het superproject. Gelijk aan het passeren van --remote naargit submodule update.,
–separate-git-dir=<git dir>
in plaats van de gekloonde repository te plaatsen waar het verondersteld wordt te zijn, plaats je de gekloonde repository op de opgegeven directory en maak dan een bestandssysteem-agnostische Git symbolische link naar daar.Het resultaat is dat Git repository gescheiden kan worden van workingtree.
– j <n> –jobs <n>
het aantal submodules dat tegelijkertijd is opgehaald.Standaard wordt de optie submodule.fetchJobs gebruikt.,
<repository>
De (mogelijk remote) repository om van te klonen. Zie de sectie git URL ‘ s hieronder voor meer informatie over het specificeren van repositories.
<map>
Leave a Reply