Git הוא כלי לניהול גרסאות (Version Control System) הפופולרי למדי בימים אלו.
בניגוד ל (Subversion (SVN או Perforce שהם כלים בעלי ניהול מרכזי, ל Git יש ניהול מבוזר.
משמעות אחת היא שבמקום שיהיה איש Operations מאחורי הקלעים שינהל את שרת ה SVN ויחסוך חשיבה למתכנתים ברוב הסוגיות הקשורות ל Source Control - כעת על המפתחים לדאוג לנושא זה בעצמם (לפחות במידה מסוימת).
משמעות אחרת היא שיש למפתחים יותר כוח לנהל את הקוד בצורה הטובה להם, לבצע פיתוחים ו merges הדרגתיים ובסה"כ להתנהל בצורה יותר יעילה.
היעילות ב Git לא מגיעה מייד. החוויה הראשונה היא כנראה שלילית לרבים המפתחים: מפתח שלא היה טרוד בענייני ה Source Control צריך לפתע פתאום ללמוד נושא חדש ולהגיע בו לרמה סבירה. השימוש ב Git הוא מורכב יותר ודורש לא-מעט אימון והעמקה. כל התהליך יכול לקחת כמה חודשים טובים.
בסה"כ Git (וכלי ניהול גרסאות מבוזרים בכלל) נחשב לתומך בפיתוח Agile המאפשר גמישות לנהל releases שתוכנם נקבע בשלב מאוחר, לעבוד בשיתוף עם מפתחים אחרים - מבלי להפריע לשאר המפתחים, לבצע שינויים משמעותיים בבסיס הקוד, ועוד. במקרים רבים ארגונים מאמצים Git בעיקר בכדי "לזרז את ה Agile".
בפוסט זה אנסה להסביר את המבנה / התנהגות של גיט קצת יותר לעומק - באופן שייסע להגיע לשלב הפרודקטיביות בכלי.
Ich bin Lior, משמעו: I am Lior.
Das ist gut, משמעו: This is good.
מצד שני הדמיון גם מטעה, וגורם לנו להניח הנחות שגויות - שיבלבלו אותנו (אדלג על הדוגמאות :) ). גיט היא אותו הדבר. אם אתם מגיעים מ SVN, Perforce או כלי דומה - כמה מהמונחים ישמעו לכם מוכרים מייד. היזהרו מהנחות אלו ונסו לא לקפוץ מהר למסקנות.
תיקיית גיט על המחשב בה יש עותק של פרויקט נקראת "Git Repository". כל Repository (כלומר: בכל מכונת פיתוח) כולל את ההיסטוריה, של כל הקבצים מאז שהפרויקט נוצר. אל דאגה: גיט דוחס את המידע ומאכסן אותו בצורה יעילה כך שהוא לא תופס הרבה מקום. בשל העבודה שה Repository הוא מקומי על הדיסק שלכם - תגלו שגיט מהיר באופן מורגש מ Repository מרכזיים שעבדתם איתם בעבר.
ה Commit Graph בגיט, מורכב מה commits השונים (ריבועים בציור למעלה) - כל אחד כולל snapshot של כל הפרויקט ברגע מסוים, וחצים - המייצגים קשר בין commits. למשל: B הוא בן של A: מישהו עבד על A, שינה אותו ואז ביצע commit ל B.
Branch בגיט מוגדר כשרשרת כל parent commits של ה tip (קצה) של ה Branch. כלומר:
ה Branch הראשון שנוצר ב Git Repository נקרא master, אולם הוא לא שונה במאומה מכל מכל branch אחר שתיצרו מאוחר יותר - זה רק שם ברירת-מחדל.
אם אתם לא רגילים לגיט, לבצע commit כל כמה דקות נשמע מוזר - אבל זה עניין שמתרגלים אליו :).
כמובן, שהייעוד העיקרי של גיט הוא עבודה בצוות. גיט מאפשר לשתף עבודה בין Repositories:
פעולת ה "clone" תשכפל את ה Repository המרוחק ותייצר Repository מקומי זהה על המחשב שלכם. זהה = מכיל את כל הקבצים, כל ה Branches וכל ההיסטוריה מרגע יצירת הפרויקט.
פעולת Push דוחפת (commit(s מה Repository שלכם למרוחק ו Pull מביאה (commit(s מה Repository המרוחק אליכם.
ניתן לעבוד עם גיט בצורה מבוזרת לגמרי, אולם כל המימושים שאני ראיתי עד היום (דיסקליימר: מפתחים שהגיעו לגיט מ SVN או Perforce) כללו Repository מרכזי עליו כל המפתחים מסנכרנים את הקוד. לא שונה משרת המרכזי של Perforce, למשל.
ה Object Store מאכסן 4 סוגים של אובייקטים. הנה הקשרים הלוגיים ביניהם:
האובייקט הבולט ביותר הוא כמובן אובייקט ה Commit, המשמש כ Aggregator לתת העץ של כל הספריות והקבצים באותו ה Commit.
ה Commit מצביע לעץ (Tree) אחד, שהוא ה Root Directory של תתי-הספריות (עצים) וקבצים (BLOBs) שהם חלק מה Commit.
כל BLOB ב Object Store מייצג קובץ, יהיה זה קובץ קוד (למשל java.) או קובץ נתונים אחר (למשל תמונה בפורמט png.). תוכן הקובץ עובר פונקציית Hash בשם SHA-1 המייצרת מספר בן 160bit המתאר את תוכן הקובץ. פונקציית SHA-1 היא פונקציית hash בעלת פיזור אחיד למדי (מקורה בעולם האבטחה) - ואנו מניחים שהיא מזהה תוכן של קובץ באופן ייחודי. ב UI של גיט נראה את ה hash בייצוג הקסדצימלי, למשל:
12cfb1862b23356523d88127fa5d5aeb333950
לעתים נראה קיצור של ה hash בצורת 7 הספרות הראשונות שלו - לרוב זהו ייצוג ייחודי דיו בכדי לזהות אובייקט בצורה אמינה (וגם: קל הרבה יותר להקלדה).
גיט מזהה כל קובץ ע"פ התוכן שלו (לא ע"פ שם הקובץ, סיומת או תאריך) - כלומר, ע"פ ה hash שלו. זאת אומרת ש Tree בעצם מכיל רשימת hashes של קבצים, המתארת את הקבצים בספרייה, ומייצא בעצמו hash של ערכים אלו. ה Commit מקבל ה hash המחושב מה hash של תיקיית ה root של הפרויקט + כמה שדות.
אם הקובץ(כלומר התוכן, בפנים) לא השתנה, אזי ה hash שלו יישאר זהה, וגיט לא תאכסן עותק חדש שלו ב Object Store. מספיק שביט אחד בקובץ השתנה (למשל: ריווחים בקוד) בכדי שעבור גיט זה יהיה אובייקט BLOB חדש לגמרי, בעל hash שונה לחלוטין שמאוחסן בשלמותו (ולא deltas).
באופן דומה, העצים הם hash של כל ה hashes של העצים / קבצים שהם מכילים. אם כל הקבצים בתת-עץ לא השתנו, אזי אובייקט ה Tree שמייצג אותם יישאר עם אותו ה hash וכן הלאה.
זיהוי אובייקטים ע"פ hash מאפשר לגיט לבצע השוואות מהירות בין אובייקטים ובין תתי-עצים של אובייקטים: פשוט יש להשוות בין שני hashes.
commit message
parents
committer vs. author
דוגמה אחת לכך היא cherry-pick, היכולת לקחת שינויים של commit ולהעתיק רק אותם (כלומר: את השינויים) ל branch אחר. יכולת זו היא רבת-עוצמה כאשר רוצים להעביר בין ענפים תיקוני-באגים. יכולות אחרות הן filter-branch ("שכתוב היסטוריה") ו rebase (חיתוך ענף, והדבקה שלו במקום אחר). במקרים אלו יהיה ניתן להבחין בין האדם שביצע את הפעולה (committer) לבין ה committer של הקוד המקורי (author).
תהליך העדכון קבצים ל Git Repository מתבצע בשני שלבים:
האינדקס יכול להיות מבלבל לפעמים: רבים מדמיינים אותו כ snapshot הנוכחי של הפרויקט - אבל זה לא המצב. ה snapshot הנוכחי של הפרויקט לא מנוהל ע"י גיט - גיט סורק את תיקיות הפרויקט ברגע שהוא צריך (למשל: בעת הפעלת פקודת git status) כדי לדעת מה השתנה.
האינדקס הוא מבנה נתונים נוסף של גיט, שמנותק ממצב הקבצים במערכת הקבצים (נקרא בעולם הגיט "Working tree)" ו/או מה Commit האחרון. הוא פשוט מילון של pathnames ו hashes של אובייקטים ב Object Store, כלומר <pathname, hash>.
כאשר אנו מבצעים פעולת git status (או git status --short), או רואים השוואה בין התיקייה המקומית והאינדקס.
בשלב הראשון גיט יציג לנו קבצים שהשתנו במערכת הקבצים, אבל לא מנוהלים ("tracking") ע"י האינדקס:
הערה: git stat הוא alias שיצרתי לפקודה git status --short. לא נראה לי הגיוני שהגרסה הקצרה של הפקודה, ארוכה יותר להקלדה מהגרסה הארוכה של הפקודה. לכן יצרתי ה alias באופן הבא:
ברגע שנבצע פעולת git add לקבצים - הם ייווספו לאינדקס:
כעת אני רואה שהקובץ התווסף לאינדקס (עמודה ירוקה, A הוא קיצור של Add).
כדי לראות אלו קבצים נמצאים באינדקס - פשוט הקלידו git ls-files.
כמה דקות לאחר מכן אני מבצע git stat ומקבל את המצב הבא:
מה זה המצב הדו-פרצופי הזה - מישהו יודע?
הקובץ השתנה או התווסף? מדוע אדום וירוק יחדיו?
מה שקרה הוא שגיט השווה בין תוכן הקובץ (ה hash שנוצר) במערכת הקבצים, לזה שמתואר ע"י האינדקס ושמור אצלו ב Object Store. הקובץ השתנה. גיט מדווח בצבע ירוק את המצב ב Object Store (הקובץ נוסף) ובאדום את המצב בדיסק (הקובץ השתנה, יחסית ל Object Store).
אם נבצע git commit בשלב זה, העותק שהוספנו קודם לכן לאינדקס (ונשמר ב Object Store) יכנס ל Repository, בעוד השינויים שביצעו לאחר מכן - יישארו במערכת הקבצים.
לאחר ה commit, פעולת Git Stat תראה רק את השינוי שבדיסק (הקובץ יוותר במעקב):
עוד טיפ קטן:
לי זה עזר.
אם אתם רוצים לבצע היפוך ("revert" בשפת perforce) לשינוי בקובץ, עליכם פשוט לבצע <git checkout <filename. כפי שהזהרתי בהקדמה על השפה הגרמנית - פעולת git revert עושה משהו לגמרי אחר (והרסני).
מהו Branch?
כבר אמרנו ש Branch מוגדר כאוסף ה commits שניתן להגיע אליהם מה tip (הקצה) של ה Branch.
הגדרה נוספת ומשלימה הוא ש Branch הוא מצביע ל commit, ומנקודה זו מוגדר ה branch.
גיט מחזיק במבנה נתונים נוסף: refs (קיצור של References, נקרא גם Pointer לפעמים). יש בגיט 2 סוגי מצביעים:
commit E הוא לא חלק מה branch. ניתן לפתור מצב זה ע"י יצירת branch חדש מהנקודה הנוכחית ע"י
פקודת <git checkout -b <new branch name ואולי אח"כ לבצע merge בין ה branch החדש ל dev. אם לאחר זמן ממושך לא "תטפלו" ב commits שאינם שייכים ל branch כלשהו - גיט ינקה אותם בתהליך "ניקוי הזבל" שלו.
שיהיה בהצלחה!
-----
קישורים רלוונטיים
GitGuys - מקור טוב להבנת המבנה של גיט:
http://www.gitguys.com/topics/
Git cheat sheet - רפרנס ויזואלי של הפקודות הנפוצות וההשפעות שלהן:
http://www.ndpsoftware.com/git-cheatsheet.html#loc=remote_repo;
UnGit - כלי ויזואלי שעוזר ללמוד גיט:
https://github.com/FredrikNoren/ungit
Learn Git Branching - אתר טוב שמציע "משחק" שיסייע לכם לעקוב אחר branching מתקדם בגיט - נחמד מאוד.
http://pcottle.github.io/learnGitBranching/
כלי UI טוב מהרגיל לגיט (שומר על השפה של גיט) - SourceTree:
לינק מעניין: לינוס מציג את גיט ב 2007.
אוסף נחמד של מדריכי וידאו לגיט: http://training.github.com/resources/videos/
בניגוד ל (Subversion (SVN או Perforce שהם כלים בעלי ניהול מרכזי, ל Git יש ניהול מבוזר.
משמעות אחת היא שבמקום שיהיה איש Operations מאחורי הקלעים שינהל את שרת ה SVN ויחסוך חשיבה למתכנתים ברוב הסוגיות הקשורות ל Source Control - כעת על המפתחים לדאוג לנושא זה בעצמם (לפחות במידה מסוימת).
משמעות אחרת היא שיש למפתחים יותר כוח לנהל את הקוד בצורה הטובה להם, לבצע פיתוחים ו merges הדרגתיים ובסה"כ להתנהל בצורה יותר יעילה.
היעילות ב Git לא מגיעה מייד. החוויה הראשונה היא כנראה שלילית לרבים המפתחים: מפתח שלא היה טרוד בענייני ה Source Control צריך לפתע פתאום ללמוד נושא חדש ולהגיע בו לרמה סבירה. השימוש ב Git הוא מורכב יותר ודורש לא-מעט אימון והעמקה. כל התהליך יכול לקחת כמה חודשים טובים.
בסה"כ Git (וכלי ניהול גרסאות מבוזרים בכלל) נחשב לתומך בפיתוח Agile המאפשר גמישות לנהל releases שתוכנם נקבע בשלב מאוחר, לעבוד בשיתוף עם מפתחים אחרים - מבלי להפריע לשאר המפתחים, לבצע שינויים משמעותיים בבסיס הקוד, ועוד. במקרים רבים ארגונים מאמצים Git בעיקר בכדי "לזרז את ה Agile".
בפוסט זה אנסה להסביר את המבנה / התנהגות של גיט קצת יותר לעומק - באופן שייסע להגיע לשלב הפרודקטיביות בכלי.
 |
| גיט הוא פשוט להיט! מקור: סקר המפתחים של אקליפס 2013 |
קצת הגדרות
כשלומדים גרמנית (ניסיתי), מהר מאוד מזהים את הדמיון שלה לאנגלית:Ich bin Lior, משמעו: I am Lior.
Das ist gut, משמעו: This is good.
מצד שני הדמיון גם מטעה, וגורם לנו להניח הנחות שגויות - שיבלבלו אותנו (אדלג על הדוגמאות :) ). גיט היא אותו הדבר. אם אתם מגיעים מ SVN, Perforce או כלי דומה - כמה מהמונחים ישמעו לכם מוכרים מייד. היזהרו מהנחות אלו ונסו לא לקפוץ מהר למסקנות.
תיקיית גיט על המחשב בה יש עותק של פרויקט נקראת "Git Repository". כל Repository (כלומר: בכל מכונת פיתוח) כולל את ההיסטוריה, של כל הקבצים מאז שהפרויקט נוצר. אל דאגה: גיט דוחס את המידע ומאכסן אותו בצורה יעילה כך שהוא לא תופס הרבה מקום. בשל העבודה שה Repository הוא מקומי על הדיסק שלכם - תגלו שגיט מהיר באופן מורגש מ Repository מרכזיים שעבדתם איתם בעבר.
ה Commit Graph בגיט, מורכב מה commits השונים (ריבועים בציור למעלה) - כל אחד כולל snapshot של כל הפרויקט ברגע מסוים, וחצים - המייצגים קשר בין commits. למשל: B הוא בן של A: מישהו עבד על A, שינה אותו ואז ביצע commit ל B.
Branch בגיט מוגדר כשרשרת כל parent commits של ה tip (קצה) של ה Branch. כלומר:
- ה release Branch מכיל את A, B, C, E, G, H.
- ה master Branch מכיל את A, B, C, D, F, I, J, K. כן, commits יכולים להיות חברים ביותר מ Branch אחד.
- ה topic Branch מכיל את A, B, F, I, L, M.
ה Branch הראשון שנוצר ב Git Repository נקרא master, אולם הוא לא שונה במאומה מכל מכל branch אחר שתיצרו מאוחר יותר - זה רק שם ברירת-מחדל.
גיט מקומי וגיט מרוחק
יש טעם לעבוד על גיט מקומי-בלבד, נאמר: כאשר שאר הצוות שלכם עובד על SVN ואתם רוצים Repository שלכם שישמור את השינויים שעשיתם כל 5 עד 30 דקות של עבודה.אם אתם לא רגילים לגיט, לבצע commit כל כמה דקות נשמע מוזר - אבל זה עניין שמתרגלים אליו :).
כמובן, שהייעוד העיקרי של גיט הוא עבודה בצוות. גיט מאפשר לשתף עבודה בין Repositories:
פעולת ה "clone" תשכפל את ה Repository המרוחק ותייצר Repository מקומי זהה על המחשב שלכם. זהה = מכיל את כל הקבצים, כל ה Branches וכל ההיסטוריה מרגע יצירת הפרויקט.
פעולת Push דוחפת (commit(s מה Repository שלכם למרוחק ו Pull מביאה (commit(s מה Repository המרוחק אליכם.
ניתן לעבוד עם גיט בצורה מבוזרת לגמרי, אולם כל המימושים שאני ראיתי עד היום (דיסקליימר: מפתחים שהגיעו לגיט מ SVN או Perforce) כללו Repository מרכזי עליו כל המפתחים מסנכרנים את הקוד. לא שונה משרת המרכזי של Perforce, למשל.
 |
| לגיט יש עקומת למידה לא-קלה |
שכבת ה Persistence של גיט
שכבת אכסון הנתונים של גיט ידועה בשם The Object Store או Object Database. את התוכן שלה ניתן למצוא בפועל תחת הספרייה git/objects.(בעקבות פעולת git clone נוצרת תיקייה נסתרת בשם "git." ב path בו התבצעה הפעולה).ה Object Store מאכסן 4 סוגים של אובייקטים. הנה הקשרים הלוגיים ביניהם:
האובייקט הבולט ביותר הוא כמובן אובייקט ה Commit, המשמש כ Aggregator לתת העץ של כל הספריות והקבצים באותו ה Commit.
ה Commit מצביע לעץ (Tree) אחד, שהוא ה Root Directory של תתי-הספריות (עצים) וקבצים (BLOBs) שהם חלק מה Commit.
הערת צד: בוודאי מטרידה אתכם השאלה כיצד ענף (Branch) יכול להכיל משהו (Commit) שמצדו מכיל הרבה עצים (Trees) - הרי "ענף" הוא חלק מה"עץ". יש לכך 2 תשובות:
- Branch הוא ענף של ה "Commit Graph"', בעוד עץ (Tree) הוא ספרייה במערכת הקבצים של ה Commit הנוכחי.
- זו אכן טרמינולוגיה מבלבלת - היה עדיף לקרוא ל Tree פשוט Directory או Folder, על אף הקונוטציה הלא-רצויה למערכת ההפעלה חלונות (רחמנא ליצלן).
כל BLOB ב Object Store מייצג קובץ, יהיה זה קובץ קוד (למשל java.) או קובץ נתונים אחר (למשל תמונה בפורמט png.). תוכן הקובץ עובר פונקציית Hash בשם SHA-1 המייצרת מספר בן 160bit המתאר את תוכן הקובץ. פונקציית SHA-1 היא פונקציית hash בעלת פיזור אחיד למדי (מקורה בעולם האבטחה) - ואנו מניחים שהיא מזהה תוכן של קובץ באופן ייחודי. ב UI של גיט נראה את ה hash בייצוג הקסדצימלי, למשל:
12cfb1862b23356523d88127fa5d5aeb333950
לעתים נראה קיצור של ה hash בצורת 7 הספרות הראשונות שלו - לרוב זהו ייצוג ייחודי דיו בכדי לזהות אובייקט בצורה אמינה (וגם: קל הרבה יותר להקלדה).
גיט מזהה כל קובץ ע"פ התוכן שלו (לא ע"פ שם הקובץ, סיומת או תאריך) - כלומר, ע"פ ה hash שלו. זאת אומרת ש Tree בעצם מכיל רשימת hashes של קבצים, המתארת את הקבצים בספרייה, ומייצא בעצמו hash של ערכים אלו. ה Commit מקבל ה hash המחושב מה hash של תיקיית ה root של הפרויקט + כמה שדות.
אם הקובץ(כלומר התוכן, בפנים) לא השתנה, אזי ה hash שלו יישאר זהה, וגיט לא תאכסן עותק חדש שלו ב Object Store. מספיק שביט אחד בקובץ השתנה (למשל: ריווחים בקוד) בכדי שעבור גיט זה יהיה אובייקט BLOB חדש לגמרי, בעל hash שונה לחלוטין שמאוחסן בשלמותו (ולא deltas).
הערת צד: שמירת עותקים שלמים של קבצים היא החלטת Design של גיט הכוללת Tradeoff בין נפח אכסון ליעילות. כלי ניהול גרסאות רבים אחרים בחרו את האופציה השנייה. שווה לציין שהיתירות (redundancy) במקרה זה מגבירה את האמינות. אם היינו מחזיקים רק diffs, ו diff מסוים בשרשרת היה נפגם - היינו מאבדים את כל המשך השרשרת מאותו הרגע. באופן לא-מפתיע למדי, ניתן לראות דמיון רב בין החלטות התכנון של גיט ל פילוסופיית התכנון של יוניקס.
באופן דומה, העצים הם hash של כל ה hashes של העצים / קבצים שהם מכילים. אם כל הקבצים בתת-עץ לא השתנו, אזי אובייקט ה Tree שמייצג אותם יישאר עם אותו ה hash וכן הלאה.
זיהוי אובייקטים ע"פ hash מאפשר לגיט לבצע השוואות מהירות בין אובייקטים ובין תתי-עצים של אובייקטים: פשוט יש להשוות בין שני hashes.
כמה properties חשובים על אובייקט ה Commit:
commit message
הערת טקסט המסבירה מה כולל ה commit.
parents
מצביעים ל commits אחרים, קשר המגדיר את ה Commit Graph.
- אם ל commit יש יותר מהורה אחד (ניתן 3 או יותר) - אזי זהו merge בין ענפים (branches).
- אם ל commit אין parents, אזי ה commit הזה הוא ה Root Commit (ראשית ה Repository) או orphan commit - מין אופציה מתקדמת בגיט לייצר branch חדש עם קוד שלא קשור לענפים הקיימים ב Repository.
committer vs. author
לרוב ה committer וה author יהיה אותו אדם, מלבד כמה מקרים בהם מישהו מבצע commit מחודש לקוד שמישהו אחר עשה לו commit בעבר.
דוגמה אחת לכך היא cherry-pick, היכולת לקחת שינויים של commit ולהעתיק רק אותם (כלומר: את השינויים) ל branch אחר. יכולת זו היא רבת-עוצמה כאשר רוצים להעביר בין ענפים תיקוני-באגים. יכולות אחרות הן filter-branch ("שכתוב היסטוריה") ו rebase (חיתוך ענף, והדבקה שלו במקום אחר). במקרים אלו יהיה ניתן להבחין בין האדם שביצע את הפעולה (committer) לבין ה committer של הקוד המקורי (author).
ה Index
תהליך העדכון קבצים ל Git Repository מתבצע בשני שלבים:
- עדכון ה Index (נקרא גם "Staging Area" או "Directory Cache") בעדכון.
- ביצוע העדכונים מתוך ה Index ל Repository.
תהליך דו-שלבי זה נוצר בכדי לאפשר למתכנת לבצע Review על השינויים שלו ולשלוט מה בדיוק נכנס ל Repository.
האינדקס יכול להיות מבלבל לפעמים: רבים מדמיינים אותו כ snapshot הנוכחי של הפרויקט - אבל זה לא המצב. ה snapshot הנוכחי של הפרויקט לא מנוהל ע"י גיט - גיט סורק את תיקיות הפרויקט ברגע שהוא צריך (למשל: בעת הפעלת פקודת git status) כדי לדעת מה השתנה.
האינדקס הוא מבנה נתונים נוסף של גיט, שמנותק ממצב הקבצים במערכת הקבצים (נקרא בעולם הגיט "Working tree)" ו/או מה Commit האחרון. הוא פשוט מילון של pathnames ו hashes של אובייקטים ב Object Store, כלומר <pathname, hash>.
כאשר אנו מבצעים פעולת git status (או git status --short), או רואים השוואה בין התיקייה המקומית והאינדקס.
בשלב הראשון גיט יציג לנו קבצים שהשתנו במערכת הקבצים, אבל לא מנוהלים ("tracking") ע"י האינדקס:
הערה: git stat הוא alias שיצרתי לפקודה git status --short. לא נראה לי הגיוני שהגרסה הקצרה של הפקודה, ארוכה יותר להקלדה מהגרסה הארוכה של הפקודה. לכן יצרתי ה alias באופן הבא:
git config --global alias.stat "status --short"
ברגע שנבצע פעולת git add לקבצים - הם ייווספו לאינדקס:
- ה pathname יזכור איזה קובץ במעקב.
- תוכן הקובץ, כפי שהוא באותו הרגע, ישמר כ BLOB ב Object Store וה hash של אותו BLOB יישמר באינדקס.
הנה:
כעת אני רואה שהקובץ התווסף לאינדקס (עמודה ירוקה, A הוא קיצור של Add).
כדי לראות אלו קבצים נמצאים באינדקס - פשוט הקלידו git ls-files.
מה זה המצב הדו-פרצופי הזה - מישהו יודע?
הקובץ השתנה או התווסף? מדוע אדום וירוק יחדיו?
מה שקרה הוא שגיט השווה בין תוכן הקובץ (ה hash שנוצר) במערכת הקבצים, לזה שמתואר ע"י האינדקס ושמור אצלו ב Object Store. הקובץ השתנה. גיט מדווח בצבע ירוק את המצב ב Object Store (הקובץ נוסף) ובאדום את המצב בדיסק (הקובץ השתנה, יחסית ל Object Store).
אם נבצע git commit בשלב זה, העותק שהוספנו קודם לכן לאינדקס (ונשמר ב Object Store) יכנס ל Repository, בעוד השינויים שביצעו לאחר מכן - יישארו במערכת הקבצים.
לאחר ה commit, פעולת Git Stat תראה רק את השינוי שבדיסק (הקובץ יוותר במעקב):
עוד טיפ קטן:
- פעולת <git rm <filename מסירה קובץ מהאינדקס (כלומר - הוא לא יהיה במעקב) ומהדיסק: זו הדרך להעיף קובץ שאינכם מעוניינים בו מהפרויקט. במילים אחרות: הוסף קובץ להסרה - לאינדקס. בכלל ש rm נשמע ההיפך מ add - זו דרך מצוינת להתבלבל.
- לצורך הגנה, אם ניסיתם לבצע git rm על קובץ שנעשו בו שינויים - גיט יסרב ויציע לכם להוסיף cached-- .לא פעם הקשבתי לעצתו בשמחה - ומחקתי לעצמי כמה שינויים.
- פעולת <git reset <filename רק מסירה את הקובץ מהאינדקס - זו בעצם הפעולה ההופכית ל git add.
פתרון אפשרי לבלבול, יכול להיות להגדיר alias בשם remove, שיהיה ההופכי ל add:
git config --global alias.remove "reset"
לי זה עזר.
אם אתם רוצים לבצע היפוך ("revert" בשפת perforce) לשינוי בקובץ, עליכם פשוט לבצע <git checkout <filename. כפי שהזהרתי בהקדמה על השפה הגרמנית - פעולת git revert עושה משהו לגמרי אחר (והרסני).
ענפים
הפוסט מתארך, ולכן אסיים בנושא אחרון חשוב לפוסט זה: Branches.מהו Branch?
כבר אמרנו ש Branch מוגדר כאוסף ה commits שניתן להגיע אליהם מה tip (הקצה) של ה Branch.
הגדרה נוספת ומשלימה הוא ש Branch הוא מצביע ל commit, ומנקודה זו מוגדר ה branch.
גיט מחזיק במבנה נתונים נוסף: refs (קיצור של References, נקרא גם Pointer לפעמים). יש בגיט 2 סוגי מצביעים:
- מצביע ישיר, המצביע לאובייקט ב Object Store (לרוב זה יהיה commit או tag).
- מצביע סימבולי (symbolic ref) המצביע למצביע אחר. משהו כמו symbolic link במערכת ההפעלה.
גיט משתמש במצביעים כדי לתת שמות / לסמן דברים, ובמקרה שלנו - branches. כל אחד מה branches הוא פשוט מצביע שכזה.
לעתים יווצר מצב בו ה Repository המרוחק ("origin") יכיל branches שלא קיימים אצלנו. פקודת git pull מייבאת את ה commits - אך לא את המצביעים. פקודת git fetch מייבאת את המצביעים מה Repository המרוחק, מה שיראה אצלנו כ branches ו tags.
מצביע מיוחד הוא מצביע ה HEAD המסמן את המיקום הנוכחי שלנו ב Commit Graph. כאשר אנו מחליפים branch לעבודה ע"י פקודת <git checkout <branch name אנו מחליפים את HEAD להצביע על commit ו/או branch אחר.
ייתכן מצב בו HEAD לא יצביע על tip של branch אלא על commit אחר בגרף. מצב זה יתרחש, למשל, בעקבות ביצוע פקודת <git checkout <commit's hash. לאחר פעולה זו גיט יספק הזהרה שאתם במצב של detached HEAD - כלומר HEAD לא מצביע על ה tip commit - ולכן אינו מצביע על branch.
מצב זה, למרות שנראה מוזר, הוא תקין וניתן לבצע בו commits - מה שיוביל אותנו למצב הבא:
commit E הוא לא חלק מה branch. ניתן לפתור מצב זה ע"י יצירת branch חדש מהנקודה הנוכחית ע"י
פקודת <git checkout -b <new branch name ואולי אח"כ לבצע merge בין ה branch החדש ל dev. אם לאחר זמן ממושך לא "תטפלו" ב commits שאינם שייכים ל branch כלשהו - גיט ינקה אותם בתהליך "ניקוי הזבל" שלו.
סיכום
יש בערך אינסוף חומר על גיט ברשת. במקום לחזור פעם נוספת על סט של הפקודות של גיט ומשמעותן, ניסיתי להביא מבט קצת יותר טכני על ה internals של גיט ולהסביר כמה מההתנהגויות של גיט בעזרתן. לי נקודת-מבט זו הייתה חסרה - וסייעה רבות ברגע שקיבלתי אותה. נראה שגיט הוא קצת יותר מבאזז רגעי - והוא יישאר עמנו כמה שנים. אני מאמין ששווה להשקיע ולהבין אותו.שיהיה בהצלחה!
-----
קישורים רלוונטיים
GitGuys - מקור טוב להבנת המבנה של גיט:
http://www.gitguys.com/topics/
Git cheat sheet - רפרנס ויזואלי של הפקודות הנפוצות וההשפעות שלהן:
http://www.ndpsoftware.com/git-cheatsheet.html#loc=remote_repo;
UnGit - כלי ויזואלי שעוזר ללמוד גיט:
https://github.com/FredrikNoren/ungit
Learn Git Branching - אתר טוב שמציע "משחק" שיסייע לכם לעקוב אחר branching מתקדם בגיט - נחמד מאוד.
http://pcottle.github.io/learnGitBranching/
כלי UI טוב מהרגיל לגיט (שומר על השפה של גיט) - SourceTree:
"A shout out to developers of SourceTree - a nice GUI for git and hg. Useful even for a command-line fan like me. " -- Martin Fowler
לינק מעניין: לינוס מציג את גיט ב 2007.
אוסף נחמד של מדריכי וידאו לגיט: http://training.github.com/resources/videos/
