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

כדי לעבוד עם קוד 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

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

מתחילים הסתעפות של נושא בסביבת העבודה המקומית בכל פעם שמתחילים שינוי, למשל כשמתחילים לעבוד על באג או על תכונה חדשה. ענף נושאי לא מהווה עותק של הקבצים המקוריים, אלא מצביע על קומיט מסוים, ולכן יצירת ענפים מקומיים ומעבר ביניהם היא פעולה קלה. כשמשתמשים בענפים, אפשר לבודד היבט אחד של העבודה מהיבטים אחרים. מאמר מעניין על שימוש בענפים של נושאים אפשר לקרוא במאמר Separating topic branches (הפרדה בין ענפים של נושאים).

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

repo start BRANCH_NAME .

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

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

repo status .

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

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

repo start BRANCH_NAME PROJECT_NAME

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

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

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

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