کدوم برنامه نویس ها روی پروژمون بیشتر کامیت داشتند؟

تا حالا شده به این فکر کنید که کدوم برنامه نویس ها تا حالا روی پروژه ای که روی اون کد میزنید کد زدند؟
یا اینکه هر برنامه نویس چه قدر تا به حال روی پروژه کد زده و کدوم برنامه نویس بیشتر تاحالا commit داشته؟
گیت یک کامند برای این سوال ها داره که shortlog هست:

git shortlog

اجرای این کامند بدون option اسم برنامه نویس، تعداد کل commit و commit message رو چاپ میکنه.

کی بیشترین کامیت رو داشته؟

حالا اگر بخواهیم به صورت descending بر اساس تعداد commit و به صورت خلاصه فقط تعداد commit و ایمیل و اسم هر برنامه نویس رو ببینیم با ۳ تا option زیر اجرا میکنیم:

git shortlog -nse

با زدن این کامند شما دارید مشاهده میکنید که به ترتیب کدوم برنامه نویس ها بیشترین commit رو در پروژه شما از روز اول داشتند

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

مثلا یک برنامه نویسی به اسم Vahiiiid شاید 100 تا commit با ایمیل A و ۲۰۰ تا commit با همین اسم ولی ایمیل ‌B داشته باشه.

در این اسپرینت یا در یک بازه زمانی هر برنامه نویس چقدر کامیت داشته؟

کافیه از option هایی که برای فیلتر زمان گیت روی کامند هاش داره استفاده کنید مثلا در ۴ هفته اخیر چقدر commit هر شخصی داشته است:

git shortlog -nse --after=&quot4 weeks ago&quot
git shortlog -nse --before=&quot2021-09-01&quot --after=&quot2021-08-01&quot

اولین کامیت های پروژه چی بوده و کی زده؟

شاید اگر در یک پروژه ای مشغول کار هستید که چند سالی از شروع نوشتن و نگه داریش میگذره و اسم آدم های مختلفی رو شنیدید، بخواهید بدونید پروژه دقیقا چه روزی شروع شده، چه کسی و چه commit هایی رو برای اولین بار زدند:

git log  --reverse

بعد از دستور بالا میتونید hash commit اول رو بردارید و با دستور های زیر کل فایل های اون commit رو ببینید و تفاوتشون رو هم متوجه بشید:

git ls-files <commit-id> 
git show <commit-id>

همون طور که همه میدونیم تعداد commit بالا صرفا مشخص نمیکنه که یک شخصی بیشتر کار کرده یا در یک بازه زمانی یکسان برنامه نویس بهتری بوده و این زمانی بیشتر نمود پیدا میکنه که معمولا تیم ها convention برای اینکه چه زمانی یک commit جدید بزنند ندارند.

زدن commit برای هر تغییر فایل یا زدن تنها یک commit برای یک فیچر بزرگ هر دو bad practice هستند و این موارد میتونه به همراه خیلی چیزهای دیگه مثل commit message درست گذاشتن از طریق تعریف یک team convention طبق best practice های موجود حل بشه.

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