פיצ׳רים בגיטהאב שלא הכרתם

מסתבר שיש כמה שינויים חדשים ומגניבים במיוחד בגיטהאב שלא כולם מכירים וכשאני אומר לא כולם אני מתכוון לעצמי. אז אם אתם עובדים עם גיטהאב או עם ביטבאקט, יש סיכוי שזה יסייע לכם מאוד, אבל מאוד.

אני מאמין שרוב הקוראים פה משתמשים בגיט על מנת לכתוב את הקוד שלהם. בין אם מדובר בחברת ענק ובין אם מדובר במפתח הבודד – כולנו צריכים להשתמש ב version control וגיט הוא הדרך שנחשבת ממש סטנדרט בתחום. (אם אתם לא יודעים בכלל על מה אני מדבר, אין מה להתבייש – קראו כאן על גיט).  למרות שיש אנשים שמחזיקים שרתי גיט, חלק גדול מהאוכלוסיה משתמשים בגיטהאב. בין אם מדובר בגיטהאב אנטרפרייז או גיטהאב בתשלום או אפילו גיטהאב חינמי. בסופו של דבר זה גיטהאב או ביטבאקט והפיצ׳ר הזה קיים בשניהם.

הפיצ׳ר החשוב שאני רוצה לדבר עליו הוא CONTRIBUTING.md. מה זה? מדובר במסמך שאמור להכיל הוראות בנוגע לאיך תורמים קוד לריפוזיטורי שלכם. זה יכול להיות הסברים טכניים על סביבת העבודה, onbaording, פתרון בעיות – הכל. בתחום הקוד הפתוח מקובל לשים שם code of conduct- סט כללים מחייב שמתחייבים אליו בנוגע ליחס ולאווירה בפרויקט הקוד הפתוח.

בפרויקט בחברה שלי זה הכל: הסברים טכניים, onboarding וגם הסברים על התנהלות מכבדת ומכובדת. הנה למשל דוגמה:

# Contributing

When contributing to this repository, Make sure that your change is documented in JIRA item. please first discuss the change you wish to make via Slack,
email, or any other method with the owners of this repository before making a change. 

## Git process
We are using git and we are using git over ssh\https. In order to setup Git Enterprise, please  [Read git documentation](docs/git.md). You can find there information on the git flow as well.

## Pull Request Process
1. Ensure any install or build dependencies are removed before the end of the layer when doing a 
   build.
2. Update the documentation with details of changes to the interface, this includes new environment 
   variables, exposed ports, useful file locations and container parameters.
3. Follow the [versions policy](docs/versions.md).
4. You may merge the Pull Request in once you have the sign-off of other developers, if you 
   do not have permission to do that, you may request the reviewer to merge it for you.

## Best practice
We have a [best practice](docs/best-practice.md) guide that you should read before development. The guide is focused on code readability, clarity, and security.

## Build
We use Jenkins for our build system. If the build fails, please read [the guide on what to do in case of build failure](docs/build-help.md). 

## Best practice
We have a [best practice](docs/best-practice.md) guide that you should read before development. The guide is focused on code readability, clarity, and security.

## Code of Conduct
All pull requests and communications around this project should be in compliance with the company code of conduct. Please remember to maintain positive environment.

- Using welcoming and inclusive language
- Being respectful of differing viewpoints and experiences
- Gracefully accepting constructive criticism
- Showing empathy towards other contributers.

אפשר לראות שמדובר במסמך נאה שעושה סדר ומוביל למסמכים נוספים. ברגע שאני שם אותו בתיקיה הראשית, כל מפתח – גם מתחיל וגם מנוסה, יכול לפתוח אותו. אם אתם נכנסים לפרויקט קוד פתוח, חפשו את המסמך הזה קודם. אבל מה השוס הגדול? שבגיטהאב אם תנסו לעשות פול ריקווסט לריפוזיטורי שיש בו את המסמך הזה – תראו את הפלא הבא:

ותודו שזה מגניב במיוחד. במיוחד אם אתם מנהלים פרויקט תשתיתי שכמה צוותים משתמשים בו. זה באמת לוקח את הדוקומנטציה שלכם לרמה גבוהה הרבה יותר.

נמשיך?

הצגת משימות בפול ריקווסט

אני מאמין שבכל מקום יש את תהליך הפול ריקווסט – השלב שבו מפתח אחר (לאו דווקא בכיר יותר) קורא את הקוד שלך. כפי שראש הצוות שלי, ערן שפירא, נוהג לומר – זה לא ״אישור״ אלא קריאה וחוות דעת נוספת. מדובר בחלק חשוב ממעגל התרומה לקוד. אם תהליך ה-CI שלי מספיק טוב, אני לא צריך להקפיד בפול ריקווסט על שטויות כמו רווחים, נקודה פסיק והערות כי ה-Static code analysis מטפל בזה. אבל יש דברים אחרים שחשוב לי שהמפתח שקורא את הקוד ישים לב אליהם. למשל שהפול ריקווסט יהיה עם תוכן ומשמעות. או שאין eslint-disable בקוד – כל אחד עם מה שחשוב לו. 

אם תשימו בתיקית docs קובץ שנקרא docs/pull_request_template.md – הטמפלייט הזה יופיע בכל פול ריקווסט. רגע, יש עוד – אם תשימו צ׳ק ליסט:

- [ ] The pull request has at least a `What's New?` text and make sure that the subject has meaning.
- [ ] Never allow unnecessary use of `eslint-disable`.
- [ ] Tests are added to all new functionality.

הוא יופיע בבקשה, הבודק יוכל למלא אותו ואפשר לראות בפול ריקווסט עצמו אם הבודק מילא את הסעיפים וכמה מהם. אל תגידו שזה לא גאוני.

יש עוד כמה פיצ׳רים מגניבים שלא ידעתי עליהם, אבל הדבר שלעיל פוצץ לי את הראש. זה לא ממש קוד – אבל אני מאמין שדוקומנטציה טובה ותהליכים טובים הם אבן היסוד של כל קוד טוב.