Some heavy edits (#457)
This commit is contained in:
Ayub Kokabi
GitHub
parent
53f0205775
commit
66b49ef595
|
|
@ -1,6 +1,6 @@
|
|||
---
|
||||
description: لاگ تغییرات را نگه دارید
|
||||
title: لاگ تغییرات را نگه دارید
|
||||
description: تاریخچهٔ تغییرات را نگه دارید
|
||||
title: تاریخچهٔ تغییرات را نگه دارید
|
||||
language: fa-IR
|
||||
version: 1.0.0
|
||||
---
|
||||
|
|
@ -27,8 +27,8 @@ pre {direction:ltr;text-align:left}
|
|||
|
||||
.header
|
||||
.title
|
||||
%h1 لاگ تغییرات را نگه دارید
|
||||
%h2 اجازه ندهید دوستانتان، لاگ git را در لاگ تغییرات خالی کنند
|
||||
%h1 تاریخچهٔ تغییرات را نگه دارید
|
||||
%h2 نگذارید دوستانتان، خروجی git log را به اسم تاریخچهٔ تغییرات پروژه منتشر کنند.
|
||||
|
||||
= link_to changelog do
|
||||
Version
|
||||
|
|
@ -39,49 +39,49 @@ pre {direction:ltr;text-align:left}
|
|||
.answers
|
||||
%h3#what
|
||||
%a.anchor{ href: "#what", aria_hidden: "true" }
|
||||
لاگ تغییرات چیست؟
|
||||
تاریخچهٔ تغییرات چیست؟
|
||||
|
||||
%p
|
||||
لاگ تغییرات فایلی است که لیست تغییرات قابل توجه برای هر نسخه یک پروژه که بر اساس تاریخ مرتب شدند را شامل می‌شود
|
||||
تاریخچهٔ تغییرات، فایلی شامل تغییرات قابل‌توجهِ هر نسخه از پروژه به‌ترتیبِ زمان انتشار هر نسخه است.
|
||||
|
||||
%h3#why
|
||||
%a.anchor{ href: "#why", aria_hidden: "true" }
|
||||
چرا لیست تغییرات را حفظ کنیم؟
|
||||
چرا باید لیست تغییرات را نگهداری کنیم؟
|
||||
|
||||
%p
|
||||
برای اینکه کاربران و مشارکت‌کنندگان، ساده‌تر بتوانند دقیقاً متوجه تغییرات مهم بین هر عرضه (یا نسخه) پروژه بشوند
|
||||
برای اینکه مردم بفهمند در هر نسخه از پروژه چه تغییرات عمده‌ای وجود داشته است.
|
||||
|
||||
%h3#who
|
||||
%a.anchor{ href: "#who", aria_hidden: "true" }
|
||||
چه کسی به لیست تغییرات نیاز دارد؟
|
||||
لیست تغییرات به درد چه کسانی می‌خورد؟
|
||||
|
||||
%p
|
||||
مردم. خواه مصرف کننده یا توسعه‌دهنده، کاربران نهایی نرم‌افزار انسان‌هایی هستند که به آنچه در نرم‌افزار هست اهمیت می‌دهند. وقتی نرم‌افزار تغییر می‌کنند،مردم می‌خواهند بدانند چرا و چگونه.
|
||||
مصرف‌کننده‌ها، توسعه‌دهنده‌ها، کاربران نهایی و در یک کلام مردم. مسلماً وقتی نرم‌افزاری بروزرسانی می‌شود، کاربران آن دوست دارند بدانند چرا و چطور این تغییرات اعمال شده است.
|
||||
|
||||
.good-practices
|
||||
%h3#how
|
||||
%a.anchor{ href: "#how", aria_hidden: "true" }
|
||||
چطور یک لاگ تغییرات خوب بسازم؟
|
||||
چطور یک تاریخچهٔ تغییرات خوب بسازم؟
|
||||
|
||||
%h4#principles
|
||||
%a.anchor{ href: "#principles", aria_hidden: "true" }
|
||||
اصول راهنما
|
||||
راهنمای کلی
|
||||
|
||||
%ul
|
||||
%li
|
||||
لاگ تغییرات <em>برای انسان‌ها</em>هستند، نه ماشین‌ها.
|
||||
تاریخچهٔ تغییرات <em>برای انسان</em>است، نه ماشین.
|
||||
%li
|
||||
برای هر کدام از نسخه‌ها باید یک مدخل وجود داشته باشد
|
||||
برای هر نسخه از پروژه، مدخلی تعریف کنید.
|
||||
%li
|
||||
انواع مشابه تغییرات باید دسته‌بندی شوند.
|
||||
تغییرات مشابه را دسته‌بندی کنید.
|
||||
%li
|
||||
نسخه‌ها و بخش‌ها باید پیوند پذیر باشند.
|
||||
نسخه‌ها و بخش‌های مختلف باید قابل لینک‌شدن باشند.
|
||||
%li
|
||||
آخرین نسخه اول می‌آید.
|
||||
آخرین نسخه را در ابتدا قرار دهید.
|
||||
%li
|
||||
تاریخ عرضه هر کدام از نسخه‌ها، نمایش داده می‌شود.
|
||||
تاریخ انتشار هر نسخه را مشخص کنید.
|
||||
%li
|
||||
به اینکه #{link_to "نسخه‌بندی معنایی", semver} را رعایت می‌کنید اشاره کنید
|
||||
بگویید که آیا از #{link_to "نسخه‌بندی معنایی", semver} پیروی می‌کنید یا نه.
|
||||
|
||||
%a.anchor{ href: "#types", aria_hidden: "true" }
|
||||
%h4#types انواع تغییرات
|
||||
|
|
@ -89,155 +89,142 @@ pre {direction:ltr;text-align:left}
|
|||
%ul
|
||||
%li
|
||||
%code Added
|
||||
برای امکانات جدید.
|
||||
برای قابلیت‌های جدید.
|
||||
%li
|
||||
%code Changed
|
||||
برای تغییر در عملکرد موجود.
|
||||
برای تغییر در عملکردهای فعلی.
|
||||
%li
|
||||
%code Deprecated
|
||||
برای امکاناتی که به زودی حذف می‌شوند.
|
||||
برای قابلیت‌هایی که به‌زودی حذف می‌شود.
|
||||
%li
|
||||
%code Removed
|
||||
برای امکانات حذف شده.
|
||||
برای قابلیت‌های حذف‌شده.
|
||||
%li
|
||||
%code Fixed
|
||||
برای هر نوع رفع خطا.
|
||||
برای خطاهای رفع‌شده.
|
||||
%li
|
||||
%code Security
|
||||
در صورت وجود آسیب‌پذیری امنیتی.
|
||||
برای آسیب‌پذیری‌های امنیتی.
|
||||
|
||||
.effort
|
||||
|
||||
%h3#effort
|
||||
%a.anchor{ href: "#effort", aria_hidden: "true" }
|
||||
چطور تلاش لازم برای نگهداری لاگ تغییرات را کم کنم؟
|
||||
چطور ثبت تغییرات پروژه را آسان‌تر کنیم؟
|
||||
|
||||
%p
|
||||
بخش <code>Unreleased</code> را برای دنبال کردن تغییرات پیش رو به بالا اضافه کنید
|
||||
در بالای فایل تاریخچهٔ تغییرات، بخشی را تحت عنوان <code>Unreleased</code> برای دنبال‌کردن تغییرات پیش‌رو در نظر بگیرید.
|
||||
|
||||
%p این کار دو هدف را دنبال می‌کند:
|
||||
|
||||
%ul
|
||||
%li
|
||||
افراد بتوانند ببینند چه تغییراتی را می‌توانند در عرضه‌های بعدی انتظار داشته باشند.
|
||||
افراد بتوانند پیش از انتشار یک نسخهٔ جدید، از تغییراتی که می‌توانند در نسخهٔ بعدی انتظار داشته باشند مطلع شوند.
|
||||
%li
|
||||
در زمان عرضه، می‌توانید بخش <code>Unreleased</code> را به بخش release منتقل کنید.
|
||||
هنگام انتشار بتوانید بخش <code>Unreleased</code> را به‌راحتی در قالب یک نسخهٔ جدید به بخش انتشاریافته‌ها منتقل کنید و دیگر لازم نباشد بروید ببینید چه تغییراتی ایجاد شده است.
|
||||
|
||||
.bad-practices
|
||||
%h3#bad-practices
|
||||
%a.anchor{ href: "#bad-practices", aria_hidden: "true" }
|
||||
آیا لاگ تغییرات می‌توانند بد باشند؟
|
||||
|
||||
%p بلی. این‌ها شرایطی هستند که لاگ تغییرات کمتر مفیدند.
|
||||
|
||||
آیا تاریخچهٔ تغییرات می‌تواند بد نوشته شود؟
|
||||
%p بله. در شرایط زیر.:
|
||||
%h4#log-diffs
|
||||
%a.anchor{ href: "#log-diffs", aria_hidden: "true" }
|
||||
تفاوت (diff) لاگ کامیت‌ها
|
||||
استفاده از خروجی log diff به عنوان تاریخچهٔ تغییرات
|
||||
|
||||
%p
|
||||
استفاده از لاگ تفاوت کامیت‌های به عنوان لازم تغییرات ایده بدی است: چون پر از پازایت هستند. پارازیت‌هایی مثل کامیت‌های ادغام، کامیت‌هایی با عناوین مبهم، تغییر مستندات و ...
|
||||
استفاده از خروجی log diffها به عنوان تاریخچهٔ تغییرات، ایدهٔ بدی است. این خروجی مملو از اطلاعات درهم‌وبرهم است؛ مثلاً کامیت‌های مربوط به مرج، کامیت‌هایی با عناوین مبهم، تغییرات مربوط به مستندات و غیره.
|
||||
|
||||
%p
|
||||
هدف کامیت مستند کردن یک گام در سیر تکاملی سورس کد است. بعضی پروژه‌ها، کامیت‌ها را تمیز می‌کنند و بعضی این کار را نمی‌کنند.
|
||||
هدف از یک کامیت، ثبت یک گام انجام‌شده در روند تکامل سورس کد است. برخی از پروژه‌ها، کامیت‌های تمیزی دارند و برخی نه.
|
||||
|
||||
%p
|
||||
هدف یک مدخل لاگ تغییرات مستند کردن تفاوت‌های مهم، معمولاً از میان چندین کامیت، برای انتقال شفاف این تغییرات به کاربران نهایی است.
|
||||
هدف از یک مدخل جدید در فایل تاریخچهٔ تغییرات، مستندسازی شفاف تغییرات مهمِ پروژه برای کاربران نهایی است. هر مدخل در تاریخچهٔ تغییرات لزوماً متناظر با یک کامیت در تاریخچهٔ کامیت‌ها نیست. ممکن است چندین کامیت مختلف، مربوط به یک تغییر باشد و بالعکس یک کامیت (غیراستاندارد) دربردارندهٔ چندین تغییر مهم باشد.
|
||||
|
||||
%h4#ignoring-deprecations
|
||||
%a.anchor{ href: "#ignoring-deprecations", aria_hidden: "true" }
|
||||
نادیده گرفتن منسوخ شده‌ها
|
||||
نادیده‌گرفتن چیزهای منسوخ‌شده
|
||||
Ignoring Deprecations
|
||||
|
||||
%p
|
||||
وقتی مردم از یک نسخه به نسخه دیگری به روز رسانی می‌کنند، باید کاملاً شفاف باشد که چه موقع چیزی می‌شکند.
|
||||
باید ممکن باشد که به نسخه‌ای که منسوخ شده‌ها (deprecations) را فهرست کند، آنچه منسوخ شده را حذف کند و سپس به نسخه‌ای به روز رسانی کرد که منسوخ شده‌ها را برداشته است.
|
||||
|
||||
%p
|
||||
حتی اگر کار دیگری نمی‌کنید، منسوخ شده‌ها، امکانات حذف شده یا هر نوع تغییرات منجر به شکست را در لاگ تغییرات فهرست کنید
|
||||
|
||||
وقتی مردم از یک نسخه به نسخهٔ دیگر به‌روزرسانی می‌کنند باید بدانند که چه موقع نسخهٔ جدید تغییرات ناسازگار به‌همراه دارد. یعنی مثلاً بعد از بروزرسانی یک کتابخانه که پروژهٔ شما به آن وابسته بوده، آیا بخش‌هایی از پروژه از کار می‌افتد یا نه. اگر بله، کدام بخش‌ها. پاسخ این سؤال کمک می‌کند تا توسعه‌دهنده‌ها، متناسب با نسخهٔ جدید، قسمت‌های منسوخ‌شده را جایگزین کرده و بعد از آن اقدام به بروزرسانی کنند.
|
||||
|
||||
%h4#confusing-dates
|
||||
%a.anchor{ href: "#confusing-dates", aria_hidden: "true" }
|
||||
تاریخ‌های گیج کننده
|
||||
تاریخ‌های گیج‌کننده
|
||||
|
||||
%p
|
||||
فرمت‌های تاریخ محلی در سراسر جهان متفاوت است و معمولاً مشکل است که یک فرمت انسان پسند تاریخ پیدا کنیم که همه درکش کنند.
|
||||
مزیت استفاده از فرمت‌هایی مثل
|
||||
<code>2017-07-17</code>
|
||||
این است که شما ترتیب بزرگترین به کوچگترین واحدها را رعایت می کنید: سال، ماه و روز.
|
||||
این فرمت همچنین بر خلاف بعضی فرمت‌های محلی که که جای اعداد ماه و روز را عوضی می‌کنند، با فرمت‌های دو پهلوی تاریخ همپوشانی ندارد،
|
||||
این دلایل، و این واقعیت که این فرمت یک
|
||||
#{link_to "استاندارد ایزو", iso} است، دلیل پیشنهاد شدن این فرمت برای مدخل‌های لاگ تغییرات است.
|
||||
در هر نقطه‌ای از دنیا شکل نمایش تاریخ متفاوت است؛ بنابراین پیداکردن یک قالب نمایش همه‌فهم برای کل مردم دنیا کار دشواری است. مزیت استفاده از قالب‌هایی مثل <code>2017-07-17</code> این است که در آن ترتیب بزرگترین به کوچکترین واحدها یعنی سال، ماه و روز رعایت شده است. این باعث می‌شود که برخلاف برخی از قالب‌ها که در آن جای ماه و روز عوض شده، درک تاریخ دچار ابهام نشود. با درنظرگرفتن این دلایل واین واقعیت که این فرمت یک #{link_to "استاندارد ایزو", iso} است، این قالب را برای مدخل‌های تاریخچهٔ تغییرات در نظر گرفته‌ایم.
|
||||
|
||||
|
||||
%h4#inconsistent-changes
|
||||
%a.anchor{ href: "#inconsistent-changes", aria_hidden: "true" }
|
||||
ناهمگونی ثبت تغییرات
|
||||
Inconsistent Changes
|
||||
%p
|
||||
تاریخچهٔ تغییراتی که فقط شامل برخی از تغییرات است می‌تواند به اندازهٔ نبود تاریخچهٔ تغییرات خطرناک باشد. با اینکه لزومی به ثبت همهٔ تغییرات مثلاً حذف یک فاصلهٔ خالی نیست، باید هر تغییر مهمی را در تاریخچهٔ تغییرات ثبت کرد. نایکدستی در ثبت تغییرات ممکن است اعتماد کاربران را به تاریخچهٔ تغییرات به عنوان یگانه مرجع مشاهدهٔ تغییرات سلب کند. یک تاریخچهٔ تغییرات خوب باید به‌طور منظم بروزرسانی شود.
|
||||
|
||||
%aside
|
||||
موارد بیشتری وجود دارد. با
|
||||
اگر فکر می‌کنید جای موارد بیشتری در این لیست خالی است با
|
||||
= link_to "ارسال issue", issues
|
||||
یا ارسال Pull request به من کمک کنید این ضد الگوها را جمع‌آوری کنم
|
||||
یا ارسال Pull request به من کمک کنید.
|
||||
|
||||
.frequently-asked-questions
|
||||
%h3#frequently-asked-questions
|
||||
%a.anchor{ href: "#frequently-asked-questions", aria_hidden: "true" }
|
||||
پرسش‌های متداول
|
||||
|
||||
سوالات متداول
|
||||
%h4#standard
|
||||
%a.anchor{ href: "#standard", aria_hidden: "true" }
|
||||
آیا فرمت استانداردی برای لاگ تغییرات وجود دارد؟
|
||||
آیا فرمت استانداردی برای تاریخچهٔ تغییرات وجود دارد؟
|
||||
|
||||
%p
|
||||
خیر. "راهنمای" #{link_to "راهنمای شیوه لاگ تغییرات GNU", gnustyle},
|
||||
یا #{link_to "فایل دو پاراگرافی GNU NEWS", gnunews}
|
||||
وجود دارد. این نارسا و ناکافی هستند.
|
||||
حقیتاً نه. یک "راهنمای" #{link_to "راهنمای شیوه ثبت تاریخچهٔ تغییرات GNU", gnustyle},
|
||||
و یک #{link_to "فایل دو پاراگرافیِ بلند GNU NEWS", gnunews}
|
||||
وجود دارد که متأسفانه هردویشان نارسا و ناکافی هستند.
|
||||
|
||||
%p
|
||||
این پروژه قصد دارد
|
||||
= link_to "یک قرارداد بهتر برای لاگ تغییرات باشد", changelog
|
||||
که از مشاهده و جمع آوری شیوه‌های خوب جامعه متن باز آمده است
|
||||
= link_to "قراردادی بهتر برای ثبت تاریخچهٔ تغییرات باشد", changelog
|
||||
که برگرفته از تجربیات جامعهٔ متن‌باز است.
|
||||
|
||||
%p
|
||||
از نقد سالم، بحث و گفتگو و پیشنهادات برای بهبود
|
||||
از نقد سالم، بحث‌وگفتگو و پیشنهادها
|
||||
= link_to "استقبال می‌کنیم.", issues
|
||||
|
||||
|
||||
%h4#filename
|
||||
%a.anchor{ href: "#filename", aria_hidden: "true" }
|
||||
فایل لاگ تغییرات باید چه نامیده شود؟
|
||||
نام فایل تاریخچهٔ تغییرات چه چیزی باشد؟
|
||||
|
||||
%p
|
||||
نامش را <code>CHANGELOG.md</code> بگذارید. بعضی پروژه‌ها از
|
||||
نام این فایل را <code>CHANGELOG.md</code> بگذارید. بعضی پروژه‌ها از
|
||||
<code>HISTORY</code>, <code>NEWS</code> یا <code>RELEASES</code> استفاده می‌کنند.
|
||||
|
||||
%p
|
||||
در حالی گه ساده است فکر کنیم که اسم فایل لاگ تغییرات اهمیتی ندارد، چرا پیدا کردن تغییرات مهم را برای کاربران نهایی سخت کنیم؟
|
||||
در حالی که ساده است فکر کنیم که اسم فایل تاریخچهٔ تغییرات اهمیتی ندارد، چرا یافتن تغییرات مهم را برای کاربران نهایی سخت کنیم؟
|
||||
|
||||
%h4#github-releases
|
||||
%a.anchor{ href: "#github-releases", aria_hidden: "true" }
|
||||
Release های گیت‌هاب چطور؟
|
||||
|
||||
چرا از ریلیزهای گیت‌هاب استفاده نکنیم؟
|
||||
%p
|
||||
ابتکار فوق‌العاده‌ای است. #{link_to "Release", ghr} ها می‌توانند برای تبدیل برچسب‌های ساده گیت
|
||||
(مثلاً برچسبی به نام <code>v1.0.0</code>)
|
||||
به یادداشت عرضه (Release Note) غنی استفاده شوند. یا با اضافه کردن دستی یادداشت عرضه یا با گرفتن پیام‌های حاشیه‌نویسی شده برچسب گیت و تبدیلشان به یادداشت.
|
||||
|
||||
ابتکار خوبی است. در هنگام انتشار #{link_to "Release", ghr}ها می‌توانید به جای عرضهٔ یک نسخهٔ ساده (مثلاً یک برچسب خالی با نام <code>v1.0.0</code>)، لیست تغییرات آن نسخه را در قالب یک یادداشت، به آن برچسب ضمیمه کنید.
|
||||
|
||||
%p
|
||||
Release های گیت‌هاب لاگ‌های تغییرات غیرقابل حمل که فقط در گیت‌هاب به کاربران نمایش داده می‌شوند را ایجاد می‌کنند.
|
||||
شبیه کردن‌شان به فرمت پیشنهادی این سند ممکن است اما تلاش بیشتری می‌طلبد.
|
||||
|
||||
اما نکته این است که تاریخچهٔ تغییراتی که در هر ریلیز گیت‌هاب منتشر می‌کنید فقط در خودِ گیت‌هاب قابل استفاده است و به‌راحتی نمی‌توانید آن را به جای دیگری منتقل کنید. شاید بتوانید بسیار شبیهش کنید به نسخهٔ پیشنهادی این سند ولی کار زحمت‌داری است.
|
||||
|
||||
%p
|
||||
نسخه فعلی release های گیت‌هاب نسبت به فایل‌های با حرف بزرگ دیگر
|
||||
مشاهدهٔ تغییرات پروژه در لابه‌لای ریلیزهای گیت‌هاب، به اندازهٔ دیدن همهٔ تغییرات در یک فایل، آسان و دلچسب نیست. فایل‌هایی با حرف بزرگ،
|
||||
(<code>README</code>, <code>CONTRIBUTING</code>, غیره.)
|
||||
کمتر توسط کاربران پیدا می‌شوند
|
||||
مشکل کوچک دیگر این است که رابط کاربری فعلی امکان ایجاد پیوند به لاگ کامیت‌ها را بین هر عرضه نمی‌دهد.
|
||||
|
||||
جذابیت بیشتری برای کاربران دارد. مشکل کوچک بعدی این است که رابط کاربری فعلی اجازه نمی‌دهد بین تاریخچهٔ کامیت‌ها در عرضه‌های مختلف، پیوند برقرار کنید.
|
||||
%h4#automatic
|
||||
%a.anchor{ href: "#automatic", aria_hidden: "true" }
|
||||
آیا لاگ تغییرات را می‌توان به صورت اتوماتیک، پارس کرد؟
|
||||
آیا نمی‌توان مطابقت تاریخچهٔ تغییرات با موازین این سند را به صورت خودکار انجام داد؟
|
||||
|
||||
%p
|
||||
مشکل است، چون افراد فرمت‌ها و فایل‌ها خیلی متفاوتی را استفاده می‌کنند.
|
||||
مشکل است؛ چون افراد از فرمت‌ها و نام‌گذاری‌های متعددی برای این فایل استفاده می‌کنند.
|
||||
|
||||
%p
|
||||
#{link_to "Vandamme", vandamme} یک روبی gem ساخته شده توسط تیم
|
||||
Gemnasium است که اغلب (اما نه همه) لاگ تغییرات پروژه‌های متن باز را پارس می‌کند.
|
||||
#{link_to "Vandamme", vandamme} یک روبی gem است که توسط تیم
|
||||
Gemnasium ساخته شده است. این ابزار، تاریخچهٔ تغییرات پروژه‌های متن‌باز (البته نه همه) را بررسی می‌کند.
|
||||
|
||||
|
||||
%h4#yanked
|
||||
|
|
@ -245,24 +232,22 @@ pre {direction:ltr;text-align:left}
|
|||
عرضه‌های yanked چطور؟
|
||||
|
||||
%p
|
||||
عرضه‌های Yanked نسخه‌هایی هستند که به خاطر باگ جدی یا مشکل امنیتی باید گرفته شوند.
|
||||
معمولاً این عرضه‌ها در لاگ تغییرات دیده نمی‌شوند، اما باید اضافه شوند. این روشی است که باید آن‌ها را نمایش دهید:
|
||||
عرضه‌های Yanked نسخه‌هایی هستند که به خاطر باگ جدی یا مشکل امنیتی باید گرفته شوند. این نسخه‌ها اغلب حتی در تاریخچهٔ تغییرات نیز دیده نمی‌شوند، اما باید اضافه شوند. آن‌ها را به صورت زیر در فایل تاریخچهٔ تغییرات نشان دهید:
|
||||
%p <code>## [0.0.5] - 2014-12-13 [YANKED]</code>
|
||||
|
||||
%p
|
||||
برچسب <code>[YANKED]</code> به دلیلی پر سر و صداست.
|
||||
مهم است که مردم به آن توجه کنند. چون با کروشه محصور شده پارس کردن نرم‌افزاری آن‌ها هم ساده‌تر است.
|
||||
برچسب <code>[YANKED]</code> را به این دلیل، به‌شکل متمایز در تاریخچهٔ تغییرات آورده‌ایم که نظرها را به خود جلب کند. بعلاوه وجود کروشه، کار پارزرها را راحت‌تر می‌کند.
|
||||
|
||||
|
||||
%h4#rewrite
|
||||
%a.anchor{ href: "#rewrite", aria_hidden: "true" }
|
||||
آیا هرگز باید یک لاگ تغییرات را بازنویسی کنید؟
|
||||
آیا لازم است تاریخچهٔ تغییرات را بازنویسی کنیم؟
|
||||
|
||||
%p
|
||||
حتماً. همیشه دلیل خوبی برای بهبود لاگ تغییرات وجود دارد. من معمولاً برای اضافه کردن عرضه‌های فراموش شده به پروژه‌های متن باز که لاگ تغییرات را نگهداری نمی‌کنند Pull Request ایجاد می‌کنم.
|
||||
قطعاً. معمولاً همیشه دلیل خوبی برای بهبود تاریخچهٔ تغییرات وجود دارد. من معمولاً به‌طور منظم، فایل تاریخچهٔ تغییرات را برای پروژه‌های متن‌بازی که این کار را انجام نداده‌اند می‌نویسم و تغییرات را به صورت یک پول‌ریکوئست ارائه می‌دهم.
|
||||
|
||||
%p
|
||||
ممکن است متوجه شوید گه فراموش کردید تغییرات منجر به شکست را در یادداشت‌‌های یک نسخه بنویسید. به طور مشخص در چنین شرایطی مهم است که لاگ تغییرات را به روز رسانی کنید.
|
||||
گاهی نیز ممکن است یادتان رفته باشد که تغییرات ناسازگار یک نسخه را ثبت کنید. در چنین شرایطی نیز واضح است که باید تاریخچهٔ تغییرات را بروزرسانی کنید.
|
||||
|
||||
|
||||
%h4#contribute
|
||||
|
|
@ -270,15 +255,15 @@ pre {direction:ltr;text-align:left}
|
|||
چطور می‌توانم مشارکت کنیم؟
|
||||
|
||||
%p
|
||||
این سند <strong>حقیقت</strong> نیست; این نظر به دقت در نظر گرفته شده من به همراه اطلاعات و مثال‌هایی است که من گردآوری کردم
|
||||
این سند <strong>کامل و بی‌نقص</strong> نیست; صرفاً نظرات به‌دقت بررسی‌شده‌ای است که با اطلاعات و مثال‌هایی در اینجا قرار داده‌ام.
|
||||
|
||||
%p
|
||||
این سند برای آن است که جامعه نرم‌افزاری به اجماع برسند. معتقدم بحث و گفتگو به اندازه نتیجه نهایی مهم است
|
||||
این به خاطر آن است که می‌خواهم جامعهٔ ما توسعه‌دهنده‌ها به یک اتفاق‌نظر برسد. من معتقدم بحث‌وگفتگو به‌اندازهٔ نتیجه مهم است.
|
||||
|
||||
%p
|
||||
بنابراین لطفاً <strong>#{link_to "دست به کار شوید", gh}</strong>.
|
||||
بنابراین شما نیز <strong>#{link_to "دست به کار شوید", gh}</strong>.
|
||||
|
||||
.press
|
||||
%h3 گفتگو
|
||||
%p
|
||||
به #{link_to "پادکست Changelog", thechangelog} رفتم تا درباره اینکه چرا متصدیان نگهداری و مشارکت‌کنندگان پروژه‌ها باید به لاگ تغییرات اهمیت بدهند و همچنین انگیزه‌های پشت این پروژه صحبت کنم.
|
||||
در #{link_to "پادکست Changelog", thechangelog}، گفتگویی داشته‌ام دربارهٔ انگیزهٔ پشت این پروژه و اینکه چرا متصدیان نگهداری و مشارکت‌کنندگان پروژه‌ها باید به تاریخچهٔ تغییرات اهمیت بدهند.
|
||||
|
|
|
|||
Loading…
Reference in New Issue