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

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

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

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

ואחרי ששמנו את זה מאחורינו אפשר להתקדם ולשאול - מה אני צריך לעשות כדי להיות במקום שבו אני יכול לפתור את הבעיה הזאת? הנה כמה רעיונות:

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

2. ללמוד יותר על עולם התוכן הרלוונטי (קורס מקוון, ספר, קריאת תיעוד).

3. להמשיך לפתור בעיות אחרות ולחזור לזה עוד חודשיים-שלושה כשאהיה יותר משופשף.

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

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

חבר סיפר לי השבוע שהם מתלבטים בין Vue ל React לפרויקט הבא. בשיחה אחרת חברה שאלה באיזה כלי CI כדאי להשתמש וחבר שלישי לא הצליח להחליט אם לפתח את האפליקציית מובייל שלהם ב React Native או ב Flutter.

ובתכל'ס כולם מודאגים מאותם הדברים-

1. מה אם אבחר את הכלי הלא נכון?
2. מה אם בעוד חצי שנה לא אצליח לבנות איזה פיצ'ר בגלל הכלי שבחרתי?
3. מה אם הכלי שבחרתי יעלם מהשוק בעוד שנה?
4. מה אם לא אצליח להגיע לביצועים שאני רוצה?

או במילים אחרות: "מה כדאי לבחור כדי שלא אתחרט על זה בהמשך?"

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

אני רוצה להציע רעיון אחר - במקום לשבור את הראש כדי לנסות למצוא את הכלי הכי טוב עבורכם, נסו לסנן החוצה את כל הכלים שלגמרי לא באים בחשבון ולבחור באקראי את אחד מהנשארים. בינינו, יש סיכוי טוב שגם ב React וגם ב Vue תצליחו לבנות יופי של אפליקציה; שגם ב Jenkins, גם ב Travis וגם ב Circle CI תוכלו לבנות יופי של אינטגרציה ואפליקציית המובייל שלכם תרוץ גם אם תכתבו אותה ב RN, גם ב Flutter ואפילו אם תלכו על Xamarin. עדיף לכתוב קוד מאשר לבזבז את הזמן בהתלבטויות.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[alias]
  st = status

אפשר גם להוסיף פרמטרי ברירת מחדל לפקודות לכן האליאס הבא יפעיל את reset hard בלי בעיה:

[alias]
    trashall = git reset --hard

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

[alias]
  stst = !git status && git status

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

$ git stst -s

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

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

[alias]
  acm = "!f() { git add \"$@\"; git commit; }; f"

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

$ git acm demo.txt hello.py

וזה יגרום להפעלה של:

$ git add demo.txt hello.py && git commit

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

https://www.atlassian.com/blog/git/advanced-git-aliases

יש את השיטה של הבית ספר ואת השיטה של החדר כושר.

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

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

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

לפני כמה ימים הראיתי פה שלד לפרויקט Node.JS שבכל קומיט מריץ את בדיקות היחידה עם מנגנון Bitbucket Pipelines. כמה חברים הציעו לקחת את זה עוד צעד קדימה ולשלב גם את Selenium כדי להריץ בדיקות End To End לפרויקט. מאחר ומערכות גדולות יותר אני מעדיף לכתוב ב Rails החלפתי גם את טכנולוגיית צד השרת וכך קיבלנו את השלד בפוסט של היום.

הפרויקט כולל:

1. פרויקט Rails שמציג אתר עם דף אחד ובו הודעת שלום. ההודעה והדף נשמרים בקובץ app/views/home/index.html.erb.

2. בדיקת End-To-End לפרויקט שמפעילה Selenium, מתחברת לעמוד ומוודאת שהדף עלה והציג את ההודעה. הבדיקה נמצאת בקובץ test/system/home_test.rb.

3. בסיס נתונים PostgreSQL עבור הבדיקות שמאופס בכל פעם שעושים Push.

4. קובץ bitbucket-pipelines.yml שמתקין את כל הכלים שצריך ומריץ את הבדיקות.

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

https://bitbucket.org/ynonp/rails-selenium-pipeline/src

החלק שהכי יעניין אותנו היום הוא הקובץ bitbucket-pipelines.yml אז בואו נתחיל ממנו:

image: ruby:2.4.4

pipelines:
  default:
    - step:
        script: # Modify the commands below to build your repository.
        - export DATABASE_URL=postgresql://test_user:test_user_password@localhost/pipelines
        - curl -sL https://deb.nodesource.com/setup_8.x | bash -
        - apt-get update && apt-get install -y unzip libnss3-dev nodejs libgconf-2-4 wget && wget -q -O - https://dl-ssl.google.com/linux/linux_signing_key.pub | apt-key add -  && sh -c 'echo "deb [arch=amd64] http://dl.google.com/linux/chrome/deb/ stable main" >> /etc/apt/sources.list.d/google.list' && apt-get update && apt-get install -y google-chrome-stable fonts-ipafont-gothic fonts-wqy-zenhei fonts-thai-tlwg fonts-kacst ttf-freefont --no-install-recommends
        - bundle install
        - rake db:setup
        - rake db:test:prepare
        - rails test:system
        services:
        - postgres

definitions:
  services:
    postgres:
      image: postgres
      environment:
        POSTGRES_DB: pipelines
        POSTGRES_USER: test_user
        POSTGRES_PASSWORD: test_user_password

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

החלק הראשון הוא שמגדיר את האימג' שמריץ את הבדיקות. הקונטיינר שלו יתקין את הפרויקט עם כל התלויות, וגם את דפדפן כרום. בסוף הוא יאפס את בסיס הנתונים ויפעיל את כל בדיקות המערכת עם rails test:system. זה יגרום להפעלת סלניום והרצת הבדיקה.

הקובץ שכולל את הגדרות הסלניום נקרא test/application_system_test_case והוא כולל את התוכן הבא:

require "test_helper"

class ApplicationSystemTestCase < ActionDispatch::SystemTestCase
  driven_by :selenium, using: :headless_chrome, screen_size: [1400, 1400], options: {
    args: %w[--headless --no-sandbox --disable-gpu --disable-dev-shm-usage]
  }
end

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

המקום האחרון שדרש התערבות בשביל שכל העסק הזה ירוץ הוא הקובץ test/test_helper.rb. לשם הוספתי את שתי השורות הבאות כדי שתוצאות הבדיקות יישמרו בקובץ XML בפורמט jUnit כך שביטבאקט יצליח לקרוא אותן:

require "minitest/reporters"

Minitest::Reporters.use! Minitest::Reporters::JUnitReporter.new("test-reports")

הג'ם שמפעיל את זה נקרא minitest-reporters והוא נמצא ב Gemfile.

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

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

"It's funny, people have been asking me since I got here, 'When is Yahoo going to have 20% time?'" she said on stage during an all-employee meeting at Yahoo. "I've got to tell you the dirty little secret of Google's 20% time. It's really 120% time."

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

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

כששאלו בראיון את קן ת'ומפסון (הממציא של מערכת יוניקס) אם העבודה על יוניקס אותה הוא עשה במהלך העבודה שלו ב AT&T היתה חלק מהמשימות הרשמיות שלו שם הוא ענה:

No, I was sort of incorrigible, to be honest. I suspected that I would eventually get fired, but it didn’t bother me. We were supposed to be doing basic research but there was some basic research we should be doing and some basic research we shouldn’t be doing. And just coming out of the ashes of MULTICS, operating systems was one of those basic research things we shouldn’t be doing

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

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

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

נניח בשביל הדוגמא ש master הוא הענף הראשי ו dev הוא ענף פיצ'ר קטן, והקומיטים שלהם נראים כך:

$ git log --oneline master
b4ff474 (HEAD -> master) c4
9da14d1 c3
146d73d c2
e82851f c1

$ git log --oneline dev
433746a (dev) c7
8324f82 c6
da5ccb8 c5
146d73d c2
e82851f c1

במצב כזה merge רגיל יחבר את כל הקומיטים כך שנקבל את עץ הפרויקט הבא:

$ git merge dev
$ git log --oneline --graph

*   9b80e8d (HEAD -> master) merge commit
|\  
| * 433746a (dev) c7
| * 8324f82 c6
| * da5ccb8 c5
* | b4ff474 c4
* | 9da14d1 c3
|/  
* 146d73d c2
* e82851f c1

הקומיטים c7, c6 ו-c5 שבוצעו ב Feature Branch עכשיו נמצאים איתנו ויישארו בעץ הפרויקט לנצח. דרך אחת לוותר עליהם היא "לכווץ" אותם לפני ביצוע המיזוג:

1. נעבור לענף dev

2. נחזיר את HEAD אחורה ל C2 בלי לשנות את הקבצים בתיקיית העבודה (עם פקודת reset). הקומיט C2 הוא הקומיט המשותף האחרון בין dev ל master ולכן זה בעצם הקומיט שהתחיל את הפיצול. החזרה אליו תאפשר לנו "לאחד" את קומיטים C5, C6 ו C7 לקומיט חדש יחיד.

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

אחרי פעולה זו ב dev יהיה רק קומיט יחיד (הקומיט שעשינו בסעיף 3), וכשנמזג אותו חזרה ל master נראה בהיסטוריה רק את הקומיט היחיד הזה.

לגיט יש קיצור דרך לרצף הזה שעושה משהו אפילו יותר נחמד: הפקודה git merge --squash תיקח את כל הקבצים מענף dev למקום הנוכחי בלי להזיז את HEAD, בלי לעשות קומיט ובלי לעדכן את MERGE_HEAD. הדבר השלישי אומר שהקומיט הבא לא יהיה Merge Commit עם שני הורים אלא קומיט רגיל.

בקוד זה נראה כך:

$ git merge --squash dev
$ git log --oneline --graph

* b4ff474 (HEAD -> master) c4
* 9da14d1 c3
* 146d73d c2
* e82851f c1

עכשיו אפשר לעשות קומיט ולקבל:

$ git add .
$ git commit -m 'C8'
$ git log --oneline --graph

* 08f5e15 (HEAD -> master) C8
* b4ff474 c4
* 9da14d1 c3
* 146d73d c2
* e82851f c1

וקיבלנו מיזוג של Feature Branch לענף הראשי תוך מחיקת ההיסטוריה של ה Feature Branch ושמירה על לוג לינארי בענף הראשי.

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

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