Git – יצירת pull request

במאמר הקודם למדנו על יצירת ענף חדש – ראשית מקומית (באמצעות branch -b) ואז בשרת (באמצעות git push). נותרו לנו כמה שאלות פתוחות – הראשונה היא עדכון הענף שלי. נניח והתפצלתי מה-master אל develop. בינתיים מישהו אחר עידכן את ה-master. איך אני מבצע עדכון? יש כמה דרכים לעשות את זה. הדרך הפשוטה יותר היא לבצע משיכה של הענף אלי באמצעות pull.

מה זאת אומרת? יש repo מרוחק ויש את הגרסה המקומית שלנו. בגרסה המקומית שלנו אנו עורכים שינויים, בגרסה המרוחקת מישהו עשה שינויים (או יותר נכון: עשה שינויים אצלו ודחף אותם לגרסה שיש בשרת). אני רוצה לעדכן את הגרסה שלי. אם אני עושה push ואין קונפליקטים, הכל בסדר. אם אני עושה git push origin master ויש קונפליקטים, אקבל שגיאה וייאמר לי שיש לי קונפליקטים עם המקור. מה בדיוק בשביל זה, אני חייב לעשות:

git pull origin master

מה יש שם? git pull הוא מוכר, ה-origin הוא השם של השרת המרוחק כפי שהוא בדרך כלל מוגדר. master הוא שם של ה-branch:

מייד כל הקומיטים שנעשו לשרת המרוחק נמשכים אלי ואם יש קונפליקטים (ויש), הם יוצגו בדיוק כמו ב-SVN. אני נדרש לבצע תהליך resolve (בדיוק כמו ב-SVN) ואחרי כן, לבצע add ו-commit לתיקונים עצמם שנחשבים שינוי קוד. איך זה נראה? בדיוק ככה:

כלומר, כל פעם שאני מושך קוד, הקומיטים המרוחקים בעצם נמשכים אלי ומוצבים על השינויים שלי. אם יש קונפליקטים, הפתרון שלהם מוצב על הקומיטים שלי ועל הקומיטים המרוחקים. ואז אני צריך לעשות git push origin master וה-push יתקבל.

אם אני עושה git pull origin master לפני שאני אדחוף ולא יהיו קונפליקטים, מן הסתם לא אצטרך לפתור, אבל כאשר אני אעשה push, בלוג אני אראה שיש לי קומיט ריק. נשאלת השאלה למה? התשובה היא שכאשר אני עושה git pull אני תמיד תמיד לא רק מביא את השינויים מהגרסה המרוחקת, אלא גם עושה merge וזה חייב להרשם בלוג גם אם אין שום קונפליקט. יש דרך להמנע מזה והיא נקראת rebase. אדבר עליה במאמר הבא.

אם אנחנו יודעים למשוך repo מרוחק, לבצע שינויים, לעדכן אותו באופן סדיר וגם לדחוף אותו ל-master. הגיע הזמן לדעת איך עושים אותו בעולם האמיתי. בעולם האמיתי לעולם לעולם לא דוחפים קוד ישירות לתוך ה-master או ה-develop או ענף מרכזי אחר. כל השינויים בענפים מרכזיים נעשים באמצעות pull requets. כאשר כל השינויים לענפים המרכזיים לא נעשים עם push אלא אך ורק עם merge.

איך עושים את זה? נניח ויש לי master שהוא הגרסה המרכזית. אני רוצה להוסיף תכונה כלשהי. אני אפתח את ה-master אצלי באמצעות clone או (אם יש לי את master במחשב) אני אעדכן אותו באמצעות pull. אחרי זה אני אצור ממנו ענף באמצעות checkout -b. אני מבצע את השינויים בקוד שנדרשים על מנת להוסיף את התכונה, דוחף את השינויים כענף מרוחק. אם יש לי גיטהאב, באמצעות הממשק הגרפי אני מבקש pull request. אם יש לי מערכת אחרת (כמו stash) אני מבצע את ה-pull request באמצעות המערכת הזו. זה שיש לו את הרשאות הכתיבה ל-master בוחן את הקוד, יכול להעיר את ההערות שלו, אני יכול לתקן (ולדחוף את התיקונים לאותו branch כמובן) ואחרי שהכל תקין, ה-pull request יאושר והגרסה שלי תתמזג עם ה-master.

ה-pull request נעשה תמיד מול המערכת שמנהלת את ה-git ותמיד נעשה באופן גרפי. ב-pull request מקובל לכתוב בדיוק למה הוא נעשה ואיזה שינויים נעשו בקוד. בדרך כלל במערכת אפשר גם לראות את השינויים השונים בקבצים. המערכת הזו מאוד נוחה כאשר עוסקים בפרויקטים בקוד פתוח.

במאמר הבא אנו נלמד על rebase ואיך הוא שונה באופן מהותי מ-git pull.