מה זה Pull Request ואיך כותבים אחד טוב¶
הפעם הראשונה שראיתי את המילים "Pull Request" חשבתי שזה איזשהו מונח טכני מסובך שרק מפתחים מנוסים מבינים. בפועל, זה אחד המושגים הכי פשוטים בעולם הפיתוח, ברגע שמישהו טורח להסביר אותו בלי ז'רגון.
אז מה זה בעצם Pull Request¶
Pull Request, או בקיצור PR, הוא בקשה מסודרת להכניס שינויים שעשיתם לענף קוד אחד, לתוך ענף אחר - כמעט תמיד מ-branch שלכם אל תוך ה-branch הראשי של הפרויקט. השם עצמו קצת מטעה, כי הוא בעצם אומר "אני מבקש שתמשכו (pull) את השינויים שלי פנימה", ולא ממש "אני מושך משהו".
זה לא מנגנון טכני של git עצמו, אלא תכונה שהוסיפו שירותים כמו GitHub ו-GitLab מעל git. הרעיון הוא לתת נקודת עצירה מסודרת בין "כתבתי קוד" לבין "הקוד שלי עכשיו חלק מהפרויקט הראשי" - נקודה שבה מישהו יכול לבדוק, להעיר, ולאשר לפני שהשינוי נכנס.
איך הזרימה נראית בפועל¶
התהליך הרגיל נראה בערך ככה:
- יוצרים branch חדש מתוך הקוד העדכני, ייעודי לשינוי הספציפי שאתם עובדים עליו.
- עובדים ועושים commits על ה-branch הזה, בלי לגעת בקוד הראשי.
- דוחפים (push) את ה-branch לשרת המרוחק.
- פותחים Pull Request דרך האתר, שמשווה בין ה-branch שלכם לבין הראשי ומראה בדיוק מה השתנה.
- מישהו סוקר את הקוד, אולי מבקש שינויים, ואתם מעדכנים לפי ההערות.
- ה-PR מתמזג (merge) לתוך הענף הראשי, וההיסטוריה נשמרת לתמיד.
זה בדיוק המנגנון שמאפשר לפרויקטים עם עשרות ומאות תורמים לשמור על קוד יציב, למרות שכולם עובדים במקביל.
איך כותבים Pull Request שמישהו ישמח לקרוא¶
זה החלק שרוב המדריכים מדלגים עליו, וזה בדיוק החלק שקובע אם ה-PR שלכם ייבדק תוך יום או ייתקע בשכחה במשך שבועיים.
כותרת ברורה. לא "תיקונים" ולא "שינויים קטנים". כותרת שמסבירה במשפט אחד מה ה-PR עושה, כמו "מוסיף ולידציה לשדה האימייל בטופס הרשמה".
תיאור עם הקשר. מה השתנה, למה זה היה צריך להשתנות, ואיך בודקים שזה עובד. מי שסוקר לא נמצא בראש שלכם, ולא יודע למה החלטתם לעשות דווקא ככה.
PR קטן ומרוכז. זו אולי העצה הכי חשובה. PR שמשנה 800 שורות בעשרה קבצים שונים כמעט בלתי אפשרי לבדוק ברצינות. PR שמשנה דבר אחד ברור, קל לסקור, קל לאשר, וקל לתקן אם משהו לא בסדר. אם תפסתם את עצמכם עושים יותר מדי דברים באותו PR, כנראה שווה לפצל.
סקרו את עצמכם קודם. לפני שאתם שולחים, עברו על השינויים שלכם כאילו מישהו אחר כתב אותם. תתפסו לבד שורות דיבוג ששכחתם, קוד מוער שנשאר בטעות, או שינוי שבכלל לא היה קשור למטרה של ה-PR.
מה קורה כשמבקשים ממכם לשנות¶
לקבל הערות על PR זה חלק טבעי מהתהליך, לא סימן שעשיתם משהו רע. גם מתכנתים הכי מנוסים מקבלים בקשות לשינוי בכל PR שהם פותחים. הדרך הנכונה להגיב היא לא להתגונן, אלא לשאול אם לא ברור למה, ולתקן. זה בדיוק המנגנון שהופך קוד טוב לקוד מצוין, ובדרך גם הופך אתכם למתכנתים טובים יותר.
מה זה fork ומתי צריך את זה¶
בפרויקטים שאתם לא חלק מהצוות שלהם - למשל תרומה לפרויקט קוד פתוח - בדרך כלל אין לכם הרשאה ליצור branch ישירות בתוך ה-repo המקורי. הפתרון הוא fork, שהוא בעצם עותק אישי משלכם של כל ה-repo, שעליו כן יש לכם הרשאות מלאות. אתם עובדים על ה-fork, ואז פותחים PR מה-fork שלכם חזרה אל הפרויקט המקורי.
מי שרוצה לתרגל את הזרימה הזו על פרויקטים אמיתיים, כדאי שיהיה לו קודם בסיס יציב בגיט ובתכנות.
התחילו את קורס התכנות הבסיסי כאן
לסיכום¶
Pull Request הוא לא טופס בירוקרטי, הוא שיחה מובנית על קוד. ככל שתכתבו PR ברורים יותר, קטנים יותר, ומתועדים יותר, כך יקל יותר על אנשים לעזור לכם לשפר את הקוד, ותלמדו מהר יותר.
הפעם הראשונה תמיד מרגישה מלחיצה. בדיסקורד יש אנשים שישמחו לעבור איתכם על ה-PR הראשון שלכם ולתת פידבק לפני שאתם שולחים אותו החוצה.