נקסט אינשורנס מסומנת ע"י כלכליסט כמספר 3 בסטאראט-אפים המבטיחים לשנת 2018

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

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

מקור

הביטוח, בפרספקטיבה היסטורית, ביחד עם הרעיון של בורסאות (stock market) - היו הדלק לעליה של מערב אירופה ב-500 השנים האחרונות. עד קודם לכן, הייתה מערב-אירופה פריפריה נחשלת וחסרת השפעה על ההיסטוריה האנושית.

בני-האדם שחיו בתקופה "אסונית יותר" (למשל: שליש מהילדים באירופה לא הגיע לגיל 15) לא האמין בעתיד טוב יותר, ולא שש להשקיע במיזמים חדשים. ללא השקעה - לא היו צמיחה, ולא הייתה התפתחות משמעותית. החיים בשנת 1000 לספירה והחיים בשנת 1500 לספירה - היו דיי דומים.

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

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

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

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

הרבה חישובים נעשים ע"י צבא של מפעילי אקסל, במקום ע"י תוכנה מרכזית (כלומר: מבוזרת, אבל כתובה פעם אחת).
הנתונים - שהם לכאורה core business בתעשייה הזו, המבוססת על סטטיסטיקה וחיזוי - עברו עיבוד חלקי ולא-מעמיק.

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

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

כמובן שהדבר גם תלוי בצוות, שעובד במתודולוגיה מאוד נכונה (Lean Startup inspired) - ומצליח להתמקד בעיקר.
יש חברות דומות (לא אציין שמות) - שקיימות פרק זמן דומה, ועדיין לא החלו למכור (או בקושי למכור).

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

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

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

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

אבל לא המצב. כמה חבר'ה חכמים שעובדים בחברה - מכסים את נושא הרגולציות.

אז הנה, פרגון לצוות שעושה את זה:

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

כמה דברים שרציתם לדעת על גיט - אבל חששתם / התעצלתם לשאול

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

גיט הוא כלי "הכרחי":

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

מתוך הצורך הקיומי לשימוש בגיט, קיימת רמת מיומנות בסיסית הנפוצה בקרב אנשי תוכנה.

נקרא לה "רמה 2".

רוב אנשי התוכנה נמצאים ברמה 2. הם יודעים לעבוד בצורה שוטפת עם גיט, וכבר לא נתקלים בבעיות רציניות איתו (אין כבר מצבי "Detached from head" שכיחים כמו בהתחלה), אבל עדיין יש עוד הרבה בגיט שאינו מוכר ואינו מובן.

למשל: 

• עניינים של ה internals - כיצד גיט ממומש, וכיצד הוא עובד מאחורי הקלעים.
• כל מיני מונחים מוכרים, אבל לא מובנים, למשל: Fast-Forward, ReReRe, Rebase, או Bisect - היא רשימה מייצגת שאני נתקלתי בה, של מונחים שאנשים רבים שמעו - אבל לא יודעים באמת מה הם אומרים.

האם רמה 2 היא "מספיק טובה" בכדי לעבוד עם גיט? 

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

מצד שני... קצת חבל. לשמוע מושגים ולא להבין מה הם אומרים? 

לאורך שנים?

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

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

Rebase

rebase הוא דרך חלופית ל merge על מנת למזג עבודה בין branches.
יש הנחה ששמעתי הגורסת שמשתמשי SVN לשעבר, הרגילים לעבור על branch יחיד (להלן "trunk") - נוטים להשתמש ב rebase כי הוא מזכיר את הכלי הקודם שלהם. לא יודע.

בעוד השימוש בפקודת git merge מייצרת היסטוריה של branches מקבילים המתמזגים זה לתוך זה כמו מסילות רכבת בתחנת רכבת גדולה באירופה, rebase משמר היסטוריה שנראית כמו "מסילה בודדה".

אותו קוד, אותם שינויים - שיטת מיזוגים שונה (בד"כ ה rebase יהיה ארוך יותר)

Merge - מציג את המצב המסובך כפי שהוא.
Rebase - יוצר מציאות קלה יותר למעקב - אך יש מחירים לייצר אותה.


נניח שיש לנו branch עם 6 commits שאנחנו רוצים למזג ל master.
כאשר אנו משתמשים ב merge - זו פעולה אחת, עם סיכוי מסוים לקונפליקטים. הקונפליקטים נוצרים ע"פ המצב הסופי של ה branch שלי מול המצב הסופי של ה master.

rebase הוא מורכב יותר: הוא ייקח את ה branch שלי, commit אחר commit, ויטמיע אותם בראש ה master branch כאילו רק עכשיו כתבתי אותם. אחד אחרי השני.

הסיכוי לקונפליקטים שצריך לפתור גדל משמעותית: ייתכן שכתבתי קוד ב commit מס'3 שיצור קונפליקט, אבל הסרתי את הקוד הזה ב commit מס'5 (המאוחר יותר ב branch).
אם הייתי עובד עם merge לא הייתי צריך להתעסק עם הקונפליקט (הזמני) הזה -הקוד הסופי אינו מכיל אותו.
ב rebase אני צריך לפתור אותו. אם ב commit מס'4 היה שינוי נוסף בקוד הזה - ייתכן וייווצר קונפליקט נוסף שיהיה עלי לפתור.

בקיצור: rebase יוצר היסטוריה שקל יותר להבין, במחיר של פתירת קונפליקטים רבים יותר בעת המיזוג.

מתי זה משתלם?
עבור רוב הפרויקטים זה לא משתלם. בפרויקטים בהם עוברים על ההיסטוריה פעמים רבות ומנסים להבין אותה - זה עשוי להשתלם.
Rebase נפוץ בשימוש, יחסית, בפרויקטי Open Source מרובי תורמים זרים - כלומר: תורמים שלא מכירים זה את זה ולכן התקשורת ביניהם היא פחות יעילה. במקרים האלו - היסטוריה נקיה יכולה לחסוך הרבה בעיות תקשורת, ולהצדיק את המחיר הנוסף בביצוע rebase.

נ.ב: בעוד את פקודת git merge מפעילים מתוך branch היעד (אליו רוצים למזג), את פקודת git rebase מפעילים מתוך branch המקור - ה branch אשר את תוכנו רוצים למזג/"להרכיב" על branch אחר.

Fast Forward

אין סיכוי שלא נתקלתם במונח Fast Forward (להלן FF) בעבודה עם גיט.

"טוב, קרה פה משהו מהיר. נראה שאין בעיות. יופי - נמשיך הלאה!" - היא התגובה המקובלת להודעה של גיט שבוצע FF.


בואו נבין טיפה יותר:
בעצם FF הוא אופטימיזציה של גיט על מנת לפשט את ההיסטוריה.

כאשר יש לי branch (למשל: feature branch) שאני רוצה למזג (למשל: ל master) אבל ה master לא השתנה מאז שהתפצלתי ל feature branch - אפשר לפשט את הדברים.

merge בשלב כזה ל master הוא כאילו הוספתי את ה commits שלי ,לא ל feature branch - אלא ישירות ל master.
התוצאה הרי הייתה זהה.

יש פה גם עניין של חיסכון ברמת המימוש הפנימי של גיט: בוודאי שמעתם ש branch הוא בעצם רק pointer.
על מנת לבצע FF כל מה שגיט צריך הוא להפנות את המצביע (branch) בשם "master" להצביע לנקודה של המצביע "feature branch".

אם מסיבה כלשהי חשוב לכם להדגיש את ההיסטוריה כפי שקרתה - אתם יכולים להורות ל git לבצע merge ללא FF.
זה כל הסיפור.

Git Revert

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

הפקודה git revert HEAD~2 (אנו מכוונים ל commit X, הרי הוא Head פחות 2 צעדים אחורה) - מנסה ליצור commit חדש המסומן כ X- אשר מהווה את ההופכי של X ומבטל את כל הפעולות שנעשו.
לאחר ש commit -X ייווצר - כל התוספות של y ו z - עדיין יהיו תקפות, לא ביטלנו אותן.

מתי הדבר שימושי? למשל כאשר יש בעיה בסביבת production או staging שאנו רוצים לפתור מהר, ואנו יודעים איזה commit אחראי לה. ניתן אח"כ לעשות revert ל X- - ולקבל בחזרה את השינויים של X למערכת.

אם יש התנגשות שגיט לא יודע לפתור (בד"כ הוא עושה עבודה יפה מאוד) - אזי הוא ייתן לכם לפתור את הקונפליקטים.
ניתן לקרוא ל git revert --abort (ממש כמו merge) - אם הסתבכתם בהתרה שלהם.

revert ניתן גם לעשות מתוך ה UI של github ולפתוח ממנו מיד Pull Request - מה שמאוד נוח.

מקור: https://www.slideshare.net/durdn/ninja-git-save-your-master

Git ReReRe (ידוע גם כ Re3)

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

השם הלא-שגרתי הוא קיצור לא Reuse Recorded Resolution או "שימוש-חוזר בפתרונות מוקלטים".

שימוש נפוץ בפקודה היא בסיטואציות בהן לא עובדים ב Continuous Delivery אלא ב long feature branches.
למשל: אני עובד על פיצ'ר במשך שבועיים-שלושה, ורוצה כל יום למשוך שינויים מה master.

לרוע המזל אני נתקל יום אחרי יום באותו ה merge conflict כי אני עובד על קטע קוד שעובר שוב ושוב שינויים גם על גבי ה master.

תסריט נפוץ אחר הוא כאשר עובדים עם rebase, ואז ישנם הרבה קונפליקטים דומים. למשל: אני עושה rebase ל branch עם 10 commits המכיל 4-5 קונפליקטים דומים על אותו האזור בדיוק. אני רוצה שגיט ילמד איך פתרתי את הקונפליקט הפעם הראשונה - ו"יסתדר לבד" בפעמים הבאות.

רהרהרה היא גם פקודה וגם קונפיגורציה. אנו אומרים לגיט להקליט את ה מיזוגים שאנו עושים (בעקבות rebase, merge, cherry-pick וכדומה) - בכדי שישמש בהם כ reference ל conflict resolution אוטומטי בעתיד.

הפעלת הקונפיגורציה הבסיסית נראית כך:
git config --global rerere.enabled 1

בכל פעולה בה יש מיזוג של קוד (merge, rebase, ועוד) והיה קונפליקט שנפתר על ידי ידנית - גיט ישמור "fingerprint".
ה fingerprint הוא ספציפי לקובץ מסוים, ומכיל את הקונפליקט: מה היה לפני, בשני ה branches שביניהם יש קונפליקט - ואיך נראה הקוד לאחר שפתרתי את הקונפליקט.

מקור: https://readyspace.com.hk/rerere

בעזרת pattern matching דיי שמרני (אין פה היבטים מתקדמים של "למידת מכונה"), גיט יזהה מקרים דומים - ויבצע את אותו הטיפול שאני ראיתי אותו. הקונפליקט לא חייב להיות זהה 1:1 ברמת הקוד - גיט יכול לזהות שינויים קלים ב pattern ולהתייחס אליהם בצורה נכונה.

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

• שגיט יבצע טעות, ויבצע merge שמתאים ל pattern שהוא זיהה - איך אינו נכון.
• אני ביצעתי טעות ולימדתי את גיט/רהרהרה פתרון שגוי - שהוא יחזור עליו עוד מספר פעמים עד שאזהה את הטעות.

האם גיט רהרהרה שווה את הסיכון? התשובה כנראה מאוד אינדיבידואלית.
רהרהרה מכיל גם מנגנוני תיקון, כמו הפקודה git rerere forget path_spec - המאפשרים לי לתקן למידה לא-טובה, אם זה גם אומר שעלי להשקיע עבודה נוספת / המנגנון לא פועל בצורה אוטומטית לגמרי.

סיכום

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

אולי אפילו נצליח להשתמש בגיט בצורה קצת יותר חכמה.


שיהיה בהצלחה!



---

לינקים רלוונטיים

Git Flight Rules - דוגמאות והסברים על מגוון פעולות בגיט.
מדריך לשימוש בגיט רהרהרה

ניקיונות גיט (פוסט קצר לפסח)

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

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

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

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

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

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


קצת רקע אישי הקשור לגיט:

• אני עובד עם Github (כמו הרוב), מה שאומר שאני לא נוהג לבצע פעולות ב remote מתוך command line. 
• אני עובד עם IntelliJ, מה שאומר שאני שחלק מהפעולות אני מעדיף לעשות ב GUI. בעיקר: 
• git log, git blame, git diff 
• ל intelliJ יש גם יכולת שימושית בשם Git Shelf - יכולת מקבילה ל git stash המאפשרת לאחסן כמות לא מוגבלת של "stashes" (ה IDE פשוט מאכסון את ה diffs בתיקיה נפרדת). 
• אני עובד עם Ohh my Zsh מה שמאפשר לי כמה קיצורים ו autocomplete שלא נמצאים ב shell הסטנדרטי. זה כנראה לא משפיע הרבה על מה שאכתוב כאן - אקפיד להשתמש בשם הפקודה המלאה ולא בקיצורים.

ניקוי קבצים

אתחיל בתסריט של ניקוי קבצים:

עבדתם על משהו, ואז מישהו ביקש מכם code review על branch אחר ו/או מישהו ניגש אליכם ושאל איך כדאי לעשות משהו - והראתם לו כמה שינויים בקוד.

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

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

הנה כמה פעולות שימושיות "להשתחרר" מהמצב:

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

Test-Delete untracked files: git clean -n

Delete untracked files (not staging): git clean -f

clean היא פקודה שמטרתה לנקות קבצים שאינם באינדקס (קרי: לא tracked). הגרסה n- מציגה רשימה של קבצים למחיקה, ו f- מוחקת אותם בפועל.


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

. git add ואז
git reset --hard

זוהי הדרך "אוטומטית" (ללא צורך בחשיבה) לנקות את כל השינויים המקומיים. 
קודם אנחנו מוסיפים את כל השינויים ב workspace לאינדקס (קבצים ששונו, קבצים חדשים, קבצים שנמחקו) ואז מבקשים מגיט לאפס את האינדקס משינויים, לדרוס הכל (hard--).

הסבר קצר: לפקודה git reset יש 2 צורות:

• הסרה של קובץ / path מהאינדקס. ההופכי ל git add. הווריאציה הזו פועלת כאשר מצוין path (למשל: .)
• איפוס ה branch הנוכחי (HEAD) למצב של commit מסוים - כאשר לא מצוין path.

קצת מבלבל שיש 2 פעולות עם אופי שונה תחת אותה הפקודה!

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


לכאורה ניתן לבצע את פעולת "revert" מתוך ה IDE אבל בכמה מקרים (למשל: קבצים חדשים) - יידרשו עוד כמה צעדים ידניים. גישת ה add-reset היא המהירה ביותר (עד כמה שידוע לי).

התחרטתי!

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


התחלתי merge אבל הוא הסתבך לי

git merge --abort

מבטל את ה merge וחוזר לשלב שהיה לפניו.
בד"כ הפקודה הבאה תהיה שוב <git merge <some branch - אבל הפעם אנו יודעים טוב יותר מה מצפה לנו, ונעשה אותו בצורה נכונה יותר.

עשיתי commit ל master או ל branch אחר שלא התכוונתי

git reset HEAD~1

הנה עוד שימוש בווריאציה השנייה של git reset - איפוס ה HEAD ל commit מסוים. 
על הפקודה הזו ניתן לחשוב כמו HEAD = HEAD-1:

• החזר את ה branch ל commit אחד אחורה (ניתן להחליף את המספר 1 בכל מספר אחר).
• כל השינויים שנכללו ב commits ש"בוטלו" - יועברו ל working directory.

מכאן אני יכול לבצע:

git checkout desired_branch

. git add

"..." git commit -m 

והנה כל השינויים נמצאים כ commit ב branch שאליו התכוונתי.


נ.ב.
אם אתם רוצים לחזור הרבה commits אחורה, וקצת מתבלבלים בספירה - אולי עדיף לעשות את הפעולה מתוך ה IDE.

בגדול, כל פעם ש git log מעורב - יש יתרון לממשקי GUI ע"פ ה command line (לטעמי).
בהפעלת הפעולה, IntelliJ פותח 4 אופציות. האופציה שציינתי נקראת "mixed" - אבל אתם יכולים לבחור בכל אופציה שנשמעת לכם הגיונית ורצויה.

לנקות branches

branches באים הולכים: נוצרים, נושאים שינויי קוד, ואז ממורג'ג'ים ל branch אחר - ואז אין צורך בהם.
אם אתם מיישמים Continuous Integration - רוב הסיכויים שייצרו כמה branches חדשים כל יום.
מכירים את המצב שיש לכם 5 או יותר branches מקומיים שאתם לא בטוחים מה המצב שלהם?
אתם רוצים לעשות push ולמרגג' את מה שנותן, למחוק אותם - ואז להתחיל עבודה חדשה.

מסובך? 

העצה הכי טובה שיש לי היא למחוק בזוגות, branches מקומיים ומרוחקים - מיד לאחר ביצוע merge ב github.

git branch -d branch_name :

1. ימחק branch שהוא fully merged, ל repository המרוחק, או המקומי
2. ימחק (עם warning) את ה branch אם הוא push ל remote (ואין לו עדכונים).
3. לא ימחק אם אין remote tracking ו/או יש שינויים מקומיים שלא עודכנו ל remote.

זוהי פקודה בטוחה יחסית. אם המקרה השני קרה - אפשר לחזור ממנו בעזרת git checkout ל branch שנמחק. הקוד נמצא ב remote.
את ה branch ב Github - מוחקים בעזרת ה UI.

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

git branch | grep -v "master" | xargs git branch -d 

עוברים על כל ה branches המקומיים

grep -v יוציא ה master מהרשימה (אותו לא נרצה למחוק)

xargs מפעילה את הפקודה שאחריה עם פרמטר של מה שמגיע מה pipe (כלומר: stdin). כלומר: תנסה למחוק את כל ה branches, מלבד master, בצורה "בטוחה".

עדיין צריך לשים לב ל warnings ולהחזיר (בעזרת checkout) את branches שלא התכוונו למחוק.

יהיו עדיין branches שהפקודה לא תמחק. ירשם error בנוסח "the branch ... is not fully merged". אלו:

• branches עם commits מקומיים - אולי שכחנו לעדכן ל remote? אולי ויתרנו על הקוד הזה?
• branches ללא remote tracking (מעולם לא עשינו push ו/או הפעלנו git fetch --prune או פקודה דומה).

אז מה עושים עם ה branches שלא נמחקו עם git branch -d?
כאן יש עוד עבודה ידנית. עדיין לא מצאתי דרך פשוטה יותר:

• להיכנס לכל branch
• לבדוק את ה log לראות אילו commits קיימים
• אם זה לא מספיק - לעשות diff ולראות מה השינויים בקבצים. האם נרצה אותה?
• לדחוף (git push) ו/או למחק (git branch -D branch_name) את ה branch.

כרגיל, כאשר יש עבודה עם git log - יש יתרון גדול לעשות את העבודה ב GUI.


שווה אולי להזכיר שיש גם פקודות כגון:

git branch --merged branch_name

המספקת לנו רשימה של branches שממורג'ג'ים ל branch_name.
כאשר רוב ה merges נעשים ב remote (למשל: GitHub) - היא פחות שימושית

ניתן גם לבדוק אלו branches שיש להם remote tracking (להלן r-) מורג'ג'ו ל master המרוחק:

git branch -r --merged origin/master

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


---

טיפ קטן למשתמשי Ohh my Zsh:
לעתים המלצות ה autocomplete ל gco (קרי git checkout) כוללות כל מיני branches ישנים.

git fetch -p שזה בעצם git fetch --prune

מנקה את ה metadata על branches שהם כבר לא remote tracked - מה שמנקה הצעות autocomplete לא רלוונטיות, אל הניקוי הזה גם גורם לפקודת git branch -d לכישלונות כי היא לא יודעת מה מצב ה branch המרוחק.

הטיפ: לקרוא ל git fetch -p רק במצב שכל ה branches המקומיים נקיים או שאין לכם בכלל branches מקומיים. זה יחסוך לכם כאבי ראש.

---

טיפ קטן לסיום:

איך רואים ב IntelliJ השוואה כמו זו של Github?

ה compare של Github נראה קצר יותר וממוקד יותר מ compare ב IDE?

אתם מוצאים את עצמכם עושים git push רק בכדי ליהנות מה compare של Github ולצפות בהתקדמות שלכם בכתיבת קוד?

אתם יכולים לבצע השוואה דומה גם ב IntelliJ.

אני מניח שאתם נוהגים לעשות compare מתוך התפריט בפינה התחתונה של ה IDE:

ואז compare ל branch המוביל:

עד כאן טוב ויפה, אבל כנראה שהפעולה הבאה שלכם היא לבחור ב tab של files (מסומן ב x אדום):

התוצאה תהיה לראות את כל השינויים מול ה master - גם כאלו שלא אתם הכנסתם, אלא אתם גוררים עם ה branch. זה לא יעיל.

במקום זה, תבחרו את רשימת ה commits שלכם (1), ואז תקבלו בצד ימין את רשימת הקבצים בהם נעשו שינויים כחלק מה commits שלכם (2).

הנה עוד כמה settings ב view של ה compare שידמו יותר ל Github:

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



זהו לסיום.
מקווה שהפוסט יהיה שימושי לכמה אנשים.

שיהיה בהצלחה!

---

לינקים רלוונטיים

https://zippyzsquirrel.github.io/squirrel-u/1_SquirrelU/4_GitHub/1_introToGitAndGitHub/ - מדריך הכולל גם פרטים כיצד לעבוד עם כלי ה git של IntelliJ.