git-blame - آنلاین در ابر

برنامه:

نام

git-blame - نمایش آخرین ویرایش و نویسنده ای که هر خط یک فایل را تغییر داده است

خلاصه

دستگاه گوارش سرزنش [-c] [-b] [-l] [--ریشه] [-t] [-f] [-n] [-s] [-e] [-p] [-w] [--افزاینده]
[-L ] [-S ] [-M] [-C] [-C] [-C] [--از آنجا که= ]
[--abbrev= ] [ | --فهرست | --معکوس ] [--]

شرح

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

هنگامی که یک یا چند بار مشخص می شود، -L حاشیه نویسی را به خطوط درخواستی محدود می کند.

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

این گزارش در مورد خطوطی که حذف یا جایگزین شده اند چیزی به شما نمی گوید. شما
نیاز به استفاده از ابزاری مانند دستگاه گوارش تفاوت یا رابط "کلنگ" که به طور خلاصه در آن ذکر شده است
پاراگراف زیر

به غیر از پشتیبانی از حاشیه نویسی فایل، Git از جستجو در تاریخچه توسعه نیز پشتیبانی می کند
برای زمانی که یک قطعه کد در یک تغییر رخ داد. این امکان ردیابی زمانی که یک کد وجود دارد را ممکن می سازد
قطعه به یک فایل اضافه شد، بین فایل ها جابه جا یا کپی شد و در نهایت حذف شد یا
جایگزین شده است. با جستجوی یک رشته متن در تفاوت کار می کند. یک مثال کوچک از
رابط pickaxe که blame_usage را جستجو می کند:

$ git log --pretty=oneline -S'blame_usage'
5040f17eba15504bad66b14a645bddd9b015ebb7 blame -S <ancestry-file>
ea4c7f9bf69e781dd0cd88d2bccb2bf5cc15c9a7 git-blame: Make the output

OPTIONS

-b
SHA-1 خالی را برای تعهدات مرزی نشان دهید. این را نیز می توان از طریق کنترل کرد
گزینه پیکربندی blame.blankboundary.

-- ریشه
تعهدات ریشه ای را به عنوان مرز در نظر نگیرید. این را نیز می توان از طریق کنترل کرد
گزینه پیکربندی blame.showRoot.

--نمایش آمار
آمارهای اضافی را در پایان خروجی سرزنش درج کنید.

-ل ، ، -L:
فقط محدوده خط داده شده را حاشیه نویسی کنید. ممکن است چندین بار مشخص شود. با هم تداخل دارند
محدوده مجاز است

و اختیاری هستند. "-L " یا "-L " از به
انتهای فایل "-L، ” از ابتدای فایل تا .

و می تواند یکی از این اشکال را داشته باشد:

· عدد

اگر یا یک عدد است، یک عدد خط مطلق را مشخص می کند (شمارش خطوط
از 1).

· /regex/

این فرم از اولین خط منطبق با regex POSIX استفاده می کند. اگر هست یک
regex، از انتهای محدوده -L قبلی، در صورت وجود، در غیر این صورت جستجو می کند
از ابتدای فایل اگر "^/regex/" است، از ابتدا جستجو خواهد کرد
فایل. اگر یک regex است، با شروع از خط داده شده توسط .

· +offset یا -offset

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

اگر ": ” به جای داده می شود و ، یک عبارت منظم است
که نشان دهنده محدوده اولین خط نام تابعی است که مطابقت دارد ، تا
خط نام تابع بعدی ": ” از انتهای محدوده -L قبلی جستجو می کند، اگر
هر، در غیر این صورت از ابتدای فایل. "^: ” از ابتدای فایل جستجو می کند.

-l
نمایش دور طولانی (پیش‌فرض: خاموش).

-t
نمایش مهر زمانی خام (پیش‌فرض: خاموش).

-س
به جای فراخوانی از نسخه‌های revs-file استفاده کنید git-rev-list(1).

--معکوس
تاریخ را به جای عقب رفتن به جلو بروید. به جای نشان دادن بازبینی که در آن الف
خط ظاهر شد، این آخرین ویرایشی را نشان می دهد که در آن یک خط وجود داشته است. این نیاز دارد
طیفی از بازبینی مانند START..END که در آن مسیر سرزنش در START وجود دارد.

-p، -- چینی
نمایش در قالب طراحی شده برای مصرف ماشین.

--خط چینی
فرمت چینی را نشان دهید، اما اطلاعات تعهد خروجی را برای هر خط، نه فقط برای هر خط، نمایش دهید
اولین باری که یک commit ارجاع داده می شود. دلالت بر -- چینی.

--افزایشی
نتیجه را به صورت تدریجی در قالبی که برای مصرف ماشین طراحی شده است نشان دهید.

--Encoding=
رمزگذاری مورد استفاده برای خروجی نام نویسندگان و انجام خلاصه ها را مشخص می کند. تنظیم آن به
هیچ یک از خروجی داده های تبدیل نشده سرزنش نمی کند. برای اطلاعات بیشتر به بحث مراجعه کنید
در مورد رمزگذاری در گیت(1) صفحه دستی.

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

--تاریخ
فرمت مورد استفاده برای خروجی تاریخ را مشخص می کند. اگر --date ارائه نشده باشد، مقدار the
از متغیر پیکربندی blame.date استفاده شده است. اگر متغیر پیکربندی blame.date نیز تنظیم نشده باشد،
از فرمت iso استفاده شده است. برای مقادیر پشتیبانی شده، بحث گزینه --date را ببینید
at گیت(1).

-M| |
شناسایی خطوط منتقل شده یا کپی شده در یک فایل. هنگامی که یک commit بلوکی از را جابجا یا کپی می کند
خطوط (مثلاً فایل اصلی دارای A و سپس B است و commit آن را به B و تغییر می دهد
سپس A)، سنتی سرزنش الگوریتم فقط نیمی از حرکت را متوجه می شود و
معمولاً خطوطی را که به بالا منتقل شده اند (یعنی B) به والدین سرزنش می کند و سرزنش می کند
به خطوطی که به پایین منتقل شدند (یعنی A) به کودک متعهد شوید. با این گزینه، هر دو
گروه‌هایی از خطوط با اجرای پاس‌های اضافی بازرسی به گردن والدین می‌افتند.

اختیاری است اما کران پایینی تعداد کاراکترهای الفبایی است
که Git باید به عنوان در حال حرکت/کپی کردن در یک فایل شناسایی کند تا بتواند آن خطوط را مرتبط کند
با والدین متعهد می شوند. مقدار پیش فرض 20 است.

-C| |
علاوه بر -M، خطوط منتقل شده یا کپی شده از فایل های دیگری را که در آنها اصلاح شده اند شناسایی کنید
همان ارتکاب این زمانی مفید است که برنامه خود را سازماندهی مجدد می کنید و کد را جابجا می کنید
در سراسر فایل ها هنگامی که این گزینه دو بار داده می شود، دستور به دنبال آن می گردد
کپی از فایل های دیگر در commit که فایل را ایجاد می کند. وقتی این گزینه داده می شود
سه بار، دستور علاوه بر این به دنبال کپی از فایل های دیگر در هر commit می شود.

اختیاری است اما کران پایینی تعداد کاراکترهای الفبایی است
که Git باید به عنوان جابجایی/کپی بین فایل‌ها شناسایی کند تا بتواند آن خطوط را مرتبط کند
با والدین متعهد می شوند. و مقدار پیش فرض 40 است. اگر بیش از یک -C وجود داشته باشد
گزینه های داده شده، آرگومان آخرین -C اعمال خواهد شد.

-h
نمایش پیام راهنما

-c
از همان حالت خروجی استفاده کنید git-annotate(1) (پیش فرض: خاموش).

--score-debug
شامل اطلاعات اشکال زدایی مربوط به حرکت خطوط بین فایل ها (به -C مراجعه کنید)
و خطوط درون یک فایل جابجا شدند (به -M مراجعه کنید). اولین عدد ذکر شده امتیاز است. این هست
تعداد کاراکترهای الفبایی تشخیص داده شده که بین یا درون جابجا شده اند
فایل ها. این باید بالاتر از یک آستانه خاص باشد دستگاه گوارش سرزنش در نظر گرفتن آن خطوط از
کد منتقل شده است.

-f، --show-name
نام فایل را در commit اصلی نشان دهید. به طور پیش فرض نام فایل در صورت وجود نشان داده می شود
هر خطی که از فایلی با نام دیگری به دلیل تشخیص تغییر نام آمده است.

-n، --show-number
شماره خط را در commit اصلی نشان دهید (پیش‌فرض: خاموش).

-s
نام نویسنده و مهر زمانی را از خروجی حذف کنید.

-e، --show-email
ایمیل نویسنده را به جای نام نویسنده نشان دهید (پیش‌فرض: خاموش). این نیز می تواند باشد
از طریق گزینه blame.showEmail کنترل می شود.

-w
هنگام مقایسه نسخه والدین و فرزند برای یافتن مکان، فضای خالی را نادیده بگیرید
خطوط آمده است.

--abbrev=
به جای استفاده از ارقام پیش فرض 7+1 هگزادسیمال به عنوان نام مخفف شیء،
استفاده کنید 1+ رقم. توجه داشته باشید که از 1 ستون برای نشان دادن commit مرزی برای علامت گذاری استفاده می شود.

L' ظروف چینی FORMAT

در این فرمت، هر خط پس از یک هدر خروجی می شود. سرصفحه حداقل دارای این است
خط اول که دارای:

· 40 بایت SHA-1 از خط commit به آن نسبت داده می شود.

· شماره خط خط در فایل اصلی.

· شماره خط خط در فایل نهایی.

· در خطی که گروهی از خطوط را از کامیتی متفاوت از خط قبلی شروع می کند،
تعداد خطوط این گروه در خطوط بعدی این فیلد وجود ندارد.

این خط سرصفحه با اطلاعات زیر حداقل یک بار برای هر commit دنبال می شود:

· نام نویسنده ("نویسنده")، ایمیل ("نویسنده ایمیل")، زمان ("زمان نویسنده")، و منطقه زمانی
("نویسنده-tz")؛ به طور مشابه برای committer.

· نام فایل در commit که خط به آن نسبت داده می شود.

· خط اول پیام commit log ("خلاصه").

محتویات خط واقعی پس از هدر فوق با پیشوند یک TAB خروجی می شود. این
اجازه دادن به اضافه کردن عناصر سرصفحه بیشتر در آینده است.

قالب چینی به طور کلی اطلاعات مربوط به ارتکاب را که قبلاً دیده شده است، سرکوب می کند.
به عنوان مثال، دو خط که به یک commit سرزنش می شوند، هر دو نشان داده می شوند، اما
جزئیات مربوط به آن commit فقط یک بار نشان داده می شود. این کارآمدتر است، اما ممکن است نیاز داشته باشد
حالت بیشتر توسط خواننده حفظ شود. از گزینه --line-porcelain می توان برای خروجی کامل استفاده کرد
اطلاعات را برای هر خط متعهد کنید تا استفاده ساده‌تر (اما کارآمدتر) مانند:

# تعداد خطوط منتسب به هر نویسنده را بشمارید
git blame --line-فایل چینی |
sed -n 's/^author //p' |
مرتب سازی | uniq -c | مرتب سازی -rn

مشخص کردن محدوده ها

برخلاف دستگاه گوارش سرزنش و دستگاه گوارش حاشیه نویسی در نسخه های قدیمی git، میزان حاشیه نویسی
را می توان به هر دو محدوده خط و محدوده تجدید نظر محدود کرد. گزینه -L که محدود می کند
حاشیه نویسی برای طیف وسیعی از خطوط، ممکن است چندین بار مشخص شود.

هنگامی که علاقه مند به یافتن مبدا خطوط 40-60 برای فایل foo هستید، می توانید از آن استفاده کنید
گزینه -L مانند آن است (منظور آنها یکسان است - هر دو 21 خط را می خواهند که از خط شروع می شود
40):

git blame -L 40,60 foo
git blame -L 40,+21 foo

همچنین می توانید از یک عبارت منظم برای تعیین محدوده خط استفاده کنید:

git blame -L '/^sub hello {/,/^}$/' foo

که حاشیه نویسی را به بدنه زیربرنامه hello محدود می کند.

زمانی که علاقه ای به تغییرات قدیمی تر از نسخه 2.6.18 یا تغییرات قدیمی تر از 3 ندارید
هفته‌ها، می‌توانید از مشخص‌کننده‌های بازبینی مشابه استفاده کنید دستگاه گوارش rev-list:

git blame v2.6.18.. -- foo
git blame --since=3.weeks -- foo

وقتی از مشخص‌کننده‌های محدوده بازبینی برای محدود کردن حاشیه‌نویسی استفاده می‌شود، خطوطی که چنین نیستند
از مرز محدوده تغییر کرده است (اعم از commit v2.6.18 یا آخرین commit که
در مثال بالا بیش از 3 هفته از عمر آن می گذرد) مقصر آن ارتکاب مرز محدوده هستند.

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

git log --diff-filter=A --pretty=short -- foo

و سپس با استفاده از commit، تغییر بین commit و والدین آن را حاشیه نویسی کنید! نشانه گذاری:

git blame -C -C -f $commit^! -- فو

افزایشی OUTPUT

هنگامی که با گزینه ---incremental فراخوانی می شود، فرمان نتیجه را همانطور که ساخته شده است، خروجی می دهد. در
خروجی به طور کلی ابتدا در مورد خطوطی صحبت می کند که توسط commit های اخیر لمس شده اند (یعنی
خطوط بدون ترتیب حاشیه نویسی خواهند شد) و قرار است توسط بینندگان تعاملی استفاده شود.

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

1. هر ورودی سرزنش همیشه با یک خط شروع می شود:

<40 بایت hex sha1>

شماره خطوط از 1 محاسبه می شود.

2. اولین بار که یک commit در استریم ظاهر می شود، اطلاعات مختلفی دارد
در مورد آن با یک برچسب یک کلمه ای در ابتدای هر خط چاپ شده است
اطلاعات commit اضافی (نویسنده، ایمیل، committer، تاریخ، خلاصه و غیره).

3. برخلاف فرمت Porcelain، اطلاعات نام فایل همیشه داده می شود و خاتمه می یابد
ورودی:

"نام فایل"

و بنابراین تجزیه برای برخی از تجزیه کننده های خط و کلمه گرا واقعاً بسیار آسان است
(که باید برای اکثر زبان های اسکریپت کاملا طبیعی باشد).

توجه داشته باشید
برای افرادی که تجزیه را انجام می دهند: برای قوی تر کردن آن، کافی است خطوط بین آن ها را نادیده بگیرید
اولین و آخرین (" خطوط " و "filename") که آنها را نمی شناسید
کلمات تگ (یا اهمیت دادن به آن مورد خاص) در ابتدای عبارت
خطوط "اطلاعات گسترده". به این ترتیب، اگر اطلاعاتی اضافه شد (مانند
رمزگذاری commit یا تفسیر commit گسترده)، بیننده سرزنش اهمیتی نخواهد داد.

نقشه AUTHORS

اگر فایل mailmap در سطح بالای مخزن یا در مکان مشخص شده وجود داشته باشد.
به توسط گزینه های پیکربندی mailmap.file یا mailmap.blob، برای نگاشت نویسنده و
نام های committer و آدرس های ایمیل به نام های واقعی و آدرس های ایمیل متعارف.

در شکل ساده، هر خط در فایل از نام واقعی متعارف an تشکیل شده است
نویسنده، فضای خالی، و آدرس ایمیل استفاده شده در commit (ضمیمه شده توسط < و >) نقشه برداری
به نام مثلا:

اسم مناسب[ایمیل محافظت شده]>

اشکال پیچیده تر عبارتند از:

<[ایمیل محافظت شده]>[ایمیل محافظت شده]>

که به mailmap اجازه می دهد تا تنها قسمت ایمیل یک commit را جایگزین کند و:

اسم مناسب[ایمیل محافظت شده]>[ایمیل محافظت شده]>

که به mailmap اجازه می دهد نام و ایمیل یک commit مطابق با آن را جایگزین کند
آدرس ایمیل commit مشخص شده و:

اسم مناسب[ایمیل محافظت شده]> نام تعهد[ایمیل محافظت شده]>

که به mailmap اجازه می دهد تا نام و ایمیل یک commit را جایگزین هر دو کند
نام commit و آدرس ایمیل مشخص شده

مثال 1: تاریخچه شما شامل تعهدات دو نویسنده به نام های جین و جو است که نام آنها ظاهر می شود.
در مخزن به چندین شکل:

Joe Developer[ایمیل محافظت شده]>
Joe R. توسعه دهنده[ایمیل محافظت شده]>
جین دو[ایمیل محافظت شده]>
جین دو
جین دی.

حال فرض کنید که جو می‌خواهد از نام میانی‌اش استفاده شود و جین نام خانوادگی خود را ترجیح دهد
به طور کامل بیان شده است یک فایل mailmap مناسب به شکل زیر است:

جین دو
Joe R. توسعه دهنده[ایمیل محافظت شده]>

توجه داشته باشید که چگونه نیازی به ورودی برای وجود ندارد ، زیرا نام واقعی
آن نویسنده قبلاً درست است.

مثال 2: مخزن شما حاوی تعهداتی از نویسندگان زیر است:

نیک 1[ایمیل محافظت شده]>
نیک 2[ایمیل محافظت شده]>
نیک 2[ایمیل محافظت شده]>
بابا نوئل[ایمیل محافظت شده]>
بند[ایمیل محافظت شده]>
CTO[ایمیل محافظت شده]>

سپس ممکن است یک فایل mailmap بخواهید که به شکل زیر باشد:

<[ایمیل محافظت شده]>[ایمیل محافظت شده]>
فلان رفیق[ایمیل محافظت شده]> نیک1[ایمیل محافظت شده]>
نویسنده دیگر[ایمیل محافظت شده]> نیک2[ایمیل محافظت شده]>
نویسنده دیگر[ایمیل محافظت شده]>[ایمیل محافظت شده]>
بابا نوئل[ایمیل محافظت شده]>[ایمیل محافظت شده]>

از هش استفاده کنید # برای نظراتی که یا در خط خودشان هستند یا بعد از آدرس ایمیل.

با استفاده از خدمات onworks.net از git-blame آنلاین استفاده کنید