GIT-REV-PARSE(1) Git Manual GIT-REV-PARSE(1)

git-rev-parse - تجزیه و اعتبارسنجی پارامترها و مشخصات ارجاع

git rev-parse [<options>] <arg>...

بسیاری از دستورات سطح بالای (porcelain) گیت ترکیبی از فلگ‌ها (یعنی پارامترهایی که با خط تیره - شروع می‌شوند) و پارامترهای مختص دستور زیربنایی git rev-list که در داخل استفاده می‌کنند، و همچنین فلگ‌ها و پارامترهایی برای سایر دستوراتی که در مراحل بعدی از git rev-list استفاده می‌کنند را دریافت می‌کنند. هدف اصلی این دستور آن است که به برنامه‌های فراخواننده اجازه دهد بین آن‌ها تمایز قائل شوند. چند حالت عملیاتی دیگر نیز وجود دارند که ارتباطی با این موضوع "کمک به تجزیه گزینه‌های خط فرمان" ندارند.

مگر در مواردی که مشخص شده باشد، بیشتر گزینه‌ها و حالت‌های عملیاتی مستلزم اجرای این دستور در داخل یک مخزن گیت یا یک درخت کاری تحت کنترل یک مخزن گیت هستند، و در غیر این صورت یک خطای مهلک (fatal error) نمایش خواهند داد.

هر یک از این گزینه‌ها باید در ابتدای خط فرمان ظاهر شوند.

--parseopt

استفاده از git rev-parse در حالت تجزیه گزینه‌ها (بخش «تجزیه گزینه‌ها (PARSEOPT)» در ادامه را ببینید). این دستور در این حالت می‌تواند خارج از یک مخزن یا درخت کاری تحت کنترل یک مخزن استفاده شود.

--sq-quote

استفاده از git rev-parse در حالت نقل‌قول شل (بخش «نقل‌قول شل (SQ-QUOTE)» در ادامه را ببینید). برخلاف گزینه --sq در زیر، این حالت فقط نقل‌قول‌گذاری را انجام می‌دهد. هیچ کار دیگری روی ورودی دستور انجام نمی‌شود. این دستور در این حالت می‌تواند خارج از یک مخزن یا درخت کاری تحت کنترل یک مخزن استفاده شود.

--keep-dashdash

فقط در حالت --parseopt معنا دارد. به تجزیه‌کننده گزینه‌ها می‌گوید اولین -- مشاهده‌شده را به جای نادیده گرفتن، بازتاب (echo) دهد.

--stop-at-non-option

فقط در حالت --parseopt معنا دارد. به تجزیه‌کننده گزینه‌ها اجازه می‌دهد در اولین آرگومان غیرگزینه‌ای متوقف شود. از این مورد می‌توان برای تجزیه زیردستوراتی که خودشان گزینه دریافت می‌کنند استفاده کرد.

--stuck-long

فقط در حالت --parseopt معنا دارد. گزینه‌ها را در صورت وجود در قالب بلند آن‌ها و به همراه آرگومان‌های چسبیده به آن‌ها خروجی می‌دهد.

--revs-only

فلگ‌ها و پارامترهایی که برای دستور git rev-list در نظر گرفته نشده‌اند را خروجی ندهد.

--no-revs

فلگ‌ها و پارامترهایی که برای دستور git rev-list در نظر گرفته شده‌اند را خروجی ندهد.

--flags

پارامترهای غیرفلگ را خروجی ندهد.

--no-flags

پارامترهای فلگ را خروجی ندهد.

--default <arg>

اگر هیچ پارامتری توسط کاربر مشخص نشده باشد، به جای آن از <arg> استفاده کند.

--prefix <arg>

به گونه‌ای رفتار کند که گویی git rev-parse از زیردایرکتوری <arg> درخت کاری فراخوانی شده است. هر نام فایل نسبی به گونه‌ای حل می‌شود که گویی پیشوند <arg> دارد و به همان شکل چاپ خواهد شد.

از این مورد می‌توان برای تبدیل آرگومان‌های یک دستور اجرا شده در یک زیردایرکتوری استفاده کرد تا پس از انتقال به سطح بالای مخزن همچنان قابل استفاده باشند. به عنوان مثال:

prefix=$(git rev-parse --show-prefix)
cd "$(git rev-parse --show-toplevel)"
# rev-parse provides the -- needed for 'set'
eval "set $(git rev-parse --sq --prefix "$prefix" -- "$@")"

--verify

بررسی می‌کند که دقیقاً یک پارامتر داده شده باشد و بتوان آن را به یک SHA-1 خام ۲۰ بایتی تبدیل کرد که بتوان از آن برای دسترسی به پایگاه داده اشیاء استفاده نمود. در این صورت، آن را در خروجی استاندارد چاپ می‌کند؛ در غیر این صورت، خطا می‌دهد.

اگر می‌خواهید مطمئن شوید که خروجی واقعاً نام یک شیء در پایگاه داده اشیاء شما است و/یا می‌تواند به عنوان یک نوع شیء خاص که نیاز دارید استفاده شود، می‌توانید عملگر جداسازی (peeling) به شکل ^{type} را به پارامتر اضافه کنید. به عنوان مثال، git rev-parse "$VAR^{commit}" اطمینان حاصل می‌کند که $VAR نام یک شیء موجود است که از نوع شبه‌کامیت (commit-ish) باشد (یعنی یک کامیت یا یک برچسب یادداشت‌دار که به یک کامیت اشاره دارد). برای اطمینان از این‌که $VAR نام یک شیء موجود از هر نوعی است، می‌توان از git rev-parse "$VAR^{object}" استفاده کرد.

توجه داشته باشید که اگر نامی را از یک منبع نامعتبر اعتبارسنجی می‌کنید، بهتر است از --end-of-options استفاده کنید تا آرگومان نام با یک گزینه دیگر اشتباه گرفته نشود.

-q, --quiet

تنها در حالت --verify دارای معنا است. در صورتی که اولین آرگومان یک نام شیء معتبر نباشد، پیام خطایی نمایش ندهد؛ بلکه در سکوت با وضعیت غیرصفر خارج شود. مقادیر SHA-1 برای نام‌های معتبر اشیاء در صورت موفقیت در خروجی استاندارد (stdout) چاپ می‌شوند.

--sq

معمولاً خروجی به ازای هر فلگ و پارامتر در یک خط جداگانه نمایش داده می‌شود. این گزینه خروجی را در یک خط واحد و با نقل‌قول‌گذاری مناسب جهت مصرف در شل قالب‌بندی می‌کند. زمانی که انتظار دارید پارامتر شما شامل فاصله‌ها و خطوط جدید باشد مفید است (برای مثال هنگام استفاده از pickaxe به شکل -S با git diff-*). برخلاف گزینه --sq-quote، ورودی دستور همچنان طبق روال معمول تفسیر می‌شود.

--short[=<length>]

همانند --verify عمل می‌کند اما نام شیء را به یک پیشوند یکتا با حداقل length نویسه کوتاه می‌کند. حداقل طول ۴ است و مقدار پیش‌فرض آن مقدار مؤثر متغیر پیکربندی core.abbrev می‌باشد (به git-config(1) مراجعه کنید).

--not

هنگام نمایش نام اشیاء، پیشوند ^ را به آن‌ها اضافه کند و پیشوند ^ را از نام اشیائی که قبلاً آن را دارند حذف نماید.

--abbrev-ref[=(strict|loose)]

یک نام کوتاه غیرمبهم از نام اشیاء ارائه می‌دهد. گزینه core.warnAmbiguousRefs برای انتخاب حالت مخفف‌سازی دقیق (strict) استفاده می‌شود.

--symbolic

معمولاً نام‌های اشیاء در قالب SHA-1 (با پیشوند احتمالی ^) خروجی داده می‌شوند؛ این گزینه باعث می‌شود آن‌ها در قالبی تا حد امکان نزدیک به ورودی اولیه خروجی داده شوند.

--symbolic-full-name

این گزینه مشابه --symbolic است، اما ورودی‌هایی که ارجاع (ref) نیستند را نادیده می‌گیرد (یعنی نام شاخه‌ها یا برچسب‌ها؛ یا به طور صریح‌تر قالب تمایزبخش "heads/master" زمانی که می‌خواهید شاخه "master" را مشخص کنید در حالی که متأسفانه یک برچسب با نام "master" نیز وجود دارد) و آن‌ها را به صورت نام کامل ارجاع نمایش می‌دهد (مانند "refs/heads/master").

--output-object-format=(sha1|sha256|storage)

اجازه می‌دهد شناسه‌های اشیاء (oid) از هر قالب شیئی که مخزن فعلی پشتیبانی می‌کند وارد شوند.

مشخص کردن "sha1" در صورت لزوم تبدیل را انجام داده و یک oid از نوع sha1 برمی‌گرداند.

مشخص کردن "sha256" در صورت لزوم تبدیل را انجام داده و یک oid از نوع sha256 برمی‌گرداند.

مشخص کردن "storage" در صورت لزوم تبدیل را انجام داده و یک oid کدگذاری‌شده در الگوریتم هش فضای ذخیره‌سازی را برمی‌گرداند.

--all

نمایش تمام ارجاعات یافت‌شده در refs/.

--branches[=<pattern>], --tags[=<pattern>], --remotes[=<pattern>]

به ترتیب نمایش تمام شاخه‌ها، برچسب‌ها، یا شاخه‌های ردیابی ریموت (یعنی ارجاعات موجود در refs/heads، refs/tags یا refs/remotes).

اگر یک pattern مشخص شده باشد، فقط ارجاعاتی که با تطبیق شل گلوب (shell glob) داده شده مطابقت دارند نمایش داده می‌شوند. اگر الگو شامل نویسه‌های گلوبینگ (?, *، یا [) نباشد، با افزودن /* به یک تطبیق پیشوندی تبدیل می‌شود.

--glob=<pattern>

نمایش تمام ارجاعاتی که با الگوی گلوب شل pattern مطابقت دارند. اگر الگو با refs/ شروع نشود، این عبارت به صورت خودکار به ابتدای آن اضافه می‌شود. اگر الگو شامل نویسه‌های گلوبینگ (?, *، یا [) نباشد، با افزودن /* به یک تطبیق پیشوندی تبدیل می‌شود.

--exclude=<glob-pattern>

ارجاعاتی را که با <glob-pattern> مطابقت دارند و گزینه‌های بعدی --all، --branches، --tags، --remotes یا --glob در غیر این صورت در نظر می‌گرفتند، لحاظ نکند. تکرار این گزینه الگوهای استثنا را تا گزینه بعدی --all، --branches، --tags، --remotes یا --glob انباشته می‌کند (سایر گزینه‌ها یا آرگومان‌ها الگوهای انباشته‌شده را پاک نمی‌کنند).

الگوهای داده شده هنگام اعمال بر روی --branches، --tags یا --remotes نباید با refs/heads، refs/tags یا refs/remotes شروع شوند و هنگام اعمال بر روی --glob یا --all باید با refs/ شروع شوند. اگر یک /* پایانی مد نظر باشد، باید به صراحت قید گردد.

--exclude-hidden=(fetch|receive|uploadpack)

ارجاعاتی را که توسط git-fetch، git-receive-pack یا git-upload-pack با مراجعه به تنظیمات مربوطه fetch.hideRefs، receive.hideRefs یا uploadpack.hideRefs به همراه transfer.hideRefs پنهان می‌شوند (به git-config(1) مراجعه کنید) شامل نکند. این گزینه بر گزینه شبه‌ارجاع بعدی --all یا --glob تأثیر می‌گذارد و پس از پردازش آن‌ها پاک می‌شود.

--disambiguate=<prefix>

هر شیئی را که نام آن با پیشوند داده شده شروع می‌شود نمایش دهد. پیشوند <prefix> باید حداقل ۴ رقم هگزادسیمال طول داشته باشد تا از فهرست شدن تصادفی تک‌تک اشیاء در مخزن جلوگیری شود.

--local-env-vars

متغیرهای محیطی GIT_* که محلی برای مخزن هستند را فهرست می‌کند (مانند GIT_DIR یا GIT_WORK_TREE، اما نه GIT_EDITOR). تنها نام متغیرها فهرست می‌شوند، نه مقدار آن‌ها، حتی اگر مقداردهی شده باشند.

--path-format=(absolute|relative)

رفتار برخی گزینه‌های دیگر را کنترل می‌کند. اگر به صورت absolute مشخص شود، مسیرهای چاپ‌شده توسط آن گزینه‌ها مطلق و استاندارد (canonical) خواهند بود. اگر به صورت relative مشخص شود، در صورت امکان مسیرها نسبت به دایرکتوری کاری فعلی خواهند بود. مقدار پیش‌فرض بستگی به هر گزینه دارد.

این گزینه می‌تواند چندین بار مشخص شود و فقط روی آرگومان‌هایی که پس از آن در خط فرمان می‌آیند تأثیر می‌گذارد؛ یا تا انتهای خط فرمان یا تا نمونه بعدی این گزینه.

گزینه‌های زیر توسط --path-format تغییر می‌یابند:

--git-dir

نمایش $GIT_DIR در صورت تعریف شدن. در غیر این صورت، مسیر دایرکتوری .git را نمایش می‌دهد. مسیر نمایش‌داده‌شده، در صورت نسبی بودن، نسبت به دایرکتوری کاری فعلی است.

اگر $GIT_DIR تعریف نشده باشد و تشخیص داده نشود که دایرکتوری فعلی درون یک مخزن یا درخت کاری گیت قرار دارد، پیامی در stderr چاپ کرده و با وضعیت غیرصفر خارج می‌شود.

--git-common-dir

نمایش $GIT_COMMON_DIR در صورت تعریف شدن، در غیر این صورت $GIT_DIR.

--resolve-git-dir <path>

بررسی می‌کند که آیا <path> یک مخزن معتبر است یا یک gitfile که به یک مخزن معتبر اشاره دارد، و مکان مخزن را چاپ می‌کند. اگر <path> یک gitfile باشد، مسیر حل‌شده به مخزن واقعی چاپ می‌شود.

--git-path <path>

مسیر "$GIT_DIR/<path>" را حل می‌کند و سایر متغیرهای جابه‌جایی مسیر مانند $GIT_OBJECT_DIRECTORY، $GIT_INDEX_FILE و... را در نظر می‌گیرد. به عنوان مثال، اگر $GIT_OBJECT_DIRECTORY روی /foo/bar تنظیم شده باشد، دستور "git rev-parse --git-path objects/abc"; مقدار /foo/bar/abc را برمی‌گرداند.

--show-toplevel

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

--show-superproject-working-tree

نمایش مسیر مطلق ریشه درخت کاری پروژه مادر (superproject) در صورت وجود، که از مخزن فعلی به عنوان زیرماژول (submodule) خود استفاده می‌کند. اگر مخزن فعلی به عنوان زیرماژول توسط هیچ پروژه‌ای استفاده نشود، چیزی خروجی نمی‌دهد.

--shared-index-path

نمایش مسیر فایل نمایه مشترک (shared index) در حالت نمایه تفکیک‌شده (split index)، یا در صورت نبودن در حالت split-index، خروجی خالی است.

گزینه‌های زیر تحت تأثیر --path-format قرار نمی‌گیرند:

--absolute-git-dir

مانند --git-dir عمل می‌کند، اما خروجی آن همیشه مسیر مطلق متعارف است.

--is-inside-git-dir

هنگامی که دایرکتوری کاری فعلی زیر دایرکتوری مخزن باشد عبارت "true" را چاپ می‌کند، در غیر این صورت "false".

--is-inside-work-tree

هنگامی که دایرکتوری کاری فعلی داخل درخت کاری مخزن باشد عبارت "true" را چاپ می‌کند، در غیر این صورت "false".

--is-bare-repository

هنگامی که مخزن یک مخزن خالص (bare) باشد عبارت "true" را چاپ می‌کند، در غیر این صورت "false".

--is-shallow-repository

هنگامی که مخزن یک مخزن کم‌عمق (shallow) باشد عبارت "true" را چاپ می‌کند، در غیر این صورت "false".

--show-cdup

هنگامی که دستور از یک زیردایرکتوری فراخوانی می‌شود، مسیر دایرکتوری سطح بالا را نسبت به دایرکتوری فعلی نمایش می‌دهد (معمولاً توالی از "../"، یا یک رشته خالی).

--show-prefix

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

--show-object-format[=(storage|input|output|compat)]

قالب شیء (الگوریتم هش) مورد استفاده مخزن برای ذخیره‌سازی در دایرکتوری .git، ورودی، خروجی، یا سازگاری را نمایش می‌دهد. برای ورودی، ممکن است چندین الگوریتم که با فاصله از هم جدا شده‌اند چاپ شوند. اگر compat درخواست شود و هیچ الگوریتم سازگاری فعال نباشد، یک خط خالی چاپ می‌کند. در صورت عدم تعیین، مقدار پیش‌فرض "storage" است.

--show-ref-format

قالب ذخیره‌سازی ارجاعات مورد استفاده برای مخزن را نمایش می‌دهد.

--since=<datestring>, --after=<datestring>

رشته تاریخ را تجزیه کرده و پارامتر متناظر --max-age= را برای git rev-list خروجی می‌دهد.

--until=<datestring>, --before=<datestring>

رشته تاریخ را تجزیه کرده و پارامتر متناظر --min-age= را برای git rev-list خروجی می‌دهد.

<arg>...

فلگ‌ها و پارامترهایی که باید تجزیه شوند.

یک پارامتر بازبینی (revision) به نام <rev> معمولاً، اما نه لزوماً، نام یک شیء کامیت را مشخص می‌کند. این پارامتر از ساختاری موسوم به نحو SHA-1 گسترش‌یافته استفاده می‌کند. در این‌جا روش‌های گوناگونی برای نگارش نام اشیاء آمده است. مواردی که در نزدیکی انتهای این فهرست ذکر شده‌اند، نام درخت‌ها و blobهای موجود در یک کامیت را مشخص می‌کنند.


یادداشت

این سند نحو "خام" (raw) را همان‌گونه که توسط گیت دیده می‌شود نشان می‌دهد. شل و سایر واسط‌های کاربری ممکن است برای محافظت از نویسه‌های خاص و جلوگیری از تفکیک کلمات، به نقل‌قول‌گذاری اضافی نیاز داشته باشند.

<sha1>, e.g. dae86e1950b1277e545cee180551750029cfe735, dae86e

نام کامل شیء SHA-1 (رشته هگزادسیمال ۴۰ بایتی)، یا یک زیررشته آغازین که در مخزن یکتا باشد. برای مثال dae86e1950b1277e545cee180551750029cfe735 و dae86e هر دو به یک شیء کامیت اشاره دارند اگر شیء دیگری در مخزن شما وجود نداشته باشد که نام آن با dae86e شروع شود.

<describeOutput>, e.g. v1.7.4.2-679-g3bee7fb

خروجی حاصل از git describe؛ یعنی نزدیک‌ترین برچسب، که اختیاری به دنبال آن یک خط تیره و تعدادی کامیت می‌آید، و سپس یک خط تیره، یک g، و نام شیء به صورت مخفف قرار دارد.

<refname>, e.g. master, heads/master, refs/heads/master

یک نام ارجاع نمادین. برای مثال master معمولاً به معنای شیء کامیت ارجاع داده شده توسط refs/heads/master است. اگر اتفاقاً هر دو مورد heads/master و tags/master را داشته باشید، می‌توانید صراحتاً heads/master را قید کنید تا به گیت بگویید منظور شما کدام است. در صورت وجود ابهام، ابهام‌زدایی از یک <refname> با انتخاب اولین تطبیق در قواعد زیر انجام می‌شود:
1.اگر $GIT_DIR/<refname> وجود داشته باشد، منظور شما همان است (این مورد معمولاً فقط برای HEAD، FETCH_HEAD، ORIG_HEAD، MERGE_HEAD، REBASE_HEAD، REVERT_HEAD، CHERRY_PICK_HEAD، BISECT_HEAD و AUTO_MERGE مفید است)؛
2.در غیر این صورت، refs/<refname> در صورت وجود؛
3.در غیر این صورت، refs/tags/<refname> در صورت وجود؛
4.در غیر این صورت، refs/heads/<refname> در صورت وجود؛
5.در غیر این صورت، refs/remotes/<refname> در صورت وجود؛
6.در غیر این صورت، refs/remotes/<refname>/HEAD در صورت وجود.

HEAD

کامیتی را مشخص می‌کند که تغییرات درخت کاری را بر پایه آن بنا نهاده‌اید.

FETCH_HEAD

شاخه‌ای را ثبت می‌کند که در آخرین فراخوانی git fetch از یک مخزن دوردست واکشی کرده‌اید.

ORIG_HEAD

توسط دستوراتی ایجاد می‌شود که HEAD شما را به شکل بنیادین تغییر می‌دهند (git am، git merge، git rebase، git reset)، تا موقعیت HEAD قبل از اجرای عملیات آن‌ها را ثبت کند، به طوری که بتوانید به راحتی نوک شاخه را به وضعیت قبل از اجرای آن‌ها بازگردانید.

MERGE_HEAD

کامیت(هایی) را ثبت می‌کند که هنگام اجرای git merge در حال ادغام آن‌ها در شاخه خود هستید.

REBASE_HEAD

در حین بازنویسی تاریخچه (rebase)، کامیتی را ثبت می‌کند که عملیات در حال حاضر در آن متوقف شده است، خواه به دلیل تعارض‌ها و خواه به دلیل دستور edit در یک ریبیس تعاملی.

REVERT_HEAD

کامیتی را ثبت می‌کند که هنگام اجرای git revert در حال برگرداندن آن هستید.

CHERRY_PICK_HEAD

کامیتی را ثبت می‌کند که هنگام اجرای git cherry-pick در حال گلچین کردن آن هستید.

BISECT_HEAD

کامیت فعلی را ثبت می‌کند که هنگام اجرای git bisect --no-checkout باید مورد آزمایش قرار گیرد.

AUTO_MERGE

یک شیء درخت متناظر با وضعیتی را ثبت می‌کند که استراتژی ادغام ort هنگام مواجهه عملیات ادغام با تعارض‌ها، در درخت کاری نوشته است.

توجه داشته باشید که هر یک از موارد refs/* بالا ممکن است از دایرکتوری $GIT_DIR/refs یا از فایل $GIT_DIR/packed-refs بیایند. با وجودی که کدگذاری نام ارجاع تعیین‌نشده است، UTF-8 ترجیح داده می‌شود زیرا برخی از پردازش‌های خروجی ممکن است نام ارجاعات را به صورت UTF-8 فرض کنند.

@

@ به تنهایی میانبری برای HEAD است.

[<refname>]@{<date>}, e.g. master@{yesterday}, HEAD@{5 minutes ago}

یک ارجاع که به دنبال آن پسوند @ به همراه یک مشخصه تاریخ محصور در یک جفت آکولاد (مانند {yesterday}، {1 month 2 weeks 3 days 1 hour 1 second ago} یا {1979-02-26 18:30:00}) می‌آید، مقدار ارجاع را در یک نقطه زمانی پیشین مشخص می‌کند. این پسوند تنها می‌تواند بلافاصله پس از یک نام ارجاع استفاده شود و ارجاع باید لاگ موجود داشته باشد ($GIT_DIR/logs/<ref>). توجه داشته باشید که این مورد وضعیت ارجاع محلی شما را در یک زمان مشخص جستجو می‌کند؛ برای مثال، آنچه که در شاخه محلی master شما در هفته گذشته وجود داشته است. اگر می‌خواهید کامیت‌های انجام‌شده در زمان‌های خاصی را مشاهده کنید، گزینه‌های --since و --until را ببینید.

<refname>@{<n>}, e.g. master@{1}

یک ارجاع که به دنبال آن پسوند @ به همراه یک مشخصه ترتیبی محصور در یک جفت آکولاد (مانند {1}، {15}) می‌آید، n-امین مقدار پیشین آن ارجاع را مشخص می‌کند. برای مثال master@{1} مقدار بلافاصله قبل از master است، در حالی که master@{5} مقدار پنجمین مرتبه پیشین master است. این پسوند تنها می‌تواند بلافاصله پس از یک نام ارجاع استفاده شود و ارجاع باید لاگ موجود داشته باشد ($GIT_DIR/logs/<refname>).

@{<n>}, e.g. @{1}

می‌توانید از ساختار @ با بخش ارجاع خالی برای دستیابی به یک مدخل reflog از شاخه فعلی استفاده کنید. برای مثال، اگر در شاخه blabla هستید، @{1} همان معنای blabla@{1} را دارد.

@{-<n>}, e.g. @{-1}

ساختار @{-<n>} به معنای <n>-امین شاخه/کامیتی است که پیش از شاخه/کامیت فعلی checkout شده است.

[<branchname>]@{upstream}, e.g. master@{upstream}, @{u}

یک شاخه B ممکن است طوری تنظیم شده باشد که بر روی یک شاخه X (پیکربندی‌شده با branch.<name>.merge) در یک مخزن دوردست R (پیکربندی‌شده با شاخه X برگرفته از مخزن دوردست R، که معمولاً در refs/remotes/R/X یافت می‌شود) ساخته شود.

[<branchname>]@{push}, e.g. master@{push}, @{push}

پسوند @{push} شاخه‌ای را گزارش می‌دهد که اگر در زمان فعال بودن branchname (یا HEAD فعلی در صورتی که هیچ نام شاخه‌ای مشخص نشده باشد) دستور git push اجرا می‌شد، «به آن‌جا پوش می‌کردیم». همانند @{upstream}، ما شاخه ردیابی ریموت متناظر با آن شاخه را در مخزن دوردست گزارش می‌دهیم.

در این‌جا مثالی برای شفاف‌تر شدن موضوع آمده است:

$ git config push.default current
$ git config remote.pushdefault myfork
$ git switch -c mybranch origin/master
$ git rev-parse --symbolic-full-name @{upstream}
refs/remotes/origin/master
$ git rev-parse --symbolic-full-name @{push}
refs/remotes/myfork/mybranch

توجه داشته باشید که در این مثال یک جریان کاری مثلثی (triangular workflow) تنظیم کرده‌ایم، که در آن از یک مکان pull می‌کنیم و به مکان دیگری push می‌نماییم. در یک جریان کاری غیرمثلثی، @{push} همانند @{upstream} است و نیازی به آن نیست.

این پسوند با حروف بزرگ نیز پذیرفته می‌شود و صرف‌نظر از کوچک یا بزرگ بودن حروف، معنای یکسانی دارد.

<rev>^[<n>], e.g. HEAD^, v1.5.1^0

پسوند ^ برای یک پارامتر بازبینی، به معنای اولین والد آن شیء کامیت است. ^<n> به معنای <n>-امین والد است (یعنی <rev>^ معادل <rev>^1 است). به عنوان یک قاعده خاص، <rev>^0 به معنای خود کامیت است و زمانی استفاده می‌شود که <rev> نام شیء یک شیء برچسب باشد که به یک شیء کامیت اشاره دارد.

<rev>~[<n>], e.g. HEAD~, master~3

پسوند ~ برای یک پارامتر بازبینی به معنای اولین والد آن شیء کامیت است. پسوند ~<n> برای یک پارامتر بازبینی به معنای شیء کامیتی است که جد نسل <n>-ام شیء کامیت نام‌برده با دنبال کردن تنها والدین اول است. یعنی <rev>~3 معادل <rev>^^^ است که آن نیز معادل <rev>^1^1^1 می‌باشد. برای مشاهده نمایشی از کاربرد این قالب، بخش زیر را ببینید.

<rev>^{<type>}, e.g. v0.99.8^{commit}

پسوند ^ که به دنبال آن یک نام نوع شیء محصور در جفت آکولاد آمده است، به معنای بازگشایی ارجاع (dereference) شیء در <rev> به صورت بازگشتی است تا زمانی که شیئی از نوع <type> یافت شود یا دیگر نتوان ارجاع شیء را بازگشایی کرد (که در این حالت خطا می‌دهد). برای مثال، اگر <rev> یک commit-ish باشد، <rev>^{commit} شیء کامیت متناظر را توصیف می‌کند. به همین ترتیب، اگر <rev> یک tree-ish باشد، <rev>^{tree} شیء درخت متناظر را توصیف می‌کند. <rev>^0 حالت خلاصه <rev>^{commit} است.

از <rev>^{object} می‌توان برای اطمینان از این‌که <rev> نام شیئی موجود را مشخص می‌کند استفاده کرد، بدون این‌که نیازی باشد <rev> یک برچسب باشد و بدون بازگشایی ارجاع <rev>؛ زیرا یک برچسب از قبل خود یک شیء است، و حتی یک بار هم نیازی به بازگشایی ارجاع آن برای رسیدن به یک شیء وجود ندارد.

از <rev>^{tag} می‌توان برای اطمینان از این‌که <rev> یک شیء برچسب موجود را مشخص می‌کند استفاده نمود.

<rev>^{}, e.g. v0.99.8^{}

پسوند ^ که به دنبال آن یک جفت آکولاد خالی می‌آید به این معناست که شیء می‌تواند یک برچسب باشد، و برچسب را به صورت بازگشتی بازگشایی می‌کند تا زمانی که یک شیء غیربرچسب یافت شود.

<rev>^{/<text>}, e.g. HEAD^{/fix nasty bug}

پسوند ^ برای یک پارامتر بازبینی، که به دنبال آن یک جفت آکولاد حاوی متنی با پیشوند اسلش می‌آید، همانند نحو :/fix nasty bug در زیر است با این تفاوت که جوان‌ترین کامیت منطبق را که از <rev> قبل از ^ قابل دسترسی است برمی‌گرداند.

:/<text>, e.g. :/fix nasty bug

یک دونقطه، به دنبال آن یک اسلش، و به دنبال آن یک متن، کامیتی را مشخص می‌کند که پیام کامیت آن با عبارت باقاعده (regular expression) داده شده مطابقت دارد. این نام جوان‌ترین کامیت منطبق را برمی‌گرداند که از هر ارجاعی، از جمله HEAD، قابل دسترسی باشد. عبارت باقاعده می‌تواند با هر بخشی از پیام کامیت مطابقت داشته باشد. برای مطابقت با پیام‌هایی که با یک رشته خاص شروع می‌شوند، می‌توان برای مثال از :/^foo استفاده کرد. توالی خاص :/! برای تغییردهنده‌های آنچه که مطابقت داده می‌شود رزرو شده است. :/!-foo یک مطابقت منفی انجام می‌دهد، در حالی که :/!!foo با نویسه واقعی ! که به دنبال آن foo آمده مطابقت دارد. هر توالی دیگری که با :/! شروع شود فعلاً رزرو شده است. بسته به متن داده شده، قواعد تفکیک کلمات شل ممکن است به نقل‌قول‌گذاری اضافی نیاز داشته باشد.

<rev>:<path>, e.g. HEAD:README, master:./README

پسوند : به دنبال یک مسیر، نام blob یا درختی را در مسیر داده شده در شیء شبه‌درخت (tree-ish) مشخص‌شده توسط بخش قبل از دونقطه تعیین می‌کند. مسیری که با ./ یا ../ شروع می‌شود نسبت به دایرکتوری کاری فعلی است. مسیر داده شده طوری تبدیل می‌شود که نسبت به دایرکتوری ریشه درخت کاری باشد. این مورد بیش از همه برای آدرس‌دهی یک blob یا درخت از یک کامیت یا درختی که ساختار درختی مشابهی با درخت کاری دارد مفید است.

:[<n>:]<path>, e.g. :0:README, :README

یک دونقطه، اختیاری با یک شماره مرحله (stage number بین 0 تا 3) و یک دونقطه، که به دنبال آن یک مسیر می‌آید، نام یک شیء blob در نمایه (index) در مسیر داده شده را مشخص می‌کند. عدم وجود شماره مرحله (و دونقطه‌ای که به دنبال آن می‌آید) یک مدخل مرحله 0 را مشخص می‌کند. در طول یک ادغام، مرحله 1 نیای مشترک، مرحله 2 نسخه شاخه هدف (معمولاً شاخه فعلی)، و مرحله 3 نسخه‌ای از شاخه‌ای است که در حال ادغام شدن می‌باشد.

در این‌جا تصویری از جان لوئلیگر (Jon Loeliger) آمده است. هر دو گره کامیت B و C والدین گره کامیت A هستند. کامیت‌های والد از چپ به راست مرتب شده‌اند.

G   H   I   J
 \ /     \ /
  D   E   F
   \  |  / \
    \ | /   |
     \|/    |
      B     C
       \   /
        \ /
         A
A =      = A^0
B = A^   = A^1     = A~1
C =      = A^2
D = A^^  = A^1^1   = A~2
E = B^2  = A^^2
F = B^3  = A^^3
G = A^^^ = A^1^1^1 = A~3
H = D^2  = B^^2    = A^^^2  = A~2^2
I = F^   = B^3^    = A^^3^
J = F^2  = B^3^2   = A^^3^2

دستورات پیمایش تاریخچه مانند git log بر روی مجموعه‌ای از کامیت‌ها عمل می‌کنند، نه فقط یک کامیت منفرد.

برای این دستورات، مشخص کردن یک بازبینی منفرد، با استفاده از نشانه‌گذاری توصیف‌شده در بخش پیشین، به معنای مجموعه کامیت‌های قابل دسترسی (reachable) از کامیت داده شده است.

مشخص کردن چندین بازبینی به معنای مجموعه کامیت‌های قابل دسترسی از هر یک از کامیت‌های داده شده است.

مجموعه قابل دسترسی یک کامیت، خود کامیت و کامیت‌های موجود در زنجیره تبار (ancestry chain) آن است.

چندین نشانه‌گذاری برای مشخص کردن مجموعه‌ای از کامیت‌های مرتبط (که "محدوده بازبینی" یا revision range نامیده می‌شود) وجود دارد، که در ادامه نشان داده شده است.

نشانه‌گذاری ^<rev> (هشتک / caret)

برای مستثنی کردن کامیت‌های قابل دسترسی از یک کامیت، از نشانه‌گذاری پیشوند ^ استفاده می‌شود. برای مثال ^r1 r2 به معنای کامیت‌های قابل دسترسی از r2 به استثنای آن‌هایی است که از r1 قابل دسترسی هستند (یعنی r1 و نیاکان آن).

نشانه‌گذاری محدوده .. (دو نقطه)

عمل مجموعه‌ای ^r1 r2 آن‌چنان پرکاربرد است که یک حالت خلاصه برای آن وجود دارد. هنگامی که دو کامیت r1 و r2 را دارید (که بر اساس نحو توضیح داده شده در بخش «مشخص کردن ارجاعات (SPECIFYING REVISIONS)» در بالا نام‌گذاری شده‌اند)، می‌توانید کامیت‌هایی را که از r2 قابل دسترسی هستند به جز آن‌هایی که از r1 قابل دسترسی هستند با ^r1 r2 درخواست کنید و می‌توان آن را به شکل r1..r2 نوشت.

نشانه‌گذاری تفاضل متقارن ... (سه نقطه)

یک نشانه‌گذاری مشابه به شکل r1...r2 تفاضل متقارن (symmetric difference) بین r1 و r2 نامیده می‌شود و به صورت r1 r2 --not $(git merge-base --all r1 r2) تعریف می‌شود. این مجموعه شامل کامیت‌هایی است که از یکی از دو کامیت r1 (سمت چپ) یا r2 (سمت راست) قابل دسترسی هستند، اما نه از هر دوی آن‌ها.

در این دو نشانه‌گذاری مختصر، می‌توانید یک سر محدوده را حذف کنید تا به طور پیش‌فرض HEAD در نظر گرفته شود. برای مثال، origin.. حالت خلاصه origin..HEAD است و این سؤال را مطرح می‌کند که "از زمانی که از شاخه origin منشعب شده‌ام چه کارهایی انجام داده‌ام؟" به طور مشابه، ..origin حالت خلاصه HEAD..origin است و این سؤال را مطرح می‌کند که "مخزن origin از زمان انشعاب من چه کارهایی انجام داده است؟" توجه داشته باشید که .. به معنای HEAD..HEAD خواهد بود که یک محدوده خالی است که هم از HEAD قابل دسترسی و هم غیرقابل دسترسی است.

دستوراتی که به طور خاص برای دریافت دو محدوده متمایز طراحی شده‌اند (مانند "git range-diff R1 R2" برای مقایسه دو محدوده) وجود دارند، اما آن‌ها استثنا هستند. مگر در مواردی که خلاف آن قید شده باشد، تمام دستورات "git" که بر روی مجموعه‌ای از کامیت‌ها عمل می‌کنند، بر روی یک محدوده بازبینی منفرد کار می‌کنند. به عبارت دیگر، نوشتن دو "نشانه‌گذاری محدوده دو نقطه‌ای" در کنار یکدیگر، برای مثال:

$ git log A..B C..D

برای اکثر دستورات دو محدوده بازبینی را مشخص نمی‌کند. در عوض، یک مجموعه متصل منفرد از کامیت‌ها را مشخص می‌سازد، یعنی آن‌هایی که از B یا D قابل دسترسی هستند اما نه از A و نه از C قابل دسترسی نمی‌باشند. در یک تاریخچه خطی مانند زیر:

---A---B---o---o---C---D

از آن‌جا که A و B از C قابل دسترسی هستند، محدوده بازبینی مشخص‌شده توسط این دو محدوده نقطه‌ای یک کامیت منفرد D است.

سه حالت خلاصه دیگر وجود دارند که به ویژه برای کامیت‌های ادغام مفید هستند و برای نام‌گذاری مجموعه‌ای به کار می‌روند که توسط یک کامیت و کامیت‌های والد آن تشکیل می‌شود.

نشانه‌گذاری r1^@ به معنای تمام والدین r1 است.

نشانه‌گذاری r1^! شامل کامیت r1 است اما تمام والدین آن را مستثنی می‌کند. این نشانه‌گذاری به تنهایی کامیت منفرد r1 را نشان می‌دهد.

نشانه‌گذاری <rev>^-[<n>] شامل <rev> است اما والد <n>-ام را مستثنی می‌کند (یعنی خلاصه‌ای برای <rev>^<n>..<rev>)، که در صورت عدم قید، <n> = 1 خواهد بود. این مورد معمولاً برای کامیت‌های ادغام مفید است که در آن‌ها می‌توانید به سادگی <commit>^- را ارسال کنید تا تمام کامیت‌های موجود در شاخه‌ای را که در کامیت ادغام <commit> ادغام شده است (شامل خود <commit>) دریافت کنید.

در حالی که <rev>^<n> در مورد مشخص کردن یک والد کامیت منفرد بود، این سه نشانه‌گذاری والدین آن را نیز در نظر می‌گیرند. برای مثال می‌توانید بنویسید HEAD^2^@، اما نمی‌توانید بگویید HEAD^@^2.

<rev>

شامل کامیت‌هایی است که از <rev> قابل دسترسی هستند (یعنی <rev> و نیاکان آن).

^<rev>

مستثنی کردن کامیت‌هایی که از <rev> قابل دسترسی هستند (یعنی <rev> و نیاکان آن).

<rev1>..<rev2>

شامل کامیت‌هایی است که از <rev2> قابل دسترسی هستند اما آن‌هایی را که از <rev1> قابل دسترسی می‌باشند مستثنی می‌کند. هنگامی که هر یک از <rev1> یا <rev2> حذف شوند، پیش‌فرض HEAD خواهد بود.

<rev1>...<rev2>

شامل کامیت‌هایی است که از هر یک از <rev1> یا <rev2> قابل دسترسی هستند اما آن‌هایی را که از هر دوی آن‌ها قابل دسترسی می‌باشند مستثنی می‌کند. هنگامی که هر یک از <rev1> یا <rev2> حذف شوند، پیش‌فرض HEAD خواهد بود.

<rev>^@, e.g. HEAD^@

یک پسوند ^ که به دنبال آن یک علامت at می‌آید، همانند فهرست کردن تمام والدین <rev> است (به این معنا که هر چیزی را که از والدین آن قابل دسترسی باشد شامل می‌شود، اما خود کامیت را شامل نمی‌گردد).

<rev>^!, e.g. HEAD^!

یک پسوند ^ که به دنبال آن یک علامت تعجب می‌آید، همانند دادن کامیت <rev> و تمام والدین آن با پیشوند ^ برای مستثنی کردن آن‌ها (و نیاکانشان) است.

<rev>^-<n>, e.g. HEAD^-, HEAD^-2

معادل <rev>^<n>..<rev> است، که در صورت تعیین نشدن، <n> برابر ۱ می‌باشد.

در این‌جا چند مثال با استفاده از تصویر لوئلیگر در بالا آورده شده است، که در آن هر مرحله از بسط نشانه‌گذاری و انتخاب کامیت‌ها با دقت توضیح داده شده است:

Args   Expanded arguments    Selected commits
D                            G H D
D F                          G H I J D F
^G D                         H D
^D B                         E I J F B
^D B C                       E I J F B C
C                            I J F C
B..C   = ^B C                C
B...C  = B ^F C              G H D E B C
B^-    = B^..B
       = ^B^1 B              E I J F B
C^@    = C^1
       = F                   I J F
B^@    = B^1 B^2 B^3
       = D E F               D G H E F I J
C^!    = C ^C^@
       = C ^C^1
       = C ^F                C
B^!    = B ^B^@
       = B ^B^1 ^B^2 ^B^3
       = B ^D ^E ^F          B
F^! D  = F ^I ^J D           G H D F

در حالت --parseopt، دستور git rev-parse به یکدست‌سازی و پردازش گزینه‌ها کمک می‌کند تا امکاناتی مشابه با توابع توکار C (بخش builtin) را به اسکریپت‌های شل بیاورد. این دستور مانند یک نرمال‌ساز گزینه‌ها عمل می‌کند (برای مثال مقادیر تجمیع‌شده چند سوییچ را تفکیک می‌کند)، تا حدی شبیه به عملکرد getopt(1).

این دستور در ورودی استاندارد مشخصات گزینه‌هایی را که باید تجزیه و درک شوند دریافت می‌کند، و در خروجی استاندارد رشته‌ای مناسب برای دستور eval در sh(1) بازتاب (echo) می‌دهد تا آرگومان‌ها را با آرگومان‌های نرمال‌شده جایگزین کند. در صورت بروز خطا، راهنمای نحوه استفاده (usage) را در خروجی خطای استاندارد نمایش می‌دهد و با کد خروج ۱۲۹ پایان می‌یابد.

یادداشت: هنگام ارسال نتیجه به eval مطمئن شوید که آن را نقل‌قول‌گذاری می‌کنید. برای مشاهده یک نمونه به ادامه متن مراجعه فرمایید.

قالب ورودی git rev-parse --parseopt کاملاً مبتنی بر متن است. این قالب دارای دو بخش است که توسط خطی که تنها حاوی -- است از یکدیگر جدا می‌شوند. خطوط قبل از جداکننده (باید یک یا چند خط باشند) برای متن راهنمای استفاده به کار می‌روند. خطوط پس از جداکننده، گزینه‌ها را شرح می‌دهند.

هر خط از گزینه‌ها دارای این قالب است:

<opt-spec><flags>*<arg-hint>? SP+ help LF

<opt-spec>

قالب آن نویسه گزینه کوتاه، و سپس نام گزینه بلند است که با یک کاما از هم جدا شده‌اند. وجود هر دو بخش الزامی نیست، اگرچه حداقل یکی از آن‌ها ضروری است. نباید شامل هیچ‌یک از نویسه‌های <flags> باشد. h,help، dry-run و f نمونه‌هایی از <opt-spec> صحیح هستند.

<flags>

فلگ‌های <flags> یکی از موارد *، =، ? یا ! هستند.
•در صورتی که گزینه آرگومان دریافت می‌کند، از = استفاده کنید.
•از ? برای این منظور استفاده کنید که گزینه یک آرگومان اختیاری دریافت می‌کند. احتمالاً برای تجزیه غیرمبهم آرگومان اختیاری مایل به استفاده از حالت --stuck-long خواهید بود.
•از * برای نشان دادن این‌که این گزینه نباید در متن راهنمای ایجادشده برای آرگومان -h فهرست شود استفاده کنید. این گزینه برای --help-all همان‌طور که در gitcli(7) مستند شده است، نمایش داده می‌شود.
•از ! برای عدم دسترسی‌پذیری گزینه بلند منفی متناظر استفاده کنید.

<arg-hint>

<arg-hint>، در صورت تعیین، به عنوان نام آرگومان در خروجی راهنما برای گزینه‌هایی که آرگومان دریافت می‌کنند استفاده می‌شود. <arg-hint> با اولین فاصله پایان می‌یابد. مرسوم است که برای تفکیک کلمات در یک عبارت راهنمای چندکلمه‌ای آرگومان از خط تیره استفاده شود.

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

خطوط خالی نادیده گرفته می‌شوند، و خطوطی که با این مشخصات مطابقت ندارند به عنوان سربرگ گروه‌های گزینه‌ها استفاده می‌شوند (برای ایجاد عمدی چنین خطوطی، خط را با یک فاصله آغاز کنید).

OPTS_SPEC="\
some-command [<options>] <args>...
some-command does foo and bar!
--
h,help!   show the help
foo       some nifty option --foo
bar=      some cool option --bar with an argument
baz=arg   another cool option --baz with a named argument
qux?path  qux may take a path argument but has meaning by itself
  An option group Header
C?        option C with an optional argument"
eval "$(echo "$OPTS_SPEC" | git rev-parse --parseopt -- "$@" || echo exit $?)"

هنگامی که در مثال بالا "$@" برابر -h یا --help باشد، متن راهنمای زیر نمایش داده خواهد شد:

usage: some-command [<options>] <args>...
    some-command does foo and bar!
    -h, --help            show the help
    --[no-]foo            some nifty option --foo
    --[no-]bar ...        some cool option --bar with an argument
    --[no-]baz <arg>      another cool option --baz with a named argument
    --[no-]qux[=<path>]   qux may take a path argument but has meaning by itself
An option group Header
    -C[...]               option C with an optional argument

در حالت --sq-quote، دستور git rev-parse یک خط واحد مناسب برای دستور eval در sh(1) را در خروجی استاندارد بازتاب می‌دهد. این خط از طریق نرمال‌سازی آرگومان‌های بعد از --sq-quote ساخته می‌شود. هیچ کاری به جز نقل‌قول‌گذاری آرگومان‌ها انجام نمی‌شود.

اگر می‌خواهید ورودی دستور پیش از نقل‌قول‌گذاری در شل همچنان طبق معمول توسط git rev-parse تفسیر شود، گزینه --sq را ببینید.

$ cat >your-git-script.sh <<\EOF
#!/bin/sh
args=$(git rev-parse --sq-quote "$@")   # quote user-supplied arguments
command="git frotz -n24 $args"          # and use it inside a handcrafted
                                        # command line
eval "$command"
EOF
$ sh your-git-script.sh "a b'c"

•چاپ نام شیء کامیت فعلی:
$ git rev-parse --verify HEAD
•چاپ نام شیء کامیت از روی ارجاع موجود در متغیر شل $REV:
$ git rev-parse --verify --end-of-options $REV^{commit}

در صورتی که $REV خالی باشد یا یک ارجاع معتبر نباشد، با خطا مواجه خواهد شد.

•مشابه بالا:
$ git rev-parse --default master --verify --end-of-options $REV

اما اگر $REV خالی باشد، نام شیء کامیت از master چاپ خواهد شد.

git(1)، git-rev-list(1)، git-check-ref-format(1)

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

2026-06-29 Git 2.55.0