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

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

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

‍

?אז מה בדיוק עושים עם הפיצ'ר הזה

מדובר במסמך שאמור להכיל הוראות בנוגע לאופן שבו תורמים קוד ל- repository שלכם. אלו יכולים להיות הסברים טכניים על סביבת העבודה, 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.

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

‍

‍

‍

באופן בולטpull request הצגת המסמך בכל

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

‍

pull request -הצגת משימות ב

אני מאמין שבכל מקום יש את תהליך הפול ריקווסט – השלב שבו מפתח אחר (לאו דווקא בכיר יותר) קורא את הקוד שלך. כפי שראש הצוות שלי נוהג לומר – זה לא ״אישור״ אלא קריאה וחוות דעת נוספת. מדובר בחלק חשוב ממעגל התרומה לקוד. אם תהליך ה-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.

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

‍

‍

‍

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

‍

‍

מאת: רן בר זיק, מתכנת ובלוגר

‍