כדי ליצור היסטוריית עדכונים שימושית, על הצוותים להסכים תחילה על אמנת מסר התחייבות לשימוש. זה חל גם על פרויקטים אישיים.
לאחרונה ב- Hashnode שאלתי: "באיזה אמנת מסר התחייבות אתה משתמש בעבודה?" וקיבלתי תגובות מדהימות עם משתמשים שהסבירו את המוסכמות בהן הם משתמשים בעבודה ולפרויקטים האישיים שלהם.
באיזה אמנת מסר התחייבות אתה משתמש בעבודה?
מאת @hashnode //t.co/HewCBxRCbr
- BOLAJI ✨ (@iambolajiayo) 25 בנובמבר 2019במאמר זה אעבור כיצד לכתוב הודעות התחייבות טובות ומדוע כדאי לכם.
נ.ב: מאמר זה פורסם לראשונה בבלוג שלי כאן.
מבוא לבקרת גרסאות עם Git
תוכנת בקרת גרסאות היא חלק חיוני מהשיטות של מפתחי תוכנה בימינו.
ללא ספק, גיט היא מערכת בקרת הגרסאות הנפוצה ביותר בעולם. זהו פרויקט קוד פתוח מבוזר ומתוחזק שפותח במקור בשנת 2005 על ידי לינוס טורבלדס, היוצר המפורסם של ליבת מערכת ההפעלה לינוקס.
חדש בגיט? בדוק את המדריך הרשמי לתחילת העבודה או שקופית זו מתוך שיחה שעברתי.
מהו מסר התחייבות?
להתחייב הפקודה משמשת כדי לשמור את השינויים למאגר המקומי לאחר שביים ב Git. עם זאת, לפני שתוכל לשמור שינויים ב- Git, עליך לספר ל- Git אילו שינויים אתה רוצה לשמור מכיוון שאולי ביצעת טונות של עריכות. דרך נהדרת לעשות זאת היא הוספת הודעת התחייבות לזיהוי השינויים שלך.
אפשרויות התחייבות
- -M
אפשרות זו מגדירה את המסר של ההתחייבות.
git add static/admin/config.yml git commit -m "Setup multiple roles for netlify-cms git gateway" - -א או - הכל
אפשרות זו מתחייבת באופן אוטומטי על כל (כולל חדש) קבצים במעקב, שונה או שנמחק.
git commit -a -m "Add a new role for netlify-cms git gateway" - --לְתַקֵן
אפשרות זו משכתבת את ההתחייבות האחרונה עם כל השינויים המבוימים כרגע או הודעת התחייבות חדשה ויש לבצע אותה רק בהתחייבויות שעדיין לא נדחקו למאגר מרוחק.
git add . git commit --amend -m "Update roles for netlify-cms git gateway" מדוע כדאי לכתוב הודעות התחייבות טובות?
אתה יכול לומר, "זה רק פרויקט אישי." כן, אתה עובד לבד עכשיו, אבל מה קורה כשאתה עובד עם צוות או תורם למקור פתוח?
מסר התחייב היטב של Git הוא הדרך הטובה ביותר לתקשר הקשר על שינוי למפתחים אחרים העובדים על הפרויקט ההוא, ואכן, לעצמך העתידי.
האם ניסית אי פעם לרוץ git logעל אחד הפרויקטים הישנים שלך כדי לראות את הודעות ההתחייבות ה"מוזרות "בהן השתמשת מאז הקמתו? יכול להיות קשה להבין מדוע ביצעת שינויים בעבר, והיית רוצה שתקרא מאמר זה קודם :).
הודעות התחייבות יכולות לתקשר בצורה מספקת מדוע בוצע שינוי, והבנה ההופכת יעילה לפיתוח ולשיתוף פעולה.
כיצד לכתוב הודעות התחייבות עם גיט
עד עכשיו השתמשתי רק git commit -m "Fix X to allow Y to use Z"בפרויקטים האישיים שלי עם נושא בלבד וללא תיאור נוסף. זה נהדר לתיקונים קטנים וברורים כמו git commit -m "Fix typo in README.md, אבל במקרים של שינויים נרחבים יותר, יהיה עליך להוסיף כמה פרטים נוספים.
שיטת העורך
הפעל git commitללא הודעה או אפשרות וזה יפתח את עורך הטקסט המוגדר כברירת מחדל כדי לכתוב הודעת התחייבות.
כדי להגדיר את עורך "ברירת המחדל" שלך:
git config --global core.editor nano זה יגדיר את Git להשתמש בננו כעורך ברירת המחדל שלך. החלף את "ננו" ב- "emacs", "vim" או כל מה שאתה מעדיף.
בעורך שנפתח, השורה הראשונה היא הנושא (תיאור קצר), השאירו שורה ריקה אחריה, וכל השאר הוא התיאור המורחב (גוף).
שיטת שורת פקודה
git commit -m "Subject" -m "Description..." -mהאפשרות הראשונה היא הנושא (תיאור קצר), והבא הוא התיאור המורחב (גוף).
איך לכתוב הודעות התחייבות טובות
ישנן מספר מוסכמות המשמשות צוותים ומפתחים שונים לכתיבת הודעות התחייבות טובות. אפרט רק כמה כללים וטיפים כלליים לכתיבת הודעות התחייבות - אתה צריך להחליט באיזו מוסכמה אתה רוצה לקיים. ואם אתה עובד בחברה או תורם למקור פתוח, אתה צריך להסתגל לכינוס שלהם :).
לשם עקביות, אתה יכול להשתמש בכנס אחד לעבודה ובאחר לפרויקטים אישיים מכיוון שאתה עשוי להחליף עבודה מתישהו, והכנס עשוי גם להשתנות.
הקפד לבדוק בשרשור זה כמה מוסכמות מדהימות של הודעות התחייבות או הוסף את שלך כדי לעזור למישהו לקבל החלטה.
הנה תבנית נהדרת של הודעת התחייבות טובה שנכתבה במקור על ידי טים אפיפיור
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 If you use an issue tracker, add a reference(s) to them at the bottom, like so: Resolves: #123 נראה נהדר, נכון? כך תוכל גם להפוך את שלך נהדר:
- ציין את סוג ההתחייבות:
- הישג: התכונה החדשה שאתה מוסיף ליישום מסוים
- fix: A bug fix
- style: Feature and updates related to styling
- refactor: Refactoring a specific section of the codebase
- test: Everything related to testing
- docs: Everything related to documentation
- chore: Regular code maintenance.[ You can also use emojis to represent commit types]
- Separate the subject from the body with a blank line
- Your commit message should not contain any whitespace errors
- Remove unnecessary punctuation marks
- Do not end the subject line with a period
- Capitalize the subject line and each paragraph
- Use the imperative mood in the subject line
- Use the body to explain what changes you have made and why you made them.
- Do not assume the reviewer understands what the original problem was, ensure you add it.
- Do not think your code is self-explanatory
- Follow the commit convention defined by your team
Conclusion
The most important part of a commit message is that it should be clear and meaningful. In the long run, writing good commit messages shows how much of a collaborator you are. The benefits of writing good commit messages are not only limited to your team, but indeed expand to yourself and future contributors.
Want to learn more about Git and become a professional "version controller"? Check out these excellent resources:
- //try.github.io/
- //git-scm.com/book/en/v2
- //www.git-tower.com/learn/
- //learngitbranching.js.org/
- //github.com/commitizen/cz-cli