نام (NAME)

git-clone - کلون کردن یک مخزن درون یک دایرکتوری جدید

خلاصه دستور (SYNOPSIS)

git clone [--template=<template-directory>]
          [-l] [-s] [--no-hardlinks] [-q] [-n] [--bare] [--mirror]
          [-o <name>] [-b <name>] [-u <upload-pack>] [--reference <repository>]
          [--dissociate] [--separate-git-dir <git-dir>]
          [--depth <depth>] [--[no-]single-branch] [--[no-]tags]
          [--recurse-submodules[=<pathspec>]] [--[no-]shallow-submodules]
          [--[no-]remote-submodules] [--jobs <n>] [--sparse] [--[no-]reject-shallow]
          [--filter=<filter-spec> [--also-filter-submodules]] [--] <repository>
          [<directory>]

توضیحات (DESCRIPTION)

یک مخزن را درون یک دایرکتوری تازه‌ساخته‌شده کلون می‌کند، برای هر شاخه در مخزن کلون‌شده شاخه‌های ردگیری دوردست (قابل مشاهده با git branch --remotes) می‌سازد، و یک شاخه اولیه منشعب‌شده از شاخه فعال فعلی مخزن کلون‌شده را ایجاد و دریافت (checkout) می‌کند.

پس از انجام کلون، یک دستور ساده git fetch بدون آرگومان تمام شاخه‌های ردگیری دوردست را به‌روزرسانی می‌کند، و یک دستور git pull بدون آرگومان علاوه بر آن، در صورت وجود شاخه اصلی (master/main) دوردست، آن را با شاخه اصلی محلی فعلی ادغام می‌کند (هنگامی که گزینه --single-branch داده شود این امر صادق نیست؛ در ادامه را ببینید).

این پیکربندی پیش‌فرض با ایجاد مراجعی به سرشاخه‌های دوردست در زیرمسیر refs/remotes/origin و با مقداردهی اولیه متغیرهای پیکربندی remote.origin.url و remote.origin.fetch حاصل می‌شود.

گزینه‌ها (OPTIONS)

-l, --local

--no-hardlinks

-s, --shared

--reference=<repository>, --reference-if-able=<repository>

--dissociate

-q, --quiet

-v, --verbose

--progress

--server-option=<option>

-n, --no-checkout

--no-reject-shallow, --reject-shallow

--bare

--sparse

--filter=<filter-spec>

--also-filter-submodules

--mirror

-o<name>, --origin=<name>

-b<name>, --branch=<name>

--revision=<rev>

-u<upload-pack>, --upload-pack=<upload-pack>

--template=<template-directory>

-c<key>=<value>, --config=<key>=<value>

--depth=<depth>

--shallow-since=<date>

--shallow-exclude=<ref>

--single-branch, --no-single-branch

--tags, --no-tags

--recurse-submodules[=<pathspec>]

--shallow-submodules, --no-shallow-submodules

--remote-submodules, --no-remote-submodules

--separate-git-dir=<git-dir>

--ref-format=<ref-format>

-j<n>, --jobs=<n>

<repository>

<directory>

--bundle-uri=<uri>

نشانی‌های گیت (GIT URLS)

به‌طور کلی، نشانی‌ها (URL) حاوی اطلاعاتی درباره پروتکل انتقال، نشانی سرور دوردست و مسیر مخزن هستند. بسته به پروتکل انتقال، ممکن است برخی از این اطلاعات وجود نداشته باشند.

گیت از پروتکل‌های ssh، git، http و https پشتیبانی می‌کند (علاوه بر این، ftp و ftps می‌توانند برای واکشی استفاده شوند، اما این کار ناکارآمد و منسوخ است؛ از آن‌ها استفاده نکنید).

انتقال بومی (یعنی نشانی git://) هیچ‌گونه احراز هویتی انجام نمی‌دهد و باید در شبکه‌های ناامن با احتیاط استفاده شود.

قالب‌های ساختاری زیر می‌توانند با آن‌ها استفاده شوند:

همچنین می‌توان یک نحو جایگزین شبیه scp را با پروتکل ssh استفاده کرد:

این نحو تنها در صورتی تشخیص داده می‌شود که هیچ اسلشی قبل از اولین دو‌نقطه نباشد. این امر به تمایز مسیر محلی که حاوی دو‌نقطه است کمک می‌کند. برای نمونه، مسیر محلی foo:bar می‌تواند به‌صورت یک مسیر مطلق یا ./foo:bar مشخص شود تا از تفسیر نادرست آن به‌عنوان یک نشانی ssh جلوگیری شود.

پروتکل‌های ssh و git علاوه بر این از بسط ~<username> پشتیبانی می‌کنند:

برای مخازن محلی، که به‌طور بومی توسط گیت نیز پشتیبانی می‌شوند، می‌توان از نحوهای زیر استفاده کرد:

این دو نحو عمدتاً معادل هستند، به جز اینکه اولی متضمن گزینه --local است.

دستورهای git clone، git fetch و git pull (اما نه git push) یک فایل باندل مناسب را نیز می‌پذیرند. نگاه کنید به git-bundle(1).

هنگامی که گیت روش کار با یک پروتکل انتقال معین را نمی‌داند، تلاش می‌کند از دستیار دوردست remote-<transport> در صورت وجود استفاده کند. برای درخواست صریح یک دستیار دوردست، می‌توان از نحو زیر استفاده کرد:

که در آن <address> می‌تواند یک مسیر، یک سرور و مسیر، یا یک رشته دلخواه شبیه نشانی باشد که توسط دستیار دوردست مربوطه فراخوانی‌شده شناسایی می‌شود. برای جزئیات به gitremote-helpers(7) مراجعه کنید.

اگر تعداد زیادی مخزن دوردست با نام‌های مشابه وجود دارد و می‌خواهید فرمت متفاوتی برای آن‌ها استفاده کنید (به گونه‌ای که نشانی‌های مورداستفاده شما به نشانی‌هایی که کار می‌کنند بازنویسی شوند)، می‌توانید یک بخش پیکربندی به این شکل بسازید:

[url "<actual-url-base>"]
        insteadOf = <other-url-base>

برای نمونه، با این تنظیم:

[url "git://git.host.xz/"]
        insteadOf = host.xz:/path/to/
        insteadOf = work:

یک نشانی مانند "work:repo.git" یا مانند "host.xz:/path/to/repo.git" در هر زمینه‌ای که یک نشانی می‌پذیرد به "git://git.host.xz/repo.git" بازنویسی خواهد شد.

اگر می‌خواهید نشانی‌ها را فقط برای push بازنویسی کنید، می‌توانید یک بخش پیکربندی به این شکل بسازید:

[url "<actual-url-base>"]
        pushInsteadOf = <other-url-base>

برای نمونه، با این تنظیم:

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

یک نشانی مانند "git://example.org/path/to/repo.git" برای ارسال‌ها (push) به "ssh://example.org/path/to/repo.git" بازنویسی می‌شود، اما دریافت‌ها (pull) همچنان از نشانی اصلی استفاده خواهند کرد.

مثال‌ها (EXAMPLES)

$ git clone git://git.kernel.org/pub/scm/.../linux.git my-linux
$ cd my-linux
$ make

$ git clone -l -s -n . ../copy
$ cd ../copy
$ git show-branch

$ git clone --reference /git/linux.git \
        git://git.kernel.org/pub/scm/.../linux.git \
        my-linux
$ cd my-linux

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

$ git clone --no-local /home/otheruser/proj.git /pub/scm/proj.git

پیکربندی (CONFIGURATION)

تمام موارد زیر این خط در این بخش به‌صورت گزینشی از مستندات git-config(1) گنجانده شده است. محتوای آن همان چیزی است که در آنجا یافت می‌شود:

init.templateDir

init.defaultBranch

init.defaultObjectFormat

init.defaultRefFormat

init.defaultSubmodulePathConfig

clone.defaultRemoteName

clone.rejectShallow

clone.filterSubmodules

گیت (GIT)

بخشی از مجموعه git(1)