یک مخزن
گیت در دو
نوع متفاوت
عرضه
می‌شود:
•یک
دایرکتوری
.git در ریشه
درخت کاری (working
tree)؛
•یک
دایرکتوری
<project>.git که یک
مخزن خام (bare -
یعنی بدون
درخت کاری
اختصاصی
خود) است، که
معمولاً
برای تبادل
تاریخچه‌ها
با دیگران
از طریق
ارسال (push) به
آن و واکشی (fetch)
از آن
استفاده
می‌شود.
نکته:
همچنین
می‌توانید
یک فایل
متنی ساده
به نام .git در
ریشه درخت
کاری خود
داشته
باشید که
حاوی gitdir: <path>
برای اشاره
به
دایرکتوری
واقعی حاوی
مخزن باشد.
این
سازوکار gitfile
نامیده
می‌شود و
معمولاً از
طریق
دستورات git
submodule و git worktree
مدیریت
می‌شود. این
قابلیت
اغلب برای
درخت کاری
یک
زیرماژول (submodule
checkout) استفاده
می‌شود تا
به شما در
ابرپروژه
(superproject)
دربرگیرنده
اجازه دهد
شاخه‌ای را
با git checkout
بررسی کنید
که فاقد آن
زیرماژول
است. دستور
checkout باید کل
درخت کاری
زیرماژول
را بدون از
دست دادن
مخزن
زیرماژول
حذف کند.
این موارد
ممکن است در
یک مخزن گیت
وجود داشته
باشند:
objects
مخزن
اشیاء (object store)
مرتبط با
این مخزن.
معمولاً یک
شیءدان
خودکفا است
(یعنی تمام
اشیایی که
توسط یک شیء
موجود در آن
مورد ارجاع
قرار
گرفته‌اند
نیز در آن
یافت
می‌شوند)،
اما چند راه
برای نقض
این اصل
وجود دارد.
1.می‌توانید
با ایجاد یک
کلون
کم‌عمق (shallow clone)،
یک مخزن
ناقص اما به
صورت محلی
قابل
استفاده
داشته
باشید. به
git-clone(1)
مراجعه
کنید.
2.می‌توانید
از
سازوکارهای
objects/info/alternates یا
$GIT_ALTERNATE_OBJECT_DIRECTORIES برای
قرض گرفتن
اشیاء از
سایر
شیءدان‌ها
استفاده
کنید. مخزنی
با این نوع
شیءدان
ناقص برای
انتشار و
استفاده با
پروتکل‌های
انتقال
ساده مناسب
نیست، اما
تا زمانی که
objects/info/alternates به
شیءدان‌هایی
که از آن‌ها
اشیاء قرض
می‌گیرد
اشاره
می‌کند
مشکلی
ندارد.
اگر متغیر
$GIT_COMMON_DIR تنظیم
شده باشد
این
دایرکتوری
نادیده
گرفته شده و
به جای آن از
"$GIT_COMMON_DIR/objects"
استفاده
خواهد شد.
objects/[0-9a-f][0-9a-f]
هر شیء
تازه
ایجادشده
در فایل
مخصوص به
خود ذخیره
می‌شود. این
اشیاء با
استفاده از
دو نویسه
نخست نام
شیء بر
مبنای sha1 در
میان ۲۵۶
زیرشاخه
پخش
می‌شوند تا
تعداد
ورودی‌های
دایرکتوری
در خود objects در
حد قابل
مدیریتی
باقی بماند.
اشیایی که
در اینجا
یافت
می‌شوند
اغلب اشیای
بسته‌بندی‌نشده
(یا منفرد / loose)
نامیده
می‌شوند.
objects/pack
بسته‌ها
(فایل‌هایی
که اشیای
زیادی را در
قالب فشرده
به همراه
فایلهای
ایندکس
نگهداری
می‌کنند تا
امکان
دسترسی
تصادفی به
آن‌ها
فراهم شود)
در این
دایرکتوری
قرار
دارند.
objects/info
اطلاعات
بیشتر در
مورد
شیءدان در
این
دایرکتوری
ثبت
می‌شود.
objects/info/packs
این فایل
به
پروتکل‌های
انتقال
ساده کمک
می‌کند تا
بسته‌های
موجود در
این شیءدان
را کشف کنند.
هر زمان که
بسته‌ای
اضافه یا
حذف
می‌شود، در
صورتی که
مخزن برای
انتقال‌های
ساده منتشر
شده باشد،
باید git update-server-info
اجرا شود تا
این فایل
به‌روز نگه
داشته شود. git
repack به طور
پیش‌فرض
این کار را
انجام
می‌دهد.
objects/info/alternates
این فایل
مسیرهای
شیءدان‌های
جایگزینی
را که این
شیءدان از
آن‌ها
اشیاء قرض
می‌گیرد،
در هر خط یک
مسیر، ثبت
می‌کند.
توجه داشته
باشید که
نه‌تنها
ابزارهای
بومی گیت از
آن به صورت
محلی
استفاده
می‌کنند،
بلکه
واکشی‌کننده
HTTP نیز سعی
می‌کند از
راه دور از
آن استفاده
کند؛ اگر در
فایل alternates خود
مسیرهای
نسبی (نسبت
به
پایگاه‌داده
اشیاء، نه
نسبت به
مخزن!) داشته
باشید
معمولاً
کار خواهد
کرد، اما
اگر از
مسیرهای
مطلق
استفاده
کنید کار
نخواهد کرد
مگر اینکه
مسیر مطلق
در
فایل‌سیستم
و URL وب یکسان
باشد.
همچنین به
objects/info/http-alternates
مراجعه
کنید.
objects/info/http-alternates
این فایل
نشانی‌های
اینترنتی URL
شیءدان‌های
جایگزینی
را که این
شیءدان از
آن‌ها
اشیاء قرض
می‌گیرد،
برای زمانی
که مخزن از
طریق HTTP واکشی
می‌شود ثبت
می‌کند.
refs
ارجاعات
در
زیرشاخه‌های
این
دایرکتوری
ذخیره
می‌شوند.
دستور git prune
می‌داند که
باید اشیای
قابل
دسترسی از
ارجاعات
موجود در
این
دایرکتوری
و
زیرشاخه‌های
آن را حفظ
کند. اگر
متغیر $GIT_COMMON_DIR
تنظیم شده
باشد، این
دایرکتوری
(به جز refs/bisect، refs/rewritten و
refs/worktree) نادیده
گرفته شده و
به جای آن از
"$GIT_COMMON_DIR/refs"
استفاده
خواهد شد.
refs/heads/name
اشیای
کامیت نوک
شاخه name را
ثبت
می‌کند.
refs/tags/name
نام هر
شیئی را ثبت
می‌کند
(لزوماً یک
شیء کامیت
نیست، یا
شیء تگی که
به یک شیء
کامیت
اشاره کند).
refs/remotes/name
اشیای
کامیت نوک
شاخه‌های
کپی‌شده از
یک مخزن راه
دور را ثبت
می‌کند.
refs/replace/<obj-sha1>
مقدار SHA-1
شیئی را که
جایگزین
<obj-sha1> می‌شود
ثبت می‌کند.
این شبیه به
info/grafts است و به
صورت داخلی
توسط
git-replace(1)
استفاده و
نگهداری
می‌شود.
برخلاف grafts،
چنین
ارجاعاتی
می‌توانند
میان مخازن
تبادل
شوند.
packed-refs
همان
اطلاعات refs/heads/،
refs/tags/ و موارد
مشابه را به
روشی
کارآمدتر
ثبت می‌کند.
به
git-pack-refs(1)
مراجعه
کنید. اگر $GIT_COMMON_DIR
تنظیم شده
باشد این
فایل
نادیده
گرفته شده و
به جای آن از
"
$GIT_COMMON_DIR/packed-refs"
استفاده
می‌شود.
HEAD
یک ارجاع
نمادین یا symref
(واژه‌نامه
را ببینید)
به فضای نام
refs/heads/ که شاخه
فعال فعلی
را توصیف
می‌کند. اگر
مخزن با هیچ
درخت کاری
مرتبط
نباشد (یعنی
یک مخزن
خام یا bare)،
معنای
زیادی
ندارد، اما
یک مخزن
معتبر گیت
باید فایل HEAD
را داشته
باشد؛ برخی
ابزارهای
سطح بالا (porcelains)
ممکن است از
آن برای حدس
زدن شاخه
«پیش‌فرض»
مخزن
(معمولاً
master)
استفاده
کنند. اگر
شاخه
نام‌گذاری‌شده
name (هنوز)
وجود
نداشته
باشد نیز
مجاز است. در
برخی
ساختارهای
قدیمی، به
جای یک symref،
این فایل یک
پیوند
نمادین (symlink)
است که به
شاخه جاری
اشاره
می‌کند.
همچنین HEAD
می‌تواند
مستقیماً
یک کامیت
خاص را ثبت
کند، به جای
اینکه یک symref
برای اشاره
به شاخه
جاری باشد.
چنین
وضعیتی
اغلب HEAD
جداشده (detached HEAD)
نامیده
می‌شود.
برای
جزئیات به
git-checkout(1) مراجعه
فرمایید.
config
فایل
پیکربندی
اختصاصی
مخزن. اگر
متغیر $GIT_COMMON_DIR
تنظیم شده
باشد، این
فایل
نادیده
گرفته شده و
از "$GIT_COMMON_DIR/config"
استفاده
خواهد شد.
config.worktree
فایل
پیکربندی
اختصاصی
دایرکتوری
کاری برای
دایرکتوری
کاری اصلی
در ساختار
چند درخت
کاری (به
git-worktree(1)
مراجعه
کنید).
branches
یک روش
منسوخ‌شده
برای ذخیره
نام‌های
کوتاه جهت
مشخص کردن
یک URL برای
دستورات
git
fetch،
git pull و
git push. یک
فایل
می‌تواند
به صورت
branches/<name> ذخیره
شود و سپس
name
می‌تواند
به جای
آرگومان
repository
به این
دستورات
داده شود.
برای
جزئیات بخش
REMOTES در
git-fetch(1) را
ببینید. این
سازوکار
قدیمی است و
بعید است در
مخازن
امروزی
یافت شود.
اگر $GIT_COMMON_DIR
تنظیم شده
باشد این
دایرکتوری
نادیده
گرفته شده و
از "
$GIT_COMMON_DIR/branches"
استفاده
می‌شود.
گیت در
نسخه Git 3.0
خواندن
مخازن راه
دور از این
دایرکتوری
را متوقف
خواهد کرد.
hooks
هوک‌ها
اسکریپت‌های
سفارشی‌سازی
هستند که
توسط
دستورات
گوناگون
گیت
استفاده
می‌شوند.
هنگام
اجرای
git init
تعدادی هوک
نمونه نصب
می‌شوند،
اما همه
آن‌ها به
طور
پیش‌فرض
غیرفعال
هستند. برای
فعال‌سازی،
پسوند
.sample
باید با
تغییر نام
از انتهای
نام فایل
حذف شود.
برای
جزئیات
بیشتر
درباره هر
هوک،
githooks(5) را
مطالعه
کنید. اگر
متغیر $GIT_COMMON_DIR
تنظیم شده
باشد این
دایرکتوری
نادیده
گرفته شده و
به جای آن از
"
$GIT_COMMON_DIR/hooks"
استفاده
خواهد شد.
common
هنگامی
که از چندین
درخت کاری
استفاده
می‌شود،
بیشتر
فایلهای
موجود در $GIT_DIR
به ازای هر
درخت کاری
مجزا هستند
به جز چند
استثنای
مشخص. با این
حال، تمام
فایلهای
زیر
دایرکتوری
common میان
تمامی
درخت‌های
کاری به
اشتراک
گذاشته
خواهند شد.
index
فایل
ایندکس
فعلی مخزن.
معمولاً در
یک مخزن خام
یافت
نمی‌شود.
sharedindex.<SHA-1>
بخش
ایندکس
مشترک، که
توسط $GIT_DIR/index و
سایر
فایلهای
ایندکس
موقت ارجاع
داده
می‌شود.
تنها در
حالت
ایندکس
تقسیم‌شده
(split index) معتبر
است.
info
اطلاعات
بیشتر
درباره
مخزن در این
دایرکتوری
ثبت می‌شود.
اگر متغیر
$GIT_COMMON_DIR تنظیم
شده باشد،
این
دایرکتوری
نادیده
گرفته شده و
از "$GIT_COMMON_DIR/info"
استفاده
خواهد شد.
info/refs
این فایل
به
پروتکل‌های
انتقال
ساده کمک
می‌کند تا
ارجاعات
موجود در
این مخزن را
کشف کنند.
اگر مخزن
برای
پروتکل‌های
ساده منتشر
شده باشد،
این فایل
باید هر بار
که یک تگ یا
شاخه ایجاد
یا اصلاح
می‌شود،
توسط git update-server-info
مجدداً
تولید شود.
این کار
معمولاً از
طریق هوک hooks/update
انجام
می‌شود، که
هنگام
اجرای
دستور git push به
درون مخزن،
توسط دستور
git-receive-pack
فراخوانی
می‌گردد.
info/grafts
این فایل
اطلاعات
نسب جعلی
کامیت را
ثبت
می‌کند، تا
وانمود کند
مجموعه
والدین یک
کامیت با
نحوه ایجاد
واقعی
کامیت
متفاوت است.
هر رکورد در
یک خط، یک
کامیت و
والدین
جعلی آن را
با فهرست
کردن
نام‌های
اشیاء
هگزادسیمال
۴۰ بایتی
آن‌ها که با
یک فاصله
جدا شده و با
یک خط جدید
خاتمه
یافته‌اند
توصیف
می‌کند.
توجه
داشته
باشید که
سازوکار grafts
منسوخ شده و
می‌تواند
منجر به
بروز
مشکلاتی در
انتقال
اشیاء میان
مخازن شود؛
برای
سیستمی
انعطاف‌پذیرتر
و قوی‌تر
جهت انجام
همین کار به
git-replace(1) مراجعه
کنید.
info/exclude
این فایل
بر طبق
قرارداد
میان
ابزارهای
سطح بالا،
لیست
الگوهای
نادیده‌گیری
(exclude) را ذخیره
می‌کند.
فایل
.gitignore
فایل
نادیده‌گیری
به ازای هر
دایرکتوری
است.
دستورات
git
status،
git add،
git rm و
git
clean به آن نگاه
می‌کنند
اما
دستورات
هسته‌ای
گیت آن را
بررسی
نمی‌کنند.
همچنین
ببینید:
gitignore(5).
info/attributes
مشخص
می‌کند چه
مشخصه‌هایی
(attributes) به یک
مسیر
اختصاص
داده شود،
مشابه
فایلهای
.gitattributes به ازای
هر
دایرکتوری.
همچنین
ببینید:
gitattributes(5).
info/sparse-checkout
این فایل
الگوهای
بررسی
کم‌پشت (sparse checkout)
را ذخیره
می‌کند.
همچنین
ببینید:
git-read-tree(1).
remotes
نام‌های
کوتاه برای URL
و نام‌های
پیش‌فرض
ارجاع را
برای
استفاده
هنگام
تعامل با
مخازن راه
دور از طریق
دستورات
git
fetch،
git pull و
git push
ذخیره
می‌کند.
برای
جزئیات بخش
REMOTES در
git-fetch(1) را
ببینید. این
سازوکار
قدیمی است و
بعید است در
مخازن جدید
یافت شود.
اگر $GIT_COMMON_DIR
تنظیم شده
باشد این
دایرکتوری
نادیده
گرفته شده و
از "
$GIT_COMMON_DIR/remotes"
استفاده
خواهد شد.
گیت در
نسخه Git 3.0
خواندن
مخازن راه
دور از این
دایرکتوری
را متوقف
خواهد کرد.
logs
سوابق
تغییرات
ایجادشده
در ارجاعات
در این
دایرکتوری
ذخیره
می‌شوند.
برای
اطلاعات
بیشتر به
git-update-ref(1) مراجعه
کنید. اگر
متغیر $GIT_COMMON_DIR
تنظیم شده
باشد، این
دایرکتوری
(به جز logs/HEAD)
نادیده
گرفته شده و
از "
$GIT_COMMON_DIR/logs"
استفاده
خواهد شد.
logs/refs/heads/name
تمامی
تغییرات
ایجادشده
در نوک شاخه
به نام name را
ثبت
می‌کند.
logs/refs/tags/name
تمامی
تغییرات
ایجادشده
در برچسب به
نام name را ثبت
می‌کند.
shallow
این شبیه
به
info/grafts است
اما به صورت
داخلی توسط
سازوکار
کلون
کم‌عمق (shallow clone)
استفاده و
نگهداری
می‌شود.
گزینه
--depth در
git-clone(1) و
git-fetch(1) را
ببینید. اگر
متغیر $GIT_COMMON_DIR
تنظیم شده
باشد این
فایل
نادیده
گرفته شده و
از "
$GIT_COMMON_DIR/shallow"
استفاده
می‌شود.
commondir
اگر این
فایل وجود
داشته
باشد،
متغیر $GIT_COMMON_DIR (به
git(1) مراجعه
کنید) در
صورتی که
صراحتاً
تعیین نشده
باشد،
برابر با
مسیر
مشخص‌شده
در این فایل
قرار خواهد
گرفت. اگر
مسیر
مشخص‌شده
نسبی باشد،
نسبت به $GIT_DIR
سنجیده
می‌شود.
مخزن دارای
commondir بدون
مخزنی که
توسط "commondir" به
آن اشاره
شده است
ناقص خواهد
بود.
modules
شامل
مخازن گیت
مربوط به
زیرماژول‌ها
است.
worktrees
حاوی
داده‌های
مدیریتی
برای
درخت‌های
کاری
پیوندداده‌شده
است. هر
زیرشاخه
حاوی بخش
مرتبط با
درخت کاری
یک درخت
کاری
پیوندداده‌شده
است. اگر
متغیر $GIT_COMMON_DIR
تنظیم شده
باشد این
دایرکتوری
نادیده
گرفته شده و
در این حالت
از "$GIT_COMMON_DIR/worktrees"
استفاده
خواهد شد.
worktrees/<id>/gitdir
یک فایل
متنی حاوی
مسیر مطلق
بازگشتی به
فایل .git که به
اینجا
اشاره
می‌کند. این
فایل برای
بررسی این
موضوع
استفاده
می‌شود که
آیا مخزن
پیوندداده‌شده
به صورت
دستی حذف
شده و دیگر
نیازی به
نگهداری
این
دایرکتوری
نیست یا خیر.
زمان تغییر
(mtime) این فایل
باید با هر
بار دسترسی
به مخزن
پیوندداده‌شده
به‌روزرسانی
شود.
worktrees/<id>/locked
اگر این
فایل وجود
داشته
باشد، ممکن
است درخت
کاری
پیوندداده‌شده
روی یک
دستگاه
قابل حمل
باشد و در
دسترس
نباشد. وجود
این فایل
مانع از آن
می‌شود که
worktrees/<id> به
صورت
خودکار یا
دستی توسط git
worktree prune
پاکسازی (prune)
شود. این
فایل ممکن
است حاوی
رشته‌ای
باشد که
دلیل قفل
بودن مخزن
را توضیح
می‌دهد.
worktrees/<id>/config.worktree
فایل
پیکربندی
اختصاصی
دایرکتوری
کاری.
هر مخزن
گیت با یک
نسخه عددی
در کلید
core.repositoryformatversion از
فایل config خود
مشخص
می‌شود. این
نسخه قواعد
مربوط به
کار روی
داده‌های
مخزن روی
دیسک را
مشخص
می‌کند. هر
پیاده‌سازی
گیت که نسخه
خاص
اعلام‌شده
توسط یک
مخزن روی
دیسک را درک
نکند،
نباید روی
آن مخزن
عملیاتی
انجام دهد؛
انجام چنین
کاری
نه‌تنها
خطر تولید
نتایج
نادرست را
به همراه
دارد، بلکه
عملاً ممکن
است موجب از
دست رفتن
داده‌ها
شود.
به دلیل
این قاعده،
ارتقای
نسخه باید
در کمترین
حد مطلق نگه
داشته شود.
در عوض، ما
معمولاً
این
راهبردها
را ترجیح
می‌دهیم:
•ارتقای
شماره نسخه
قالب
فایلهای
داده‌ای
منفرد
(مانند index،
فایلهای pack و
غیره). این
کار
ناسازگاری‌ها
را تنها به
همان
فایل‌ها
محدود
می‌کند.
•معرفی
داده‌های
جدیدی که
هنگام
استفاده
توسط
کلاینت‌های
قدیمی‌تر
به زیبایی
تنزل
می‌یابند
(به عنوان
مثال،
فایلهای
نقشه بیتی pack
توسط
کلاینت‌های
قدیمی
نادیده
گرفته
می‌شوند، و
آن‌ها
صرفاً از
بهینه‌سازی
ارائه‌شده
توسط این
فایل‌ها
بهره‌مند
نمی‌شوند).
ارتقای
نسخه قالب
کل مخزن
باید تنها
بخشی از
تغییری
باشد که
نتوان آن را
به صورت
مستقل
نسخه‌بندی
کرد. به
عنوان
مثال، اگر
کسی بخواهد
قواعد
دسترسی‌پذیری
اشیاء یا
قواعد قفل
کردن
ارجاعات را
تغییر دهد،
این امر
نیازمند
ارتقای
نسخه قالب
مخزن خواهد
بود.
توجه
داشته
باشید که
این موضوع
تنها در
مورد
دسترسی
مستقیم به
محتویات
دیسک مخزن
صدق می‌کند.
یک کلاینت
قدیمی‌تر
که تنها
فرمت 0 را
می‌فهمد
همچنان
می‌تواند
از طریق git://
به مخزنی
متصل شود که
از فرمت 1
استفاده
می‌کند، تا
زمانی که
فرآیند
سرور فرمت 1
را درک کند.
راهبرد
ارجح برای
عرضه یک
ارتقای
نسخه (چه
برای کل
مخزن و چه
برای یک
فایل منفرد)
این است که
خواندن
قالب جدید
به گیت
آموزش داده
شود، و
نوشتن قالب
جدید با یک
سوییچ
پیکربندی
یا گزینه خط
فرمان مجاز
گردد (برای
آزمایش یا
برای کسانی
که اهمیتی
به سازگاری
عقبرو با
نسخه‌های
قدیمی‌تر
گیت
نمی‌دهند).
سپس پس از یک
دوره
طولانی که
اجازه
می‌دهد
قابلیت
خواندن
همه‌گیر
شود،
می‌توان
نوشتن قالب
جدید را به
حالت
پیش‌فرض
تبدیل کرد.
نسخه‌های
قالب فعلی
تعریف‌شده
عبارتند
از:
این قالبی
است که توسط
نسخه اولیه
گیت تعریف
شده است، از
جمله شامل
(اما نه
محدود به)
قالب
دایرکتوری
مخزن، فایل
پیکربندی
مخزن، و
ذخیره‌سازی
اشیاء و
ارجاعات.
تشریح
رفتار کامل
گیت فراتر
از محدوده
این سند
است.
این قالب
با نسخه 0
یکسان است،
به استثنای
موارد زیر:
1.هنگام
خواندن
متغیر
core.repositoryformatversion، یک
پیاده‌سازی
گیت که از
نسخه ۱
پشتیبانی
می‌کند
باید تمام
کلیدهای
پیکربندی
موجود در
بخش extensions از
فایل
پیکربندی
را نیز
بخواند.
2.اگر یک
مخزن نسخه ۱
هر کلیدی از
extensions.* را مشخص
کرده باشد
که گیت در
حال اجرا آن
را
پیاده‌سازی
نکرده است،
عملیات
نباید
ادامه یابد.
به همین
ترتیب، اگر
مقدار هر
کلید
شناخته‌شده‌ای
توسط
پیاده‌سازی
درک نشود،
عملیات
نباید
ادامه
یابد.
توجه
داشته
باشید که
اگر هیچ
افزونه‌ای
در فایل
پیکربندی
مشخص نشده
باشد،
آنگاه core.repositoryformatversion
باید روی 0
تنظیم شود
(تنظیم آن
روی 1 هیچ
مزیتی
ندارد و
مخزن را با
پیاده‌سازی‌های
قدیمی‌تر
گیت
ناسازگار
می‌کند).
افزونه‌های
تعریف‌شده
در بخش extensions.*
از git-config(1)
آورده
شده‌اند. هر
پیاده‌سازی
که مایل به
تعریف یک
افزونه
جدید باشد
باید
یادداشتی
از آن در
آنجا
بگذارد تا
نام را به
خود اختصاص
دهد.
