Git Clone چیست؟

Git Clone یعنی ساختن یک کپی محلی کامل (در حالت پیش‌فرض) از یک Repository موجود — شامل فایل‌های نسخهٔ جاری، تاریخچهٔ Commitها، و پیکربندی Remote تا بعداً Fetch/Pull/Push کنید. فرمان استاندارد git clone است و در مستندات رسمی git-scm به‌عنوان «Clone a repository into a new directory» تعریف شده است.

طبق GitHub Docs، وقتی مخزنی روی GitHub است، Clone آن را از Remote به ماشین (یا Codespace) می‌آورد تا Conflict را حل کنید، فایل کم/زیاد کنید، و Commitهای بزرگ‌تر را Push کنید. Download ZIP فقط snapshot فعلی بدون تاریخچهٔ Git و بدون remote آماده است؛ برای همکاری روزمره جایگزین Clone نیست.

اگر مقالهٔ ۰۷۲ را با init شروع کردید، Clone مسیر دوم ورود به یک پروژهٔ ازقبل‌موجود است — همان‌طور که Pro Git در Getting a Git Repository می‌گوید.

پاسخ کوتاه

git clone <url> یک پوشه می‌سازد، آن را به‌عنوان مخزن Git مقداردهی می‌کند، معمولاً remote با نام origin را به همان URL می‌چسباند، تاریخچه را می‌گیرد، و Branch پیش‌فرض را Checkout می‌کند. بعد از Clone، برای به‌روزرسانی کافی است Fetch/Pull کنید نه اینکه دوباره ZIP بردارید.

Clone فقط «دانلود فایل» نیست؛ یک مخزن مستقل با حافظهٔ کامل (یا تقریباً کامل) تاریخچه است که به بالادست وصل شده.

Clone دقیقاً چه کارهایی انجام می‌دهد؟

صفحهٔ Getting changes from a remote repository در GitHub Docs مراحل مفهومی را این‌گونه خلاصه می‌کند:

1. پوشهٔ جدید با نام انسانی مخزن ساخته می‌شود (مگر نام دیگری بدهید).
2. مخزن init می‌شود و اشیاء تاریخچه دانلود می‌شوند.
3. remote به نام origin (پیش‌فرض) ثبت می‌شود.
4. برای Branchهای Remote، remote-tracking branchها مثل origin/main ساخته می‌شوند.
5. Branch پیش‌فرض Checkout می‌شود تا Working tree آمادهٔ کار باشد.

پس از آن، git fetch بدون آرگومان remote-trackingها را به‌روز می‌کند و git pull علاوه بر آن Merge به Branch جاری را هم انجام می‌دهد — مگر Clone با --single-branch محدودیت ساخته باشد.

فرمان‌های رایج

bash

git clone https://github.com/OWNER/REPO.git cd REPO

با SSH (اگر کلید تنظیم شده باشد):

bash

git clone git@github.com:OWNER/REPO.git

نام پوشهٔ مقصد دلخواه:

bash

git clone https://github.com/OWNER/REPO.git my-app

Checkout یک Branch مشخص از ابتدا (گزینهٔ -b در git-clone):

bash

git clone -b develop https://github.com/OWNER/REPO.git

Clone در برابر Download ZIP و init

Shallow clone و مخازن بزرگ

گزینهٔ --depth تاریخچه را کوتاه می‌کند تا شبکه و دیسک کمتر مصرف شود:

bash

git clone --depth 1 https://github.com/OWNER/REPO.git

طبق مستند git-clone، depth معمولاً --single-branch را هم القا می‌کند مگر خلافش را بخواهید. برای CI و اسکن سریع مفید است؛ برای کارهایی مثل Blame کامل تاریخچه یا بعضی bisectها محدودیت دارد. Partial clone با --filter=blob:none هم در مستندات رسمی برای مخازن خیلی بزرگ آمده است — وقتی نیاز واقعی دارید سراغش بروید.

دسترسی، پروتکل و خطاهای رایج

• مخزن Private بدون احراز هویت Clone نمی‌شود؛ PAT/SSH لازم است.
• URL غلط یا Branch پیش‌فرض حذف‌شده خطا می‌دهد (GitHub troubleshooting cloning).
• کلون روی پوشهٔ غیرخالی مجاز نیست مگر خالی باشد.
• --shared و برخی بهینه‌های local خطرناک‌اند اگر نفهمید چه می‌کنند؛ برای شروع از آن‌ها پرهیز کنید.

اگر فقط می‌خواهید بخوانید و Push ندارید، Clone همچنان تاریخچه می‌آورد؛ مجوز Write جدا از عمل Clone است.

بعد از Clone چه کنید؟

1. git status و git branch -a را ببینید تا بفهمید کجایید.
2. README و دستور نصب پروژه را بخوانید.
3. قبل از تغییر بزرگ، Branch جدید بسازید (مقالهٔ ۰۷۶).
4. برای همگام‌سازی بعدی Pull/Fetch — نه Clone مجدد روی همان پوشه.

Clone دوباره در پوشهٔ جدا فقط وقتی منطقی است که محیط را خراب کرده‌اید یا می‌خواهید Working tree تمیز موازی داشته باشید. برای به‌روز شدن روزانه، Pull کافی است.

نکته برای مدیران و آنبوردینگ

در چک‌لیست ورود نیروی جدید، به‌جای فرستادن ZIP، URL مخزن و سطح دسترسی را بدهید و بخواهید Clone کنند. این کار از روز اول تاریخچه، Hookها و .gitignore درست را می‌آورد و از «نسخهٔ ناقص روی دسکتاپ» جلوگیری می‌کند.

جمع‌بندی

Clone راه استاندارد ورود به یک مخزن موجود است: کپی تاریخچه + اتصال origin + Checkout Branch پیش‌فرض. ZIP برای نگاه سریع است؛ Clone برای کار واقعی. با فهم همین یک فرمان، نصف سردرگمی «از کجا کد را بگیرم؟» در تیم‌ها حل می‌شود.

قدم بعدی طبیعی: تغییر محلی، Commit، و Push/Pull برای همگام‌سازی با دیگران.

HTTPS در برابر SSH برای Clone

هر دو پروتکل معتبرند. HTTPS معمولاً شروع ساده‌تری دارد و با credential helper یا token کار می‌کند. SSH بعد از تنظیم کلید، برای کار روزانه اصطکاک کمتری دارد و در تیم‌ها رایج است. مهم این است که URL را از صفحهٔ رسمی مخزن کپی کنید و به لینک‌های ناشناس در چت اعتماد نکنید.

اگر Clone با خطای مجوز شکست خورد، اول دسترسی حساب به مخزن Private را چک کنید، بعد کلید/توکن، بعد شبکه. ترتیب نادرست دیباگ باعث می‌شود ساعت‌ها «گیت خراب است» بگویید در حالی که Invite نرسیده است.

Clone تکی نیست: Fork و چند Remote

در متن‌باز اغلب اول Fork می‌کنید (کپی سمت سرور زیر حساب شما) و بعد همان Fork را Clone می‌کنید. سپس Remote دوم به نام upstream به مخزن اصلی اضافه می‌شود تا بتوانید به‌روزرسانی بالادست را بگیرید و PR بدهید. این الگو در About Git توضیح داده شده و با Shared repository داخلی شرکت فرق دارد.

bash

git remote add upstream https://github.com/ORIGINAL/OWNER-REPO.git git fetch upstream

نام Remote قرارداد است نه جادو؛ origin و upstream فقط قراردادهای رایج‌اند.

چه زمانی Shallow کافی نیست؟

اگر به تاریخچهٔ کامل برای bisect، تحلیل ownership، یا تولید changelog نیاز دارید، depth کم محدودیت ایجاد می‌کند. می‌توان بعدها تاریخچه را عمیق‌تر کرد، ولی برای مخزن کاری روزمرهٔ تیم محصول معمولاً Clone کامل بهتر است مگر مخزن غول‌آسا باشد.

در CI، shallow سریع و منطقی است چون runner به تاریخچهٔ ده‌ساله نیاز ندارد. سیاست را بر اساس سناریو انتخاب کنید نه عادت یکسان برای همه جا.

بهداشت پوشه‌های Cloneشده

• نام پوشه را با پروژه هم‌نام و بدون فاصلهٔ عجیب نگه دارید.
• چند Clone از یک مخزن فقط وقتی لازم است که محیط‌های جدا می‌خواهید؛ وگرنه Branch کافی است.
• پوشه‌های Clone قدیمی فراموش‌شده را پاک یا آرشیو کنید تا Secretهای محلی و فضای دیسک مدیریت شوند.
• هرگز .git را از یک Clone به پروژهٔ دیگر «کپی دستی عجیب» نکنید مگر دقیقاً بدانید چه می‌کنید.

عیب‌یابی سریع

1. آیا URL درست است و مخزن هنوز وجود دارد؟
2. آیا به VPN/شبکه‌ای نیاز دارید که الان وصل نیست؟
3. آیا Branch پیش‌فرض در Remote تغییر نام داده؟
4. آیا فضای دیسک کافی است؟
5. آیا antimalware فایل‌های .git را قفل کرده؟

پیام خطا را کامل بخوانید؛ Git معمولاً راهنمای بعدی را در همان خروجی می‌دهد. کپی کردن کور فرمان‌های Force از فروم‌ها بدون فهم، خطرناک است.

تمرین

یک مخزن متن‌باز کوچک را Clone کنید، log --oneline را بخوانید، یک Branch محلی بسازید و یک Commit آزمایشی بزنید بدون Push به بالادست. هدف حس کردن تفاوت Working tree شخصی با Remote است. اگر بعداً PR می‌دهید، آن مسیر جداگانه و محترمانه است.

Clone در CI و اتوماسیون

رانرهای CI تقریباً همیشه اول مخزن را Clone (اغلب shallow) می‌کنند، بعد تست می‌سازند. اگر pipeline شما به تاریخچهٔ کامل تگ‌ها نیاز دارد، تنظیم depth را صریح کنید. اگر Submodule دارید، --recurse-submodules یا گام جدا لازم است؛ فراموش کردنش از خطاهای کلاسیک CI است.

در اتوماسیون، به جای Clone دستی تکراری روی لپ‌تاپ، به Idempotent بودن مسیر فکر کنید: هر Job از صفر Clone تمیز می‌گیرد و به وضعیت کثیف محلی وابسته نیست. این یکی از دلایل قدرت CI است.

امنیت URL و فیشینگ مخزن

لینک مخزن را از منبع معتبر بگیرید. مخازن جعلی با نام شبیه می‌توانند وابستگی مخرب داشته باشند. در شرکت، فهرست مخازن رسمی را در مستند داخلی نگه دارید. برای نصب ابزار، ترجیح بدهید از Release رسمی و checksum استفاده کنید نه Clone ناشناس از فورک نامشخص.

بعد از Clone، قبل از اجرای اسکریپت‌های نصب، README را بخوانید. اجرای کور install.sh از مخزن ناشناس خطرناک است — کنترل نسخه بودن، کد را امن نمی‌کند.

Sparse checkout و مخازن مونوریپو

در مونوریپوهای خیلی بزرگ، گاهی فقط یک زیرپوشه لازم است. قابلیت sparse-checkout و فیلترها در مستندات git-clone برای همین سناریوهاست. روز اول یادگیری لازم نیست؛ وقتی Clone کامل غیرعملی شد سراغش بروید و با تیم هماهنگ کنید چون ابزارها باید همان مدل را بفهمند.

قبل از sparse، اندازه بگیرید: آیا مشکل دیسک است، شبکه است، یا زمان CI؟ راه‌حل باید به گلوگاه واقعی بخورد.

مقایسهٔ تجربهٔ تازه‌کار: ZIP در برابر Clone

ZIP فوری به‌نظر می‌رسد ولی هفتهٔ بعد نمی‌توانید به‌روز شوید مگر ZIP جدید بگیرید و دستی قاطی کنید. Clone اول کمی اصطکاک احراز هویت دارد، بعداً با یک Pull به‌روز می‌شود. برای هر همکاری بیش از یک روز، Clone برنده است.

اگر به کسی غیرفنی باید «فقط فایل بدهید»، ZIP یا Release asset منطقی است؛ او را مجبور به Git نکنید. ابزار را با مخاطب انتخاب کنید.

جمع‌بندی عملی

Clone را به‌عنوان «ورود رسمی به پروژه» نهادینه کنید: در README اول خط clone، بعد نصب وابستگی. در جلسهٔ آنبوردینگ همان را با هم اجرا کنید. وقتی همه از یک فرمان وارد می‌شوند، نیمی از مشکلات «روی سیستم من کار می‌کند» حذف می‌شود چون حداقل پایهٔ کد یکسان است.

Clone جزئی در برابر چندبار Clone کامل

گاهی افراد برای «تمیز کردن» هر روز Clone جدید می‌گیرند. این کار شبکه و دیسک را هدر می‌دهد و Branchهای محلی Pushنشده را در معرض فراموشی می‌گذارد. راه درست: یک Clone پایدار، Branch برای کار، و گاهی git clean برای فایل‌های Untracked — با احتیاط.

اگر Working tree را به وضعیتی رساندید که نمی‌فهمید، قبل از Clone دوباره: status، stash list، و log را ببینید. اغلب قابل نجات است. Clone دوباره آخرین راه‌حل برای خرابکاری محلی است نه عادت صبحگاهی.

در لپ‌تاپ‌های مشترک آموزشی، Clone روی مسیر مشخص و حذف در پایان کار از نشت توکن‌های ذخیره‌شده کم می‌کند. credentialها را روی ماشین عمومی به‌خاطر نسپارید.

خلاصه: Clone را رویداد ورود بدانید؛ Pull را رویداد به‌روزرسانی. جابه‌جا کردنشان زندگی را سخت می‌کند.

چک‌لیست Clone برای پروژه‌های شرکتی

1. از فهرست مخازن رسمی لینک را بردارید نه از چت قدیمی.
2. دسترسی Read را قبل از جلسهٔ آنبوردینگ بگیرید.
3. SSH یا HTTPS را طبق استاندارد تیم پیکربندی کنید.
4. بعد از Clone، submodule و LFS را اگر در README آمده اجرا کنید.
5. نسخهٔ زبان/ابزار را با فایل‌های قفل نسخه تطبیق دهید.
6. یک Branch شخصی آزمایشی بسازید تا Push به main تست نشود.

این چک‌لیست را به onboarding doc بچسبانید. هر بند یک شکست کلاسیک هفتهٔ اول را کم می‌کند. Clone موفق شروع کار است نه پایان پیکربندی محیط.

اگر Clone ساعت‌ها طول می‌کشد، اول شبکه و آنتی‌ویروس را بررسی کنید؛ بعد سراغ shallow یا reference clone بروید. بهینه‌سازی زودرس بدون اندازه، فقط پیچیدگی اضافه می‌کند.

در پایان: Clone را بفهمید تا ZIP را با همکاری اشتباه نگیرید؛ بقیهٔ فرمان‌های Remote روی همین پایه سوار می‌شوند.

یادآوری نهایی دربارهٔ Clone

Clone قرارداد ورود است: تاریخچه، remote، و Branch پیش‌فرض. اگر فقط یک عادت از این مقاله بسازید، این باشد که پروژه را با Clone رسمی شروع کنید و به‌روزرسانی را با Pull ادامه دهید. ZIP را برای مخاطب غیرفنی یا توزیع فایل نگه دارید، نه برای کار روزانهٔ توسعه.

با همین تمایز، بخش بزرگی از آشفتگی آنبوردینگ و نسخه‌های پراکنده از بین می‌رود. قدم بعد همگام‌سازی آگاهانه با Push و Pull است.

منابع و مراجع

• git-clone documentation — https://git-scm.com/docs/git-clone
• GitHub Docs — Cloning a repository — https://docs.github.com/en/repositories/creating-and-managing-repositories/cloning-a-repository
• GitHub Docs — Getting changes from a remote repository — https://docs.github.com/en/get-started/using-git/getting-changes-from-a-remote-repository
• Pro Git — Getting a Git Repository — https://git-scm.com/book/en/v2/Git-Basics-Getting-a-Git-Repository
• GitHub Docs — About Git — https://docs.github.com/en/get-started/using-git/about-git