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

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

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

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

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

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

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

במנגנון הראשון הייתי מוסיף לכל דרישה מוצרית (בין אם הגיעה מ Product ובין דרישה פנימית מהפיתוח):

1. מי צריך את הפיצ'ר הזה?

2. מה הבעיה שהפיצ'ר אמור לפתור לאותו לקוח?

3. מה אותו לקוח עושה היום?

4. איך הפיצ'ר ישנה את ה Workflow של הלקוח?

5. איזה פיצ'רים אחרים עשויים להשפיע על אותה בעיה?

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

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

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

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

ככל שחברנו ה AI הולך לעזור יותר בכתיבת קוד, כך היכולת להסתכל על ה"מה" לפני ה"איך" הופכת להיות חלק בלתי נפרד מהעבודה שלנו.

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

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

אבל בפרויקט צד? בפרויקט ללימודים? בקורס?

אחת המטרות של פרויקטים נטולי סיכון היא לקבל מרחב בטוח להתנסות, מרחב שבו אפשר לכתוב אפליקציה בגישת Micro Services גם אם זה Overkill, להכניס בסיס נתונים מבוזר (או 5 בסיסי נתונים), לעצב דף בית תלת מימדי עם Three.js וכן גם לכתוב את ה Front End בלי אף פריימוורק ואת צד השרת ב Rust. לא יודע איזה מהרעיונות האלה יעבוד לפרויקט שלכם וכמה מפרויקטי הלימודים האלה באמת יצליחו להתרומם, אבל מה שבטוח שבסיום הכתיבה תהיה לכם הבנה טובה של שיטת עבודה חדשה, ואולי חלק משיטות העבודה האלה יעזרו לכם גם לפרויקטים אמיתיים.

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

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

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

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

type Table = Array<Array<number>>;

function duplicateRow(table: Table, rowIndex: number): Table {
    if ((rowIndex >= table.length) || (rowIndex < 0)) {
        throw new Error("row index out of range")
    }

    return [...table.slice(0, rowIndex), table.at(rowIndex), ...table.slice(rowIndex)];
}

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

וטיעון שלישי הוא הקהילה. גם אם אנחנו מצליחים להתמודד עם הסיבוכיות בקוד שלנו הרבה מאוד ספריות טייפסקריפט כוללות אינסוף טריקים של השפה כדי ליצור בצורה אוטומטית את הגדרות הטיפוסים לפי קוד שאנחנו כותבים. לדוגמה רידאקס טולקיט לוקחת את קוד ה Reducers ויוצרת ממנו הגדרות טיפוסים, אבל אם יש טעות קטנה בקוד או אפילו מבנה שהוא לא בדיוק מה שכותבי Redux Toolkit התכוונו אנחנו יכולים למצוא את עצמנו מול הודעות שגיאה איומות שייקח הרבה זמן לפענח. או אפולו שמכניסה להגדרות הטיפוסים ממש את שאילתות ה GraphQL (כמחרוזת מילה במילה) ואז אם אחרי יצירת הטיפוסים אני משנה אפילו פסיק או רווח בשאילתה פתאום כל מערכת הטיפוסים מפסיקה לעבוד. או קיסלי שמבין לבד את מבנה הטבלאות וגוזר ממנו דינמית הגדרות טיפוסים כדי ששאילתות שאנחנו כותבים יהיו Type Safe ובדרך מביא את טייפסקריפט לקצה. כל עוד זה עובד וכל הגדרות הטיפוסים המוזרות מוכלות רק בתוך קוד הספריה הכל בסדר, אבל כמעט בכל ספריה מגיע רגע שצריך להיכנס פנימה לקוד שלהם כדי להבין איך לכתוב את הטיפוסים כך שטייפסקריפט יהיה שמח.

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

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

וככה למרות ש Functional Components זה הדבר, עדיין אפשר להשתמש ב Class Components והכל יעבוד.

ולמרות ש Concurrent Mode זה הדבר, עדיין אפשר להפעיל ריאקט בלעדיו והכל יעבוד.

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

This was when we were more bullish about lazy fetching being a good idea some of the time (when combined with prefetching), as opposed to our latest thinking, which is that it's almost always a bad idea.

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

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

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

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

אפשר למצוא את הקוד והתוצאה בסטאקבליץ כאן: https://stackblitz.com/edit/vitejs-vite-r29prn?file=src%2Fmy-element.ts

וזה הקוד בהדבקה:

import { LitElement, css, html, unsafeCSS } from 'lit'
import { customElement, property } from 'lit/decorators.js'
import litLogo from './assets/lit.svg'
import viteLogo from '/vite.svg'
import _ from 'lodash';
import style from "./index.css?inline";

@customElement('my-cell')
export class MyCell extends LitElement {
  static styles = unsafeCSS(style);
  static shadowRootOptions = {...LitElement.shadowRootOptions, delegatesFocus: true};


  handleKeypress(ev: KeyboardEvent) {
    if (ev.key === "Enter") {
      if (this.shadowRoot?.activeElement === this.shadowRoot?.querySelector('td')) {
        // td is in focus
        this.dispatchEvent(new Event('focusinside', {composed: true, bubbles: true}))
      } else {
        this.shadowRoot?.querySelector('td').focus();
      };
    } else if (ev.key === "ArrowRight") {
      this.dispatchEvent(new Event('focusright', {composed: true, bubbles: true}))
    } else if (ev.key === "ArrowLeft") {
      this.dispatchEvent(new Event('focusleft', {composed: true, bubbles: true}))
    } else if (ev.key === "ArrowUp") {
      this.dispatchEvent(new Event('focusup', {composed: true, bubbles: true}))
    } else if (ev.key === "ArrowDown") {
      this.dispatchEvent(new Event('focusdown', {composed: true, bubbles: true}))
    }
  }

  takeFocus(ev: KeyboardEvent) {
    if (ev.key === "Enter") {
      this.shadowRoot?.querySelector('td')?.focus();
    }
  }

  render() {
    return html`<td
      tabindex="1"
      @keyup=${this.handleKeypress}
      class="border-dashed border border-1 border-gray-500 focus:border-solid focus:border-green-200 focus:border-2"
    >
      <slot></slot>
    </td>
    `
  }
}

@customElement('my-table')
export class MyTable extends LitElement {
  static styles = unsafeCSS(style);

  @property({ type: Number })
  rows = 4

  @property({ type: Number })
  columns = 2

  focusUp(e: any) {
    const me = e.target;
    const tr = me.parentNode;
    const index = Array.prototype.indexOf.call(tr.children, me);
    tr.previousElementSibling.children[index].focus();
  }

  focusDown(e: any) {
    const me = e.target;
    const tr = me.parentNode;
    const index = Array.prototype.indexOf.call(tr.children, me);
    tr.nextElementSibling.children[index].focus();
  }

  render() {
    return html`
      <table class="bg-orange border-collapse"
        @focusinside=${(e: any) => e.target.firstElementChild.focus()}
        @focusright=${(e: any) => e.target.nextElementSibling.focus()}
        @focusleft=${(e: any) => e.target.previousElementSibling.focus()}
        @focusup=${this.focusUp}
        @focusdown=${this.focusDown}
      >
        <tbody>
          ${_.range(this.rows).map((i) => (
            html`
            <tr>
              ${_.range(this.columns).map((j) => (
              html`<my-cell>
                <input
                type="text"
                value="${`${i}, ${j}`}"
                class="outline-none bg-transparent border-none border-2"
              /></my-cell>`
              ))}
            </tr>
          `
          ))}
        </tbody>
      </table>
    `
  }
}

declare global {
  interface HTMLElementTagNameMap {
    'my-table': MyTable
    'my-cell': MyCell
  }
}

נעבור בצורה זריזה על הרעיונות החשובים שלמדתי מכתיבת הדוגמה:

1. כשאני בתוך קומפוננטה של "תא" ורוצה להעביר פוקוס הדרך היחידה שלי לצאת החוצה לקומפוננטה של הטבלה היא לשלוח אירוע. רק קומפוננטת הטבלה יכולה לקבל את האירוע ולהעביר את הפוקוס.

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

3. אבל כשאני רוצה להעביר את הפוקוס מה input ל td שמכיל אותו - פה צריך כבר לקרוא ל focus מקומפוננטת ה"תא בטבלה" כי היא זאת שיצרה את ה td. בקיצור כל קומפוננטה ב Shadow DOM אחראית על האלמנטים שהיא יוצרת.

עוד שתי נקודות שלמדתי מהדוגמה הזאת על ליט:

1. הגדרת קובץ CSS לכל העמוד לא משפיעה על הקומפוננטות של lit. כל קומפוננטה חייבת להגדיר את קובץ ה CSS בעצמה. מאוד מעייף כשרוצים להגדיר עיצוב גלובאלי באפליקציית lit.

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

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

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

הפונקציה reverse של JavaScript מופעלת על מערך והופכת את האיברים בו:

> const x = [1, 2, 3, 4];
undefined
> x.reverse()
[ 4, 3, 2, 1 ]

הגירסה החדשה שלה toReversed מחזירה עותק חדש של המערך עם האיברים הפוכים:

> const x = [1, 2, 3, 4]
undefined
> x.toReversed()
[ 4, 3, 2, 1 ]
> x
[ 1, 2, 3, 4 ]

נשים לב שכשהמערך מקונן האלמנטים הפנימיים לא מועתקים, לכן:

> const x = [{a: 10}, {a: 10}, {a: 20}, {a: 30}]
undefined
> x.toReversed()
[ { a: 30 }, { a: 20 }, { a: 10 }, { a: 10 } ]
> x.toReversed()[0].a = 40
40
> x
[ { a: 10 }, { a: 10 }, { a: 20 }, { a: 40 } ]

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

> const values = [1, 10, 21, 2];
undefined

> values.toSorted()
[ 1, 10, 2, 21 ]

> values.toSorted((a, b) => a - b)
[ 1, 2, 10, 21 ]

אפשר לחשוב על שתיהן בתור גירסה מהירה וברורה יותר של array.slice().reverse() ו array.slice().sort:

> x.slice().reverse()
[ 9, 1, 2, 10 ]
> x
[ 10, 2, 1, 9 ]

> x.slice().sort()
[ 1, 10, 2, 9 ]
> x
[ 10, 2, 1, 9 ]

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

1. בחרו חבר או חברה עם רקע שונה משלכם. המטרה של Pair Programming היא לא לכתוב קוד כמה שיותר מהר אלא לדבר על הדברים המשמעותיים בתהליך הפיתוח. ככל שיש פער ברקע שלכם אפשר יהיה לקבל נקודת מבט נוספת ומעניינת על הארכיטקטורה.

2. בחרו טכנולוגיות אותן לפחות אחד הצדדים מבין או מבינה היטב. המטרה של Pair Programming היא הדיון, אז אנחנו רוצים לצמצם זמני Debug וזמני חיפוש באינטרנט.

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

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

5. גיט סטאש הוא חבר - חלק מהמשחק של לעבוד ביחד זה להיחשף לרעיונות חדשים שלא הייתם מנסים אם הייתם לבד. חלק מהרעיונות האלה טובים, חלק גרועים וחלק לא מספיק מלוטשים. אני משתדל לקבור מהר עם git restore את הרעיונות הגרועים, אבל את הלא מלוטשים להשאיר בצד עם git stash. יום אחד אולי יהיה זמן לחקור אותם שוב. או שלא. וזה בסדר.

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