הבלוג של ינון פרק

ראיתי השבוע חבר מקליד את הפקודה הבאה בגיט כדי לצאת ממצב מביך:

$ git reset --hard origin/master

בואו נראה מה היא עושה כדי להבין אם היא יכולה לעזור גם לכם.

מתחילים בתיעוד של גיט. יש לגיט ריסט שלושה מצבי פעולה:

       git reset [-q] [<tree-ish>] [--] <paths>...
       git reset (--patch | -p) [<tree-ish>] [--] [<paths>...]
       git reset [--soft | --mixed [-N] | --hard | --merge | --keep] [-q] [<comm
it>]

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

In the third form, set the current branch head (HEAD) to
<commit>, optionally modifying index and working tree to match.

לכן הדבר הראשון שריסט יעשה הוא לשנות את HEAD כך שיצביע על הקומיט שעובר בפרמטר האחרון. הקומיט הזה במקרה שלנו הוא origin/master שזה אומר הקומיט שאנחנו חושבים שהשרת קורא לו master. זה אומר שאם עשינו כבר קומיטים אצלנו ב master אנחנו הולכים לחזור לנקודה לפני הקומיטים שלנו. מצד שני פקודת reset לא פונה לשרת לכן אם מישהו אחר עשה push לשרת אנחנו לא נדע מזה. אנחנו נלך למקום ש origin/master היה בו בפעם האחרונה שפנינו לשרת.

אפשר לראות את הנקודה הזאת עם:

$ git log -1 origin/master

או אם מה שמעניין אתכם זה רק ה Commit Hash תוכלו להפעיל:

$ git rev-parse origin/master
a08935913801409ef7437ba9038d4a0580f1f6c5

ועם פקודה דומה נוכל לגלות אם ה master שלנו כבר התקדם מהקומיט הזה או שהוא עדיין שם:

$ git rev-parse master
a08935913801409ef7437ba9038d4a0580f1f6c5

דרך אחרת היא פשוט להפעיל status. אם ה master שלכם לא תואם ל origin/master תקבלו על זה הודעה בשורה השניה של הפלט. במקרה שלי הם תואמים אז יש לנו:

$ git status
On branch master
Your branch is up to date with 'origin/master'.

nothing to commit, working tree clean

בחזרה ל reset - אז הדבר הראשון שיקרה זה ש HEAD יעבור להצביע על הקומיט שנקרא origin/master. הדבר השני ש reset עושה זה לעדכן את הקבצים בתיקיית העבודה. המתג --hard אומר:

Resets the index and working tree. Any changes to tracked files in the working tree
since <commit> are discarded.

לכן הפקודה תנקה את כל ה Staging Area ותעתיק את הקבצים מהקומיט אליו אנחנו חוזרים ל Staging Area. אחרי זה היא תעשה את אותו דבר עם הקבצים בתיקיית העבודה שלנו. נשים לב שמדובר רק על שינויים בקבצים במעקב בתיקיית העבודה, לכן קבצים שיש לכם בתיקיית העבודה שלא נמצאים בריפוזיטורי לא יושפעו מהפקודה (בשביל למחוק אותם תרצו לקרוא על git clean, אבל זה סיפור לפוסט אחר).

לסיכום הפקודה git reset --hard origin/master עושה את הדברים הבאים:

1. היא בודקת מה מזהה הקומיט של הענף origin/master.

2. היא מזיזה את הענף הנוכחי כך שיצביע גם הוא לאותו קומיט. יחד איתו יזוז גם ה HEAD.

3. היא מאפסת את כל הקבצים ב Staging Area ולוקחת את הגירסא מהריפוזיטורי.

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

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

וקטנה לסיום- אם הפעלתם את git reset --hard origin/master בטעות ופתאום נעלמו לכם הקומיטים שעשיתם, אתם תמיד יכולים לגשת ל git reflog כדי למצוא את הקומיטים האבודים. אחרי שמצאתם את הקומיט ש master הצביע עליו קודם, תוכלו להשתמש ב git reset נוסף כדי לחזור אליו.

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

1. שהמערכת תהיה מבוזרת.

2. שהמערכת תהיה אמינה.

3. שהמערכת תעבוד מהר.

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

I can build something better in two weeks -- Linus Torvalds

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

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

אני מקווה שאתם מכירים את ההמלצה לחלק את השינויים שלכם לקומיטים לפי נושאים, כך שכל קומיט יתאים ל Issue במערכת ניהול ה Issues שלכם. אבל מה עושים אם שכחתם את עצמכם בהתלהבות של הקידוד והתעוררתם שעתיים אחרי עם 5 שינויים מ-5 נושאים שונים באותו קובץ?

אל תדאגו - אני יודע גיט.

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

# My Cool Project

This is a demo project

ועכשיו נוסיף לו שני בלוקים של טקסט שאמורים להיות מפוצלים ל-2 קומיטים שונים:

# My Cool Project

This is a demo project

# Installation
you need to download this app and install it if you want to use it

fixing first issue
fixing second issue
fixing third issue

במקום לעשות cut-and-paste עם קובץ נוסף אפשר פשוט להפעיל את git add במצב אינטרקטיבי:

$ git add --interactive -p

diff --git a/readme.txt b/readme.txt
index d3ef36a..a53fb88 100644
--- a/readme.txt
+++ b/readme.txt
@@ -1,3 +1,12 @@
 # My Cool Project

 This is a demo project
+
+# Installation
+you need to download this app and install it if you want to use it
+
+fixing first issue
+fixing second issue
+fixing third issue
+
+

Stage this hunk [y,n,q,a,d,e,?]? 

גיט מזהה את השינויים ושואל אולי מה לעשות. כרגע כל השינויים צמודים אחד לשני ומבחינת גיט זה נראה כמו שינוי יחיד. אני רוצה לקחת את הבלוק שמתחיל ב Installation ולשמור אותו בתור קומיט משלו ולכן אני לוחץ e כלומר edit (במצבים בהם הבלוקים לא היו רציפים גיט היה מבצע את הפיצול בצורה אוטומטית). בתגובה git יפתח את ה EDITOR המועדף עליי ויציג לי מסך עריכה שנראה כך:

# Manual hunk edit mode -- see bottom for a quick guide.
@@ -1,3 +1,12 @@
 # My Cool Project

 This is a demo project
+
+# Installation
+you need to download this app and install it if you want to use it
+
+fixing first issue
+fixing second issue
+fixing third issue
+
+
# ---
# To remove '-' lines, make them ' ' lines (context).
# To remove '+' lines, delete them.
# Lines starting with # will be removed.

במסך זה אנחנו יכולים לבחור איזה שורות יעלו ל Staging Area. את השורות שאתם לא רוצים להעלות יש למחוק (או אם מדובר היה בשינויי מחיקה למחוק רק את המינוס הקטן בתחילת השורה). נעשה את זה ונישאר עם:

# Manual hunk edit mode -- see bottom for a quick guide.
@@ -1,3 +1,12 @@
 # My Cool Project

 This is a demo project
+
+# Installation
+you need to download this app and install it if you want to use it
+
# ---
# To remove '-' lines, make them ' ' lines (context).
# To remove '+' lines, delete them.
# Lines starting with # will be removed.
# 
# If the patch applies cleanly, the edited hunk will immediately be
# marked for staging.
# If it does not apply cleanly, you will be given an opportunity to
# edit again.  If all lines of the hunk are removed, then the edit is
# aborted and the hunk is left unchanged.

שמירה ויציאה ותראו את הסטטוס:

$ git status
On branch main
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    modified:   readme.txt

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   readme.txt

הקובץ readme.txt מופיע גם בתור משהו שייכנס לקומיט הבא וגם בתור שינויים שלא ייכנסו לקומיט הבא. הפעלת diff תראה לנו את ההסבר:

$ git diff

diff --git a/readme.txt b/readme.txt
index 6076e63..a53fb88 100644
--- a/readme.txt
+++ b/readme.txt
@@ -5,3 +5,8 @@ This is a demo project
 # Installation
 you need to download this app and install it if you want to use it

+fixing first issue
+fixing second issue
+fixing third issue
+
+

בלוק הטקסט השני, שמסומן ב +, נמצא אצלי בתיקיית העבודה אבל לא ב Staging. לעומתו הבלוק שמעליו כן נמצא ב Staging area ולכן לא מופיע ב diff.

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

$ git commit -m 'add installation instructions' 

ובסטטוס הבא נראה שהקובץ עדיין ב Modified אבל הפעם רק החלק השני שלו. עכשיו אפשר להמשיך ל add ו commit נוספים כדי להכניס את בלוק הטקסט השני:

$ git add .
$ git commit -m 'fixed more issues'

ובסוף הלוג יכלול שני קומיטים עבור שני השינויים שלנו, שהתרחשו באותו זמן ובאותו הקובץ:

commit 3612ce51ab22876a6337b56050a1f16bff9ea9e9 (HEAD -> main)
Author: ynonp <ynonperek@gmail.com>
Date:   Sun Dec 23 14:49:12 2018 +0200

    fixed more issues

commit b4c25f7ac3cb7fdd3d8101750ff03cb2b3d7b5e1
Author: ynonp <ynonperek@gmail.com>
Date:   Sun Dec 23 14:47:38 2018 +0200

    add installation instructions

אוהבים גיט ורוצים ללמוד להשתמש בו טוב יותר? אני חושב שתהנו מקורס Git Hero שיש לנו כאן באתר שכולל מעל שש שעות של הסברים, דוגמאות וטיפים לשימוש חכם יותר ב Git. פרטים והרשמה בקישור https://www.tocode.co.il/bundles/git

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

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

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

אתם כבר עובדים בגיט? מעולה! עכשיו כדאי שתכירו את הפקודה git bisect שתעזור לכם למצוא באגים באופן אוטומטי בתוכניות שלכם.

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

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

תשע שנים אחרי ועדיין לא עבר לו, וגם אני כבר מזמן מכור.

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

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

מתכנתים רבים מגיעים ללמוד גיט ומחפשים איך לבצע בגיט את ה-3 פקודות שהם מכירים ממערכת ניהול הגירסאות הקודמת שלהם או דרך Tutorials של "למד את עצמך גיט בעשרים דקות". זה עובד אבל רק חלקית. כשאתם לומדים תוך כדי עבודה ומדלגים על הבסיס התיאורטי וה Best Practices יהיו דברים חשובים שתחמיצו ויהיו דברים שוליים שתקחו יותר מדי ללב.

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

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

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

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

https://www.tocode.co.il/bundles/git

נתראה שם, ינון