رسائل الـ Commit مهمة
لهذا أرى أن رسائل الـ commit مهمة، وهكذا يمكن أن تساعدكم على أن تصبحوا مطوّرين أفضل.
يُعد Git حاليًا أكثر أنظمة إدارة الإصدارات انتشارًا في صناعة البرمجيات. أنشأه Linus Torvalds بنفسه، العقل المدبر وراء نواة Linux، عام 2005، وأصبح اليوم أداة لا غنى عنها في ترسانة أي مطوّر برمجيات.
من أكثر ما يعجبني في Git نظام الـ commit. فهو يجعل مراجعة التغييرات القديمة وتصحيحها أمرًا مريحًا للغاية بفضل السياق الذي يوفّره. لكنه في الوقت نفسه من أكثر ميزات Git التي يُساء استخدامها.
انظروا إلى هذا المثال:
لقد كانت فوضى لا يمكن إنكارها.
هذا ما يحدث في مشاريع كثيرة، منها مشاريع عملت عليها سابقًا. وعادةً ما يقع الناس في واحد (إن لم يكن أكثر) من الأخطاء التالية:
الـ Commits الكسولة
مثل bug fix وnew feature وGUI done وما شابه. هذا النوع من الـ commits يُفرغ رسالة الـ commit من هدفها، وهو توفير سياق للتغييرات.
Commits نهاية اليوم
كثير ممن عملت معهم يستخدمون Git بهذه الطريقة. يرفعون كل ما عملوا عليه خلال اليوم في commit واحد قبل مغادرة العمل. والنتيجة commit ضخم يحتوي على تغييرات متعددة، ويصعب مراجعته إذا تسبب في إدخال خطأ إلى النظام.
Commits متعددة المهام
أقصد بتعدد المهام أن الـ commit الواحد يفعل أكثر من شيء، مثل إصلاح الصنف A للميزة A وإضافة الدالة B لتحديث الميزة B.
هذه الأنواع من الـ commits تفقد سياقها، وتجعل تتبع ما حدث صعبًا، بل مستحيلًا أحيانًا. فيضطر المسؤول عن صيانة الكود إلى المرور على الـ diff، وقد يستغرق ذلك ساعات إن لم يكن أيامًا.
تطوير البرمجيات عمل تعاوني. fancy-quote
حتى لو كنتم تعملون بمفردكم، فأنتم ما زلتم تتعاونون مع أنفسكم قبل أشهر. فأنتم اليوم لن تتذكروا بدقة ما كنتم تفعلونه آنذاك. والسجل السيئ يهدر الوقت حين يحتاج الآخرون (ومنهم أنتم في المستقبل!) إلى البحث عن تغييرات معينة!
وقد طرح Peter Hutterer فكرة ممتازة في مدونته
"إعادة بناء سياق جزء من الكود هدر للوقت. لا يمكننا تجنّبه تمامًا، لذا يجب أن نوجّه جهودنا إلى تقليله [قدر] الإمكان. ورسائل الـ commit تفعل ذلك تحديدًا، ولهذا تكشف رسالة الـ commit ما إذا كان المطوّر متعاونًا جيدًا."
هناك مئات الإرشادات المتاحة على الإنترنت لمساعدتكم على كتابة رسائل commit أفضل. وإليكم بعض النصائح وقالبًا أستخدمه.
**_
- استخدموا
git commitبدون الخيار-m_**
يتيح لكم ذلك كتابة الـ commit في محرر النصوص المفضل لديكم، وهذا يسهّل كثيرًا كتابة رسالة commit أطول.
_ 2. لماذا وماذا وكيف_
فكّروا قبل أن تكتبوا رسالة commit قصيرة من سطر واحد، فهي في أغلب الأحيان ليست فكرة جيدة. يجب أن يتناول الـ commit ثلاثة جوانب للتغيير: Why is this commit here? و What it does to the system? Are there any side effect? و How it’s done
إليكم قالبًا أستخدمه مأخوذًا من مدونة Tim Pope الشخصية، يشرح لكم كيف تكتبون رسالة commit جيدة.
Capitalized, short (50 chars or less) summary
More detailed explanatory text, if necessary. Wrap it to about 72
characters or so. In some contexts, the first line is treated as the
subject of an email and the rest of the text as the body. The blank
line separating the summary from the body is critical (unless you omit
the body entirely); tools like rebase can get confused if you run the
two together.
Write your commit message in the imperative: “Fix bug” and not “Fixed bug”
or “Fixes bug.” This convention matches up with commit messages generated
by commands like git merge and git revert.
Further paragraphs come after blank lines.
- Bullet points are okay, too
- Typically a hyphen or asterisk is used for the bullet, followed by a
single space, with blank lines in between, but conventions vary here
- Use a hanging indent
lang-text
كما ذكرت سابقًا، تطوير البرمجيات عمل تعاوني. وعندما تكتبون رسائل الـ commit بعناية، فإنكم ترفعون أيضًا إنتاجية برمجياتكم وجودتها.
