تاریخ قدیمی کامیت Git، تاریخ انتشار عمومی کد نیست

در یک مخزن کد، کامیتی با تاریخ مارس ۲۰۲۴ می‌بینید. صاحب ادعا آن را شاهدی می‌داند که قابلیت نرم‌افزار از همان زمان در دسترس عموم بوده است. تاریخ را ثبت کنید، اما برای این نتیجه مدرک دیگری لازم است: زمان ذخیره‌شده داخل کامیت، به‌تنهایی نشان نمی‌دهد کد چه زمانی عمومی شده است.

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

دو فیلد را با برچسب خودشان بخوانید

کامیت، سابقه‌ای از وضعیت پروژه و اطلاعات همراه آن در Git است؛ می‌توان آن را روی یک رایانه ساخت، بدون اینکه پروژه منتشر شود. هر کامیت تاریخ نویسنده یا author date و تاریخ ثبت‌کننده یا committer date دارد. هیچ‌کدام را بدون توضیح به «تاریخ انتشار» تغییر نام ندهید. مستندات رسمی ساخت کامیت امکان تعیین این دو تاریخ با متغیرهای محیطی را توضیح می‌دهد؛ در نتیجه صرف وجود آن‌ها شاهدی مستقل از ساعت وقوع رویداد نیست.

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

git show -s --format="commit=%H%nauthor=%aI%ncommitter=%cI" COMMIT_ID

طبق راهنمای git show، گزینه‌های %aI و %cI تاریخ نویسنده و ثبت‌کننده را در قالب دقیق ISO 8601 نمایش می‌دهند. گزینهٔ -s نمایش تغییرات فایل را کنار می‌گذارد. برای خواندن این اطلاعات لازم نیست برنامهٔ داخل مخزن را اجرا یا وابستگی‌های آن را نصب کنید.

در بررسی تحت وب، لینک دقیق کامیت و نام فیلدهای قابل مشاهده را نگه دارید. راهنمای مشارکت‌های GitHub توضیح می‌دهد که نمای پروفایل از تاریخ نویسنده و نمای مخزن از تاریخ کامیت استفاده می‌کند. تفاوت دو نمایش ممکن است از همین انتخاب فیلد بیاید؛ هیچ‌یک به‌خودیِ خود رویداد «اولین انتشار عمومی» را ثبت نمی‌کند.

آزمایش محلی با تاریخ‌های عمداً قدیمی

این تمرین ساختگی در ۱ نوامبر ۲۰۲۶ روی محیط محلی اجرا شد. مخزنی تازه با یک فایل متنی بی‌خطر ساختیم و دو تاریخ قدیمی را به‌عنوان دادهٔ آزمایش تعیین کردیم. مخزن مقصدی نداشت و چیزی در شبکه منتشر نشد. خواندن کامیت این خروجی را داد:

author=2024-03-10T09:00:00Z
committer=2024-03-12T10:00:00Z

خروجی در Git نسخهٔ ۲٫۵۴٫۰ ویندوز بررسی شد. این آزمایش نشان می‌دهد یک شیء تازه می‌تواند چنین تاریخ‌هایی را در خود داشته باشد. آزمایشِ رابط GitHub نیست و دربارهٔ رفتار هیچ برنامه‌نویس واقعی داوری نمی‌کند.

اکنون ادعا را امتحان کنید: «این کد تا ۱۰ مارس ۲۰۲۴ عمومی بوده است.» فیلد نویسنده برای اثبات آن کافی نیست، چون مخزن آموزشی اصلاً منتشر نشده بود. رفتن سراغ فیلد ثبت‌کننده هم مشکل را حل نمی‌کند؛ آن مقدار نیز به‌عنوان داده تعیین شده است. نتیجهٔ درست این است که دو تاریخ در شیء دیده‌ایم و زمان دسترسی عمومی هنوز ثابت نشده است.

تفاوت این دو تاریخ هم لزوماً نشانهٔ دست‌کاری فریبکارانه نیست. GitHub توضیح می‌دهد که فرایندهای بازنویسی تاریخچه می‌توانند تاریخ‌های متفاوت ایجاد کنند. برابر بودن دو فیلد نیز آن‌ها را به گواهی انتشار تبدیل نمی‌کند. برای ادعای زمانی، باید ارتباط محتوای دقیق با دسترسی عمومی را جداگانه نشان دهید.

فرستادن کامیت با عمومی شدن آن یکی نیست

مستندات push این عملیات را ارسال دادهٔ لازم و به‌روزرسانی ارجاع‌ها در مخزن مقصد شرح می‌دهد. کامیت می‌تواند پیش از این عملیات وجود داشته باشد. تاریخ نویسندهٔ یک کامیت موجود، رسید زمان ارسال آن نیست؛ خود مخزن مقصد هم ممکن است خصوصی باشد.

برای بررسی دسترسی عمومی، دنبال ثبت تاریخ‌داری از همان فایل در وب یا ارجاع عمومیِ مستقلاً حفظ‌شده‌ای باشید که محتوای دقیق را مشخص کند. موضوع مدرک مهم است: صفحه‌ای که فقط نام پروژه را آورده، وجود آن قابلیت را نشان نمی‌دهد. همین‌طور تاریخ ایجاد یک issue که امروز در مخزن عمومی دیده می‌شود، به‌تنهایی عمومی بودن مخزن در آن تاریخ را ثابت نمی‌کند.

«تا این تاریخ در این ثبت وب قابل مشاهده بوده» با «دقیقاً در این روز برای نخستین بار منتشر شده» فرق دارد. ممکن است برای جملهٔ اول مدرک داشته باشید و برای دومی نداشته باشید. روش خواندن مشاهده‌های تاریخ‌دار را در راهنمای سابقهٔ وب‌سایت دنبال کنید.

اختلاف منطقهٔ زمانی را با اختلاف رویداد اشتباه نگیرید

در یک مثال عددی جداگانه، 2024-03-10T12:30:00+03:30 و 2024-03-10T09:00:00Z یک لحظه را نشان می‌دهند. اختلاف سه ساعت و نیم از آفست زمانی می‌آید. رشتهٔ اصلی را نگه دارید و مقدار تبدیل‌شده به UTC را کنار آن بنویسید. عبارت نسبی «دو سال پیش» را نیز هم‌دقتِ یک زمان کامل در نظر نگیرید.

برای تحویل بررسی، پنج خط کافی است:

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

اگر اختلاف دربارهٔ سازندهٔ قابلیت است، به راهنمای سهم واقعی در مخزن GitHub بروید؛ خواندن تاریخ، مسئلهٔ نویسندگی را حل نمی‌کند. برای پرسش زمانی، این پنج خط را در قالب گزارش اوسینت ثبت کنید. جملهٔ «کامیت تاریخ مارس را ثبت کرده، اما عمومی بودن کد تا مارس با مدارک بررسی‌شده احراز نشده» می‌تواند نتیجهٔ کامل یک بررسی محدود باشد.