| GIT-REV-PARSE(1) | Git Manual | GIT-REV-PARSE(1) |
نام (NAME)
git-rev-parse - تجزیه و اعتبارسنجی پارامترها و مشخصات ارجاع
خلاصه دستور (SYNOPSIS)
git rev-parse [<options>] <arg>...
توضیحات (DESCRIPTION)
بسیاری از دستورات سطح بالای (porcelain) گیت ترکیبی از فلگها (یعنی پارامترهایی که با خط تیره - شروع میشوند) و پارامترهای مختص دستور زیربنایی git rev-list که در داخل استفاده میکنند، و همچنین فلگها و پارامترهایی برای سایر دستوراتی که در مراحل بعدی از git rev-list استفاده میکنند را دریافت میکنند. هدف اصلی این دستور آن است که به برنامههای فراخواننده اجازه دهد بین آنها تمایز قائل شوند. چند حالت عملیاتی دیگر نیز وجود دارند که ارتباطی با این موضوع "کمک به تجزیه گزینههای خط فرمان" ندارند.
مگر در مواردی که مشخص شده باشد، بیشتر گزینهها و حالتهای عملیاتی مستلزم اجرای این دستور در داخل یک مخزن گیت یا یک درخت کاری تحت کنترل یک مخزن گیت هستند، و در غیر این صورت یک خطای مهلک (fatal error) نمایش خواهند داد.
گزینهها (OPTIONS)
حالتهای عملیاتی (Operation Modes)
هر یک از این گزینهها باید در ابتدای خط فرمان ظاهر شوند.
--parseopt
--sq-quote
گزینههای parseopt-- (Options for --parseopt)
--keep-dashdash
--stop-at-non-option
--stuck-long
گزینههای فیلتر کردن (Options for Filtering)
--revs-only
--no-revs
--flags
--no-flags
گزینههای خروجی (Options for Output)
--default <arg>
--prefix <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
اگر میخواهید مطمئن شوید که خروجی واقعاً نام یک شیء در پایگاه داده اشیاء شما است و/یا میتواند به عنوان یک نوع شیء خاص که نیاز دارید استفاده شود، میتوانید عملگر جداسازی (peeling) به شکل ^{type} را به پارامتر اضافه کنید. به عنوان مثال، git rev-parse "$VAR^{commit}" اطمینان حاصل میکند که $VAR نام یک شیء موجود است که از نوع شبهکامیت (commit-ish) باشد (یعنی یک کامیت یا یک برچسب یادداشتدار که به یک کامیت اشاره دارد). برای اطمینان از اینکه $VAR نام یک شیء موجود از هر نوعی است، میتوان از git rev-parse "$VAR^{object}" استفاده کرد.
توجه داشته باشید که اگر نامی را از یک منبع نامعتبر اعتبارسنجی میکنید، بهتر است از --end-of-options استفاده کنید تا آرگومان نام با یک گزینه دیگر اشتباه گرفته نشود.
-q, --quiet
--sq
--short[=<length>]
--not
--abbrev-ref[=(strict|loose)]
--symbolic
--symbolic-full-name
--output-object-format=(sha1|sha256|storage)
مشخص کردن "sha1" در صورت لزوم تبدیل را انجام داده و یک oid از نوع sha1 برمیگرداند.
مشخص کردن "sha256" در صورت لزوم تبدیل را انجام داده و یک oid از نوع sha256 برمیگرداند.
مشخص کردن "storage" در صورت لزوم تبدیل را انجام داده و یک oid کدگذاریشده در الگوریتم هش فضای ذخیرهسازی را برمیگرداند.
گزینههای مربوط به اشیاء (Options for Objects)
--all
--branches[=<pattern>], --tags[=<pattern>], --remotes[=<pattern>]
اگر یک pattern مشخص شده باشد، فقط ارجاعاتی که با تطبیق شل گلوب (shell glob) داده شده مطابقت دارند نمایش داده میشوند. اگر الگو شامل نویسههای گلوبینگ (?, *، یا [) نباشد، با افزودن /* به یک تطبیق پیشوندی تبدیل میشود.
--glob=<pattern>
--exclude=<glob-pattern>
الگوهای داده شده هنگام اعمال بر روی --branches، --tags یا --remotes نباید با refs/heads، refs/tags یا refs/remotes شروع شوند و هنگام اعمال بر روی --glob یا --all باید با refs/ شروع شوند. اگر یک /* پایانی مد نظر باشد، باید به صراحت قید گردد.
--exclude-hidden=(fetch|receive|uploadpack)
--disambiguate=<prefix>
گزینههای مربوط به فایلها (Options for Files)
--local-env-vars
--path-format=(absolute|relative)
این گزینه میتواند چندین بار مشخص شود و فقط روی آرگومانهایی که پس از آن در خط فرمان میآیند تأثیر میگذارد؛ یا تا انتهای خط فرمان یا تا نمونه بعدی این گزینه.
گزینههای زیر توسط --path-format تغییر مییابند:
--git-dir
اگر $GIT_DIR تعریف نشده باشد و تشخیص داده نشود که دایرکتوری فعلی درون یک مخزن یا درخت کاری گیت قرار دارد، پیامی در stderr چاپ کرده و با وضعیت غیرصفر خارج میشود.
--git-common-dir
--resolve-git-dir <path>
--git-path <path>
--show-toplevel
--show-superproject-working-tree
--shared-index-path
گزینههای زیر تحت تأثیر --path-format قرار نمیگیرند:
--absolute-git-dir
--is-inside-git-dir
--is-inside-work-tree
--is-bare-repository
--is-shallow-repository
--show-cdup
--show-prefix
--show-object-format[=(storage|input|output|compat)]
--show-ref-format
سایر گزینهها (Other Options)
--since=<datestring>, --after=<datestring>
--until=<datestring>, --before=<datestring>
<arg>...
مشخص کردن ارجاعات (SPECIFYING REVISIONS)
یک پارامتر بازبینی (revision) به نام <rev> معمولاً، اما نه لزوماً، نام یک شیء کامیت را مشخص میکند. این پارامتر از ساختاری موسوم به نحو SHA-1 گسترشیافته استفاده میکند. در اینجا روشهای گوناگونی برای نگارش نام اشیاء آمده است. مواردی که در نزدیکی انتهای این فهرست ذکر شدهاند، نام درختها و blobهای موجود در یک کامیت را مشخص میکنند.
یادداشت
این سند نحو "خام" (raw) را همانگونه که توسط گیت دیده میشود نشان میدهد. شل و سایر واسطهای کاربری ممکن است برای محافظت از نویسههای خاص و جلوگیری از تفکیک کلمات، به نقلقولگذاری اضافی نیاز داشته باشند.
<sha1>, e.g. dae86e1950b1277e545cee180551750029cfe735, dae86e
<describeOutput>, e.g. v1.7.4.2-679-g3bee7fb
<refname>, e.g. master, heads/master, refs/heads/master
HEAD
FETCH_HEAD
ORIG_HEAD
MERGE_HEAD
REBASE_HEAD
REVERT_HEAD
CHERRY_PICK_HEAD
BISECT_HEAD
AUTO_MERGE
توجه داشته باشید که هر یک از موارد refs/* بالا ممکن است از دایرکتوری $GIT_DIR/refs یا از فایل $GIT_DIR/packed-refs بیایند. با وجودی که کدگذاری نام ارجاع تعییننشده است، UTF-8 ترجیح داده میشود زیرا برخی از پردازشهای خروجی ممکن است نام ارجاعات را به صورت UTF-8 فرض کنند.
@
[<refname>]@{<date>}, e.g. master@{yesterday}, HEAD@{5 minutes ago}
<refname>@{<n>}, e.g. master@{1}
@{<n>}, e.g. @{1}
@{-<n>}, e.g. @{-1}
[<branchname>]@{upstream}, e.g. master@{upstream}, @{u}
[<branchname>]@{push}, e.g. master@{push}, @{push}
در اینجا مثالی برای شفافتر شدن موضوع آمده است:
$ 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
<rev>~[<n>], e.g. HEAD~, master~3
<rev>^{<type>}, e.g. v0.99.8^{commit}
از <rev>^{object} میتوان برای اطمینان از اینکه <rev> نام شیئی موجود را مشخص میکند استفاده کرد، بدون اینکه نیازی باشد <rev> یک برچسب باشد و بدون بازگشایی ارجاع <rev>؛ زیرا یک برچسب از قبل خود یک شیء است، و حتی یک بار هم نیازی به بازگشایی ارجاع آن برای رسیدن به یک شیء وجود ندارد.
از <rev>^{tag} میتوان برای اطمینان از اینکه <rev> یک شیء برچسب موجود را مشخص میکند استفاده نمود.
<rev>^{}, e.g. v0.99.8^{}
<rev>^{/<text>}, e.g. HEAD^{/fix nasty bug}
:/<text>, e.g. :/fix nasty bug
<rev>:<path>, e.g. HEAD:README, master:./README
:[<n>:]<path>, e.g. :0:README, :README
در اینجا تصویری از جان لوئلیگر (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
مشخص کردن محدودهها (SPECIFYING RANGES)
دستورات پیمایش تاریخچه مانند git log بر روی مجموعهای از کامیتها عمل میکنند، نه فقط یک کامیت منفرد.
برای این دستورات، مشخص کردن یک بازبینی منفرد، با استفاده از نشانهگذاری توصیفشده در بخش پیشین، به معنای مجموعه کامیتهای قابل دسترسی (reachable) از کامیت داده شده است.
مشخص کردن چندین بازبینی به معنای مجموعه کامیتهای قابل دسترسی از هر یک از کامیتهای داده شده است.
مجموعه قابل دسترسی یک کامیت، خود کامیت و کامیتهای موجود در زنجیره تبار (ancestry chain) آن است.
چندین نشانهگذاری برای مشخص کردن مجموعهای از کامیتهای مرتبط (که "محدوده بازبینی" یا revision range نامیده میشود) وجود دارد، که در ادامه نشان داده شده است.
استثنا کردن کامیتها (Commit Exclusions)
نشانهگذاری ^<rev> (هشتک / caret)
نشانهگذاریهای محدوده نقطهای (Dotted Range Notations)
نشانهگذاری محدوده .. (دو نقطه)
نشانهگذاری تفاضل متقارن ... (سه نقطه)
در این دو نشانهگذاری مختصر، میتوانید یک سر محدوده را حذف کنید تا به طور پیشفرض 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 است.
سایر نشانهگذاریهای مختصر والد <rev>^ (Other <rev>^ Parent Shorthand Notations)
سه حالت خلاصه دیگر وجود دارند که به ویژه برای کامیتهای ادغام مفید هستند و برای نامگذاری مجموعهای به کار میروند که توسط یک کامیت و کامیتهای والد آن تشکیل میشود.
نشانهگذاری r1^@ به معنای تمام والدین r1 است.
نشانهگذاری r1^! شامل کامیت r1 است اما تمام والدین آن را مستثنی میکند. این نشانهگذاری به تنهایی کامیت منفرد r1 را نشان میدهد.
نشانهگذاری <rev>^-[<n>] شامل <rev> است اما والد <n>-ام را مستثنی میکند (یعنی خلاصهای برای <rev>^<n>..<rev>)، که در صورت عدم قید، <n> = 1 خواهد بود. این مورد معمولاً برای کامیتهای ادغام مفید است که در آنها میتوانید به سادگی <commit>^- را ارسال کنید تا تمام کامیتهای موجود در شاخهای را که در کامیت ادغام <commit> ادغام شده است (شامل خود <commit>) دریافت کنید.
در حالی که <rev>^<n> در مورد مشخص کردن یک والد کامیت منفرد بود، این سه نشانهگذاری والدین آن را نیز در نظر میگیرند. برای مثال میتوانید بنویسید HEAD^2^@، اما نمیتوانید بگویید HEAD^@^2.
خلاصه محدودههای ارجاع (REVISION RANGE SUMMARY)
<rev>
^<rev>
<rev1>..<rev2>
<rev1>...<rev2>
<rev>^@, e.g. HEAD^@
<rev>^!, e.g. HEAD^!
<rev>^-<n>, e.g. HEAD^-, HEAD^-2
در اینجا چند مثال با استفاده از تصویر لوئلیگر در بالا آورده شده است، که در آن هر مرحله از بسط نشانهگذاری و انتخاب کامیتها با دقت توضیح داده شده است:
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)
در حالت --parseopt، دستور git rev-parse به یکدستسازی و پردازش گزینهها کمک میکند تا امکاناتی مشابه با توابع توکار C (بخش builtin) را به اسکریپتهای شل بیاورد. این دستور مانند یک نرمالساز گزینهها عمل میکند (برای مثال مقادیر تجمیعشده چند سوییچ را تفکیک میکند)، تا حدی شبیه به عملکرد getopt(1).
این دستور در ورودی استاندارد مشخصات گزینههایی را که باید تجزیه و درک شوند دریافت میکند، و در خروجی استاندارد رشتهای مناسب برای دستور eval در sh(1) بازتاب (echo) میدهد تا آرگومانها را با آرگومانهای نرمالشده جایگزین کند. در صورت بروز خطا، راهنمای نحوه استفاده (usage) را در خروجی خطای استاندارد نمایش میدهد و با کد خروج ۱۲۹ پایان مییابد.
یادداشت: هنگام ارسال نتیجه به eval مطمئن شوید که آن را نقلقولگذاری میکنید. برای مشاهده یک نمونه به ادامه متن مراجعه فرمایید.
قالب ورودی (Input Format)
قالب ورودی git rev-parse --parseopt کاملاً مبتنی بر متن است. این قالب دارای دو بخش است که توسط خطی که تنها حاوی -- است از یکدیگر جدا میشوند. خطوط قبل از جداکننده (باید یک یا چند خط باشند) برای متن راهنمای استفاده به کار میروند. خطوط پس از جداکننده، گزینهها را شرح میدهند.
هر خط از گزینهها دارای این قالب است:
<opt-spec><flags>*<arg-hint>? SP+ help LF
<opt-spec>
<flags>
<arg-hint>
باقیمانده خط، پس از حذف فاصلههای اضافی، به عنوان متن راهنمای مربوط به آن گزینه استفاده میشود.
خطوط خالی نادیده گرفته میشوند، و خطوطی که با این مشخصات مطابقت ندارند به عنوان سربرگ گروههای گزینهها استفاده میشوند (برای ایجاد عمدی چنین خطوطی، خط را با یک فاصله آغاز کنید).
مثال (Example)
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 $?)"
متن راهنما (Usage text)
هنگامی که در مثال بالا "$@" برابر -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)
در حالت --sq-quote، دستور git rev-parse یک خط واحد مناسب برای دستور eval در sh(1) را در خروجی استاندارد بازتاب میدهد. این خط از طریق نرمالسازی آرگومانهای بعد از --sq-quote ساخته میشود. هیچ کاری به جز نقلقولگذاری آرگومانها انجام نمیشود.
اگر میخواهید ورودی دستور پیش از نقلقولگذاری در شل همچنان طبق معمول توسط git rev-parse تفسیر شود، گزینه --sq را ببینید.
مثال (Example)
$ 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"
مثالها (EXAMPLES)
$ git rev-parse --verify HEAD
$ git rev-parse --verify --end-of-options $REV^{commit}
در صورتی که $REV خالی باشد یا یک ارجاع معتبر نباشد، با خطا مواجه خواهد شد.
$ git rev-parse --default master --verify --end-of-options $REV
اما اگر $REV خالی باشد، نام شیء کامیت از master چاپ خواهد شد.
همچنین ببینید (SEE ALSO)
گیت (GIT)
بخشی از مجموعه git(1)
| 2026-06-29 | Git 2.55.0 |