תהליך עבודה של בקרת גרסאות

כדי לעבוד עם קוד Android, צריך להשתמש ב-Git (מערכת לניהול גרסאות בקוד פתוח) וב-Repo (כלי לניהול מאגרי מידע ש-Google יצרה, שפועל על Git). במאמר כלים לניהול קוד מקור מוסבר על הקשר בין Repo ל-Git, ומופיעים קישורים למסמכי עזרה לכל אחד מהכלים.

Flow

תהליך העבודה הבסיסי בפיתוח ל-Android הוא:

1. מתחילים ענף חדש של נושא באמצעות repo start.
2. עורכים את הקבצים.
3. העברת שינויים לשלב ההכנה לביצוע באמצעות git add.
4. שומרים את השינויים באמצעות git commit.
5. מעלים את השינויים לשרת הבדיקה באמצעות repo upload.

Tasks

העבודה עם Git ו-Repo במאגרי הקוד של Android כוללת את המשימות הנפוצות הבאות.

פקודה	תיאור
repo init	יוצרת לקוח חדש.
repo sync	מסנכרנים את הלקוח עם המאגרים.
repo start	מתחילים ענף חדש.
repo status	הסטטוס של הענף הנוכחי.
repo upload	העלאת השינויים לשרת הבדיקה.
git add	הקבצים מועברים לאזור ההמתנה.
git commit	מבצעים קומיט לקבצים שהועברו לאזור ההכנה.
git branch	הצגת הענפים הנוכחיים.
git branch [branch]	יצירת ענף נושא חדש.
git checkout [branch]	הפונקציה מעבירה את HEAD לענף שצוין.
git merge [branch]	מיזוג של [branch] לתוך הענף הנוכחי.
git diff	הצגת ההבדלים בין השינויים שלא הועברו לאזור ההכנה.
git diff --cached	הצגת השוואה של השינויים שהועברו לאזור ההמתנה.
git log	הצגת ההיסטוריה של הענף הנוכחי.
git log m/[codeline]..	הצגת הקומיטים שלא נדחפו.

מידע על שימוש ב-Repo להורדת קוד המקור זמין במאמרים הורדת קוד המקור והפניה לפקודות Repo.

סנכרון לקוחות

כדי לסנכרן את הקבצים לכל הפרויקטים הזמינים:

repo sync

כדי לסנכרן את הקבצים של הפרויקטים שנבחרו:

repo sync PROJECT0 PROJECT1 ... PROJECTN

יצירת ענפים של נושאים

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

כדי להתחיל הסתעפות של נושא באמצעות Repo, עוברים לפרויקט ומריצים את הפקודה:

repo start BRANCH_NAME .

הנקודה בסוף ( .) מייצגת את הפרויקט בספריית העבודה הנוכחית.

כדי לוודא שהסניף החדש נוצר:

repo status .

שימוש בענפים לפי נושא

כדי להקצות את הענף לפרויקט ספציפי:

repo start BRANCH_NAME PROJECT_NAME

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

כדי לעבור להסתעפות אחרת בסביבת העבודה המקומית:

git checkout BRANCH_NAME

כדי לראות רשימה של ענפים קיימים:

git branch

או

repo branches

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

הערה: יכול להיות שבאג יגרום ל-repo sync לאפס את הענף המקומי של הנושא. אם אחרי שמריצים את הפקודה repo sync מופיע git branch * (no branch), מריצים שוב את הפקודה git checkout.

העברת קבצים ל-Staging

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

כדי להכין שינויים להעלאה:

git add

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

צפייה בסטטוס של הלקוח

כדי להציג את מצב הקבצים:

repo status

כדי לראות עריכות שלא נשמרו (עריכות מקומיות שלא סומנו לשמירה):

repo diff

כדי לראות עריכות שאושרו (עריכות שאותרו וסומנו לאישור), צריך לוודא שאתם בספריית הפרויקט ואז להריץ את הפקודה git diff עם הארגומנט cached:

cd ~/WORKING_DIRECTORY/PROJECT
git diff --cached

אישור השינויים

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

git commit

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

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

העלאת השינויים ל-Gerrit

מעדכנים לגרסה האחרונה ואז מעלים את השינוי:

repo sync
repo upload

הפקודות האלה מחזירות רשימה של שינויים שביצעתם ומבקשות מכם לבחור את הענפים להעלאה לשרת הבדיקה. אם יש רק ענף אחד, תופיע הנחיה פשוטה y/n.

פתרון בעיות שקשורות לסנכרון

אם הפקודה repo sync מחזירה קונפליקטים בסנכרון:

1. צפייה בקבצים שלא מוזגו (קוד סטטוס = U).
2. עורכים את האזורים שבהם יש התנגשות לפי הצורך.
3. עוברים לספריית הפרויקט הרלוונטית. מוסיפים את הקבצים המושפעים ושומרים אותם, ואז מבצעים rebase לשינויים:

   git add .
   git commit
   git rebase --continue
   

4. אחרי שה-rebase מסתיים, מתחילים שוב את כל הסנכרון:

   repo sync PROJECT0 PROJECT1 ... PROJECTN
   

ניקוי לקוחות

אחרי מיזוג השינויים ב-Gerrit, מעדכנים את ספריית העבודה המקומית ואז משתמשים בפקודה repo prune כדי להסיר בבטחה ענפים של נושאים לא רלוונטיים:

repo sync
repo prune

מחיקת לקוחות

מכיוון שכל פרטי המצב מאוחסנים בלקוח, צריך רק למחוק את הספרייה ממערכת הקבצים:

rm -rf WORKING_DIRECTORY

כשמוחקים לקוח, כל השינויים שלא העליתם לבדיקה נמחקים לצמיתות.