| GIT-STATUS(1) | دستورات عمومی کاربر | GIT-STATUS(1) |
نام (NAME)
git-status - نمایش وضعیت شاخه و درخت کاری در مخزن گیت
خلاصه دستور (SYNOPSIS)
git status [<options>] [--] [<pathspec>...]
توضیحات (DESCRIPTION)
مسیرهایی را نمایش میدهد که دارای تفاوتهایی میان فایل ایندکس و کامیت فعلی HEAD هستند، مسیرهایی که دارای تفاوتهایی میان درخت کاری و فایل ایندکس هستند، و مسیرهایی در درخت کاری که توسط گیت ردگیری نمیشوند (و توسط gitignore(5) نادیده گرفته نشدهاند). دسته اول مواردی هستند که شما با اجرای git commit کامیت خواهید کرد؛ دسته دوم و سوم مواردی هستند که شما میتوانید قبل از اجرای git commit با اجرای git add آنها را برای کامیت آماده (استیج) کنید.
گزینهها (OPTIONS)
-s, --short
-b, --branch
--show-stash
--porcelain[=<version>]
پارامتر <version> برای تعیین نسخه قالب استفاده میشود. این پارامتر اختیاری است و مقدار پیشفرض آن قالب نسخه اصلی v1 میباشد.
--long
-v, --verbose
-u[<mode>], --untracked-files[=<mode>]
پارامتر mode برای تعیین نحوه برخورد با فایلهای ردگیرینشده استفاده میشود. این پارامتر اختیاری است: پیشفرض آن all است، و اگر مشخص شود، باید به گزینه بچسبد (برای مثال -uno، اما نه -u no).
گزینههای ممکن عبارتند از:
no
normal
all
هنگامی که گزینه -u استفاده نشود، فایلها و دایرکتوریهای ردگیرینشده نمایش داده میشوند (یعنی معادل تعیین normal)، تا به شما کمک کند فراموش نکنید فایلهای تازه ایجادشده را اضافه نمایید. از آنجا که یافتن فایلهای ردگیرینشده در سیستم فایل مستلزم کار اضافی است، این حالت ممکن است در یک درخت کاری بزرگ کمی زمان ببرد. در صورت پشتیبانی، فعالسازی حافظه پنهان ردگیرینشده (untracked cache) و ایندکس تفکیکشده (split index) را در نظر بگیرید (به git update-index --untracked-cache و git update-index --split-index مراجعه کنید). در غیر این صورت میتوانید از no استفاده کنید تا دستور git status سریعتر و بدون نمایش فایلهای ردگیرینشده بازگردد. تمام نگارشهای معمول مقدار بولی true به عنوان normal و false به عنوان no در نظر گرفته میشوند.
مقدار پیشفرض را میتوان با استفاده از متغیر پیکربندی status.showUntrackedFiles که در git-config(1) مستند شده است تغییر داد.
--ignore-submodules[=<when>]
none
untracked
dirty
all
--ignored[=<mode>]
پارامتر mode برای تعیین نحوه برخورد با فایلهای نادیدهگرفتهشده استفاده میشود. این پارامتر اختیاری است: پیشفرض آن traditional است.
گزینههای ممکن عبارتند از:
traditional
no
matching
مسیرهایی که صراحتاً با یک الگوی نادیدهگیری مطابقت دارند نمایش داده میشوند. اگر یک دایرکتوری با الگوی نادیدهگیری مطابقت داشته باشد، آن دایرکتوری نمایش داده میشود اما مسیرهای موجود در دایرکتوری نادیدهگرفتهشده نشان داده نمیشوند. اگر یک دایرکتوری با الگوی نادیدهگیری مطابقت نداشته باشد، اما تمام محتویات آن نادیده گرفته شده باشند، آنگاه دایرکتوری نمایش داده نمیشود اما تمام محتویات آن نمایش داده میشوند.
-z
--column[=<options>], --no-column
--ahead-behind, --no-ahead-behind
--renames, --no-renames
--find-renames[=<n>]
<pathspec>...
خروجی (OUTPUT)
خروجی این دستور طوری طراحی شده است که بتوان از آن به عنوان یک قالب نظر (comment) برای کامیت استفاده کرد. قالب پیشفرض و طولانی به گونهای طراحی شده است که برای انسان خوانا، پرجزئیات و توصیفی باشد. محتوا و قالب آن در هر زمانی ممکن است تغییر کند.
مسیرهای ذکرشده در خروجی، بر خلاف بسیاری از دستورات دیگر گیت، در صورتی که در یک زیردایرکتوری کار میکنید نسبت به دایرکتوری فعلی نسبی میشوند (این کار عمدی است تا به برش و چسباندن متن کمک کند). به گزینه پیکربندی status.relativePaths در زیر مراجعه کنید.
قالب کوتاه (Short Format)
در قالب کوتاه، وضعیت هر مسیر به یکی از این اشکال نمایش داده میشود:
<xy> <path> <xy> <orig-path> -> <path>
که در آن <orig-path> مکانی است که محتوای تغییرنامیافته/کپیشده از آن آمده است. <orig-path> تنها زمانی نشان داده میشود که ورودی تغییر نام یافته یا کپی شده باشد. بخش <xy> یک کد وضعیت دو حرفی XY است.
فیلدها (شامل ->) با یک فاصله از یکدیگر جدا میشوند. اگر نام یک فایل شامل فاصله یا سایر نویسههای غیرقابلچاپ باشد، آن فیلد به سبک رشتههای لفظی C درون نقلقول قرار میگیرد: محصور در نویسههای دابلکوتیشن اسکی (34)، و با کاراکترهای ویژه داخلی که با بکاسلش اسکیپ شدهاند.
سه نوع مختلف از وضعیتها وجود دارند که با استفاده از این قالب نمایش داده میشوند، و هر یک از نحو <xy> به شکل متفاوتی استفاده میکنند:
توجه داشته باشید که اصطلاح ادغام (merge) در اینجا همچنین شامل ریبیسها با استفاده از استراتژی پیشفرض --merge، چریپیکها (cherry-picks) و هر چیز دیگری که از سازوکار ادغام استفاده میکند نیز میشود.
در جدول زیر، این سه دسته در بخشهای جداگانه نشان داده شدهاند، و این نویسهها برای فیلدهای X و Y در دو بخش اول که مسیرهای ردگیریشده را نشان میدهند استفاده میشوند:
' '
M
T
A
D
R
C
U
| X | Y | معنی |
| [AMD] | بهروزرسانی نشده | |
| M | [ MTD] | در ایندکس بهروزرسانی شده |
| T | [ MTD] | نوع فایل در ایندکس تغییر کرده |
| A | [ MTD] | به ایندکس اضافه شده |
| D | از ایندکس حذف شده | |
| R | [ MTD] | در ایندکس تغییر نام یافته |
| C | [ MTD] | در ایندکس کپی شده |
| [MTARC] | ایندکس و درخت کاری مطابقت دارند | |
| [ MTARC] | M | درخت کاری پس از ایندکس تغییر کرده |
| [ MTARC] | T | نوع فایل در درخت کاری پس از ایندکس تغییر کرده |
| [ MTARC] | D | در درخت کاری حذف شده |
| R | در درخت کاری تغییر نام یافته | |
| C | در درخت کاری کپی شده | |
| D | D | ادغامنشده، در هر دو حذف شده |
| A | U | ادغامنشده، توسط ما اضافه شده |
| U | D | ادغامنشده، توسط آنها حذف شده |
| U | A | ادغامنشده، توسط آنها اضافه شده |
| D | U | ادغامنشده، توسط ما حذف شده |
| A | A | ادغامنشده، در هر دو اضافه شده |
| U | U | ادغامنشده، در هر دو تغییر یافته |
| ? | ? | ردگیرینشده |
| ! | ! | نادیدهگرفتهشده |
زیرماژولها وضعیتهای بیشتری دارند و به جای آن موارد زیر را گزارش میکنند:
M
m
?
این به این دلیل است که محتوای تغییریافته یا فایلهای ردگیرینشده در یک زیرماژول نمیتوانند از طریق git add در ابرپروژه اضافه شوند تا یک کامیت آماده گردد.
m و ? به صورت بازگشتی اعمال میشوند. برای مثال اگر یک زیرماژول تو در تو در یک زیرماژول حاوی یک فایل ردگیرینشده باشد، این مورد نیز به عنوان ? گزارش میشود.
اگر -b استفاده شود، وضعیت قالب کوتاه با خطی به این شکل آغاز میشود:
## <branchname> <tracking-info>
قالب پرسلین نسخه ۱ (Porcelain Format Version 1)
قالب پرسلین نسخه ۱ شبیه به قالب کوتاه است، اما تضمین میشود که در نسخههای گیت یا بر اساس پیکربندی کاربر، به روش ناسازگار با گذشته تغییر نکند. این امر آن را برای تجزیه و پردازش توسط اسکریپتها ایدهآل میسازد. توضیحات قالب کوتاه در بالا، به جز چند استثنا، قالب پرسلین را نیز توصیف میکند:
همچنین یک قالب جایگزین -z برای پردازش ماشینی توصیه میشود. در آن قالب، فیلد وضعیت یکسان است، اما برخی موارد دیگر تغییر میکنند. اولاً، -> از ورودیهای تغییر نام حذف شده و ترتیب فیلدها معکوس میشود (برای مثال from -> to به to from تبدیل میشود). ثانیاً، یک NUL (کد اسکی 0) بعد از هر نام فایل قرار میگیرد و جایگزین فاصله به عنوان جداکننده فیلد و خط جدید پایانی میشود (اما یک فاصله همچنان فیلد وضعیت را از نام فایل اول جدا میکند). ثالثاً، نامهای فایلی که شامل نویسههای ویژه هستند قالببندی خاصی دریافت نمیکنند؛ هیچگونه نقلقول یا اسکیپ کردن با بکاسلش انجام نمیشود.
هرگونه تغییرات زیرماژول به جای m یا ? منفرد، به عنوان M تغییریافته گزارش میشود.
قالب پرسلین نسخه ۲ (Porcelain Format Version 2)
قالب نسخه ۲ اطلاعات دقیقتری درباره وضعیت درخت کاری و موارد تغییریافته اضافه میکند. نسخه ۲ همچنین مجموعهای توسعهپذیر از سرفصلهای اختیاری را تعریف میکند که تجزیه آنها آسان است.
خطوط سرفصل با # شروع میشوند و در پاسخ به آرگومانهای خاص خط فرمان اضافه میگردند. برنامههای تجزیهکننده باید سرفصلهایی را که نمیشناسند نادیده بگیرند.
سرفصلهای
شاخه (Branch Headers)
اگر --branch داده شود، یک سری خطوط سرفصل همراه با اطلاعاتی در مورد شاخه فعلی چاپ میشوند.
| خط | توضیحات |
| # branch.oid <commit> | (initial) | کامیت فعلی. |
| # branch.head <branch> | (detached) | شاخه فعلی. |
| # branch.upstream <upstream-branch> | اگر بالادست تنظیم شده باشد. |
| # branch.ab +<ahead> -<behind> | اگر بالادست تنظیم شده باشد و کامیت وجود داشته باشد. |
اطلاعات
ذخیرهسازی
موقت (Stash Information)
اگر --show-stash داده شود، در صورتی که تعداد ورودیهای استش غیرصفر باشد، یک خط نمایش داده میشود:
# stash <N>
ورودیهای
ردگیریشده
تغییریافته
(Changed Tracked Entries)
به دنبال سرفصلها، یک سری خطوط برای ورودیهای ردگیریشده چاپ میشوند. بسته به نوع تغییر، ممکن است از یکی از سه قالب مختلف خط برای توصیف یک ورودی استفاده شود. ورودیهای ردگیریشده به ترتیبی نامعین چاپ میشوند؛ برنامههای تجزیهکننده باید امکان ترکیب این ۳ نوع خط را به هر ترتیبی در نظر بگیرند.
ورودیهای تغییریافته عادی دارای قالب زیر هستند:
1 <XY> <sub> <mH> <mI> <mW> <hH> <hI> <path>
ورودیهای تغییرنامیافته یا کپیشده دارای قالب زیر هستند:
2 <XY> <sub> <mH> <mI> <mW> <hH> <hI> <X><score> <path><sep><origPath>
| فیلد | معنی |
| <XY> | یک فیلد ۲ کاراکتری شامل مقادیر استیجشده و استیجنشده XY توصیفشده در قالب کوتاه، که حالت بدون تغییر با یک "." به جای فاصله مشخص میشود. |
| <sub> | یک فیلد ۴ کاراکتری که وضعیت زیرماژول را توصیف میکند. "N..." هنگامی که ورودی یک زیرماژول نیست. S<c><m><u> هنگامی که ورودی یک زیرماژول است. 4 • <c> اگر کامیت تغییر کرده باشد "C" است؛ در غیر این صورت ".". 4 • <m> اگر تغییرات ردگیریشده داشته باشد "M" است؛ در غیر این صورت ".". 4 • <u> اگر تغییرات ردگیرینشده وجود داشته باشد "U" است؛ در غیر این صورت ".". |
| <mH> | حالت فایل در مبنای هشت (octal file mode) در HEAD. |
| <mI> | حالت فایل در مبنای هشت در ایندکس. |
| <mW> | حالت فایل در مبنای هشت در درخت کاری. |
| <hH> | نام شیء در HEAD. |
| <hI> | نام شیء در ایندکس. |
| <X><score> | امتیاز تغییر نام یا کپی (بیانگر درصد شباهت میان مبدا و مقصد انتقال یا کپی). برای مثال "R100" یا "C75". |
| <path> | نام مسیر. در یک ورودی تغییرنامیافته/کپیشده، این مسیر مقصد است. |
| <sep> | هنگامی که گزینه -z استفاده میشود، ۲ نام مسیر با یک بایت NUL (کد اسکی 0x00) از هم جدا میشوند؛ در غیر این صورت، یک بایت TAB (کد اسکی 0x09) آنها را جدا میکند. |
| <origPath> | نام مسیر در کامیت در HEAD یا در ایندکس. این فیلد فقط در ورودیهای تغییرنامیافته/کپیشده وجود دارد و مشخص میکند محتوای تغییرنامیافته/کپیشده از کجا آمده است. |
ورودیهای ادغامنشده دارای قالب زیر هستند؛ اولین نویسه یک "u" است تا از ورودیهای تغییریافته عادی متمایز شود.
u <XY> <sub> <m1> <m2> <m3> <mW> <h1> <h2> <h3> <path>
| فیلد | معنی |
| <XY> | یک فیلد ۲ کاراکتری که نوع تعارض را همانطور که در قالب کوتاه شرح داده شد توصیف میکند. |
| <sub> | یک فیلد ۴ کاراکتری که وضعیت زیرماژول را مطابق توضیحات بالا بیان میکند. |
| <m1> | حالت فایل در مبنای هشت در مرحله ۱ (stage 1). |
| <m2> | حالت فایل در مبنای هشت در مرحله ۲ (stage 2). |
| <m3> | حالت فایل در مبنای هشت در مرحله ۳ (stage 3). |
| <mW> | حالت فایل در مبنای هشت در درخت کاری. |
| <h1> | نام شیء در مرحله ۱. |
| <h2> | نام شیء در مرحله ۲. |
| <h3> | نام شیء در مرحله ۳. |
| <path> | نام مسیر. |
سایر
موارد (Other Items)
به دنبال ورودیهای ردگیریشده (و در صورت درخواست)، یک سری خطوط برای موارد ردگیرینشده و سپس موارد نادیدهگرفتهشده موجود در درخت کاری چاپ خواهند شد.
موارد ردگیرینشده دارای قالب زیر هستند:
? <path>
موارد نادیدهگرفتهشده دارای قالب زیر هستند:
! <path>
نکات
قالب نام
مسیر و
گزینه z-
هنگامی که گزینه -z داده میشود، نامهای مسیر همانطور که هستند و بدون هیچگونه نقلقول چاپ میشوند و خطوط با یک بایت NUL (کد اسکی 0x00) پایان مییابند.
بدون گزینه -z، نامهای مسیری که دارای نویسههای "غیرمعمول" هستند، همانطور که برای متغیر پیکربندی core.quotePath توضیح داده شده نقلقول میشوند (به git-config(1) مراجعه کنید).
پیکربندی (CONFIGURATION)
این دستور از متغیرهای پیکربندی color.status (یا status.color — هر دو به یک معنی هستند و دومی برای سازگاری با گذشته حفظ شده است) و color.status.<slot> برای رنگآمیزی خروجی خود پیروی میکند.
اگر متغیر پیکربندی status.relativePaths روی false تنظیم شود، تمام مسیرهای نمایشدادهشده نسبت به ریشه مخزن خواهند بود، نه نسبت به دایرکتوری فعلی.
اگر status.submoduleSummary روی یک عدد غیرصفر یا true (همانند 1- یا یک عدد نامحدود) تنظیم شود، خلاصه زیرماژول برای قالب طولانی فعال میشود و خلاصهای از کامیتها برای زیرماژولهای تغییریافته نمایش داده خواهد شد (به گزینه --summary-limit در git-submodule(1) مراجعه کنید). لطفاً توجه داشته باشید که خروجی خلاصه از دستور status برای همه زیرماژولها هنگامی که diff.ignoreSubmodules روی all تنظیم شده باشد، یا فقط برای زیرماژولهایی که submodule.<name>.ignore=all دارند، متوقف خواهد شد. برای مشاهده خلاصه زیرماژولهای نادیدهگرفتهشده نیز میتوانید از گزینه خط فرمان --ignore-submodules=dirty یا دستور git submodule summary استفاده کنید که خروجی مشابهی را نشان میدهد اما این تنظیمات را رعایت نمیکند.
تازهسازی در پسزمینه (BACKGROUND REFRESH)
به طور پیشفرض، git status به طور خودکار ایندکس را تازهسازی میکند، اطلاعات وضعیت (stat) ذخیرهشده در حافظه پنهان را از درخت کاری بهروزرسانی کرده و نتیجه را مینویسد. نوشتن ایندکس بهروزرسانیشده یک بهینهسازی است که کاملاً ضروری نیست (status مقادیر را برای خودش محاسبه میکند، اما نوشتن آنها صرفاً برای جلوگیری از تکرار محاسبات توسط برنامههای بعدی است). هنگامی که status در پسزمینه اجرا میشود، قفل نگهداشتهشده در طول نوشتن ممکن است با سایر فرآیندهای همزمان تداخل داشته باشد و باعث شکست آنها شود. اسکریپتهایی که status را در پسزمینه اجرا میکنند باید استفاده از git --no-optional-locks status را در نظر بگیرند (برای جزئیات به git(1) مراجعه کنید).
فایلهای ردگیرینشده و کارایی (UNTRACKED FILES AND PERFORMANCE)
دستور git status در درختهای کاری بزرگ در صورت نیاز به جستجو برای فایلها و دایرکتوریهای ردگیرینشده میتواند بسیار کند باشد. گزینههای پیکربندی متعددی برای افزایش سرعت این فرآیند از طریق خودداری از انجام این کار یا استفاده از نتایج ذخیرهشده در حافظه پنهان از دستورات قبلی گیت در دسترس است. هیچ مجموعه بهینهای از تنظیمات وجود ندارد که برای همه مناسب باشد. ما خلاصهای از گزینههای مربوطه را برای کمک به شما فهرست میکنیم، اما قبل از رفتن به سراغ فهرست، ممکن است بخواهید git status را دوباره اجرا کنید، زیرا ممکن است پیکربندی شما از قبل نتایج git status را در حافظه پنهان ذخیره کرده باشد، بنابراین اجرای مجدد آن میتواند سریعتر باشد.
توجه داشته باشید که پس از روشن کردن قابلیتهای حافظه پنهان ردگیرینشده و/یا FSMonitor، ممکن است به چند دستور git status نیاز باشد تا حافظههای پنهان مختلف گرم شوند (warm up) قبل از اینکه متوجه بهبود زمان اجرای دستور شوید. این امر طبیعی است.
همچنین ببینید (SEE ALSO)
گیت (GIT)
بخشی از مجموعه git(1)
| 2026-06-29 | Git 2.55.0 |