עבודה עם גיטהאב

במאמר הקודם דיברתי על git rebase מול git merge. במאמר הזה אני לוקח את כל מה שלמדנו עליו במאמרים הקודמים ואני אדגים איך ניצלתי את הידע הזה כשתרמתי קוד בגיטהאב. אני מסביר על פרויקט של grunt\node.js בגיטהאב, אבל כמובן שלא נדרש ידע כלל ב-node בשביל להבין מה אני עושה. הקוד עצמו לא משנה, משנה הפעילות בגיט.

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

על מנת שאני אוכל להתחיל לעבוד על הפרויקט, אני צריך שתהיה לי גרסה משלי, שאני יכול להכניס אליה תוכן. אני לא יכול לדחוף קוד ל-repository שהוא לא שלי. אלחץ על כפתור ה-fork.

כפתור Fork

מיד אחרי הלחיצה, תיווצר גרסה משלי ל-repo. הגרסה הזו זהה אחד לאחד לגרסה המקורית, אבל עם הבדל משמעותי אחד – ה-repo שלי הוא שלי ואני יכול לשנות אותו. עכשיו אני נכנס למחשב המקומי שלי על מנת שאוכל לבצע שינויים בקוד. איך אעשה את זה? באמצעות clone, על clone למדנו במאמר מוקדם יותר על git.

ניתן לעשות git clone עם הכתובת של ה-repo ב-SSH או ב-HTTPS. מדובר בשיטות שונות של התחברות, למרות שיותר נוח להשתמש ב-SSH, במדריך עצמו נשתמש ב-HTTPS ואת ה-SSH נשמור למאמר אחר.

git clone https://github.com/barzik/grunt-email-boilerplate.git

clone example

עכשיו אני מבצע את השינויים, נשים לב שיש כמה ענפים ב-repo, על מנת לעבור ביניהם אני יכול לכתוב git co BRANCHNAME. יש פרויקטים שמבקשים לדחוף את כל השינויים ל-develop, יש כאלו שיעדיפו להיות ב-master, יש כאלו שיבקשו לשים את זה בענף נפרד. אם אתם לא בטוחים, אפשר להסתכל על לוג השינויים או לשאול את המפתח. במקרה הזה, ראיתי שמדובר בפרויקט קטן אז החלטתי לדחוף את השינויים שלי אל ה-master.

אחרי שביצעתי את השינויים, אעשה commit. על ה-commit דיברנו במאמר קודם ולא ארחיב עליו יותר מדי. בגדול:

$ git commit -m'Adding image as paths variable'
[master fc75522] Adding image as paths variable
 1 file changed, 11 insertions(+), 9 deletions(-)

אחרי שביצענו את השינוי, הגיעה העת לדחוף אותו. אני אעשה push ל-master שלי.

$ git push origin master
Counting objects: 10, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 463 bytes | 0 bytes/s, done.
Total 3 (delta 2), reused 0 (delta 0)
To [email protected]:barzik/grunt-email-boilerplate.git
   638a710..fc75522  master -> master

עכשיו ה-repo שלי שונה מה-repo המקורי:

ה-repo שלי מכיל את ה-commit שלי שלא נמצא ב-repo המקורי

אם אני מרוצה, אני יכול לבצע pull request, אכנס אל ה-repo שלי בגיטהאב ושם הממשק עצמו יציע לי לבצע pull request:

הצעה של pull request ב-GitHub

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

סקירת שינויים של ה-pull request

מה קורה אם יש לי קונפליקט? זה יכול לקרות אם עד שיצרתי את ה-pull request, הקוד המקורי שונה. במקרה הזה, אני צריך למשוך את השינויים שלי מהקוד המקורי באמצעות git pull או git rebase. איך אני עושה את זה? הרי ה-repo שאני מתעדכן ממנו הוא ה-repo שלי (barzik), לא ה-repo המקורי (dwightjack). התשובה היא פשוטה, אני צריך להגדיר remote נוסף שהוא לא origin. איך עושים את זה? פשוט:

git remote add upstream [email protected]:dwightjack/grunt-email-boerplate.git

אם אני אכניס את הפקודה git remote -v, אני אראה את כל המקורות שלי:

$ git remote -v
origin	[email protected]:barzik/grunt-email-boilerplate.git (fetch)
origin	[email protected]:barzik/grunt-email-boilerplate.git (push)
upstream	[email protected]:dwightjack/grunt-email-boilerplate.git (fetch)
upstream	[email protected]:dwightjack/grunt-email-boilerplate.git (push)

הפקודה git pull upstream master תביא אלי את ה-master של ה-repository של dwightjack. אני יכול לעשות כמובן rebase או pull & merge. אחרי שביצעתי את יישוב הקונפליקטים/ העדכון, אני אדחוף את הכל שוב ל-master שלי (origin) ואחזור לשלב ה-pull request.

אחרי סקירת השינויים, אני אכתוב מסר למתחזק ה-repository, חשוב שהמסר יהיה בהיר ויסביר את מהות השינויים. במקרה הזה, מדובר בשינוי פשוט, אז לא כתבתי יותר מדי.

הודעת pull request

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

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

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

במאמר הבא ב-GitHub אנחנו נדבר על git alias.