ב-Google ו-Meta יש גישות עבודה ייחודיות לניהול גרסאות, שונות מאוד מאלו שמכירים בעבודה עם GitHub. בעוד שרוב העולם עובד בשיטת ה-Branch-based, חברות ענק כמו Google ו-Meta עובדות בשיטת Commit-based. הבדל זה נובע מהעובדה שבחברות אלו מתנהלים מול מונורפו עצום (Monorepo), שם המיזוגים (Merge) והענפים (Branches) פחות שימושיים לניהול בקנה מידה כה גדול. תחשבו על זה שבזמן שאתם עובדים על הפיצ׳ר כבר נכנסו 100 פיצ׳רים אחרים בגלל שיש עוד עשרות אלפי מפתחים שעובדים איתכם על אותו codebase.
בגוגל, לדוגמה, כל שינוי מתבצע בצורה של שינוי קטן המכונה CL (קיצור של Change List), אשר מתבסס על המאסטר ומותאם לעבודה בסביבה שבה מתרחשים עשרות אלפי שינויים מדי יום. כל קומיט הוא בעצם CL שהופך אוטומטית לסוג של PR (קיצור של Pull Request).
כלי כמו Graphite מאפשר לעבוד בגישה זו גם ב-GitHub, ומקל על המפתחים שרוצים ליהנות מהיתרונות של CLים קטנים גם מחוץ לחברות הגדולות.
דוגמה להבדל בהיסטוריית Git:
גישה מסורתית עם Branches במקרה הטוב
* Merge feature-branch into main
|\
| * Change title text
| * Added utility function
| * Refactored API layer
| * Fixed bug
|/
* Previous commitבמקרה הרע
* Merge feature-branch into main
|\
| * wip
| * wip
| * wip
| * wip
|/
* Previous commitהתהליך של ה-CR (Code Review) יתבצע בסוף על כל הקוד, מה שמייצר PR גדול עם המון קוד שלאו דווקא קשור אחד לשני.
גישה Commit-based עם CLים קטנים
* Change title text
* Added utility function
* Refactored API layer
* Fixed bug in serviceהתהליך של ה-CR יתבצע עבור כל קומיט, מה שמייצר מספר PRים קטנים שקל לעבור עליהם.
למה CLים קטנים חשובים כל כך?
יתרונות מרכזיים:
- מהירות ותשומת לב ב-Code Review
שינויים קטנים קל יותר לבדוק, מה שמוביל ל-CR מהיר וממוקד. - מניעת באגים בקלות
שינוי קטן מאפשר גם לכם וגם למבקר הקוד להבין את ההשלכות שלו בצורה ברורה יותר. - קלות במיזוג ועדכונים תכופים
בפרויקטים גדולים, CL קטן משתלב טוב יותר עם מאגרי קוד שמתעדכנים כל הזמן. - עבודה יעילה מול AI
על כך נרחיב בהמשך.
הגדרת CL "קטן":
CL צריך לטפל בבעיה אחת בלבד, לכלול בדיקות רלוונטיות, ולא להיות מפורק מדי כך שקשה להבין אותו.
לדוגמה: אם אתם מוסיפים API חדש, כללו ב-CL גם דוגמה לשימוש בו.
עבודה עם כלים מבוסס AI: למה כדאי להפוך כל פרומפט ל-Commit?
כשעובדים עם כלי AI כמו GitHub Copilot או Cursor AI, כדאי להקביל בין עבודה עם פרומפטים לעבודה עם Commits. כלומר, כל פרומפט צריך לייצר שינוי ממוקד, שמהווה Commit בפני עצמו. כך ניתן לשמור על זרימה מסודרת, להימנע מבעיות, ולנצל את היכולות של ה-AI בצורה יעילה יותר.
פרומפטים ארוכים = Commitים מסובכים
כשם ש-Commit גדול מדי עלול להיות מבלבל, קשה לניהול, ולהסתבך בלוגיקות שונות, גם פרומפט ארוך מדי לכלי AI עלול לגרום לתוצאות לא מדויקות או אפילו "הזיות" של הקוד. ה-AI עשוי לנסות לקשור בין רעיונות מורכבים מדי ולהכניס שגיאות לוגיות או מבנים לא נכונים.
Commit = נקודת שמירה
Commit קטן דומה לנקודת שמירה במשחק מחשב. הוא מאפשר לחזור אחורה, לבדוק מה השתנה, ולהבין את ההשלכות של כל צעד בקלות. כשכל פרומפט מתורגם ל-Commit נפרד, ניתן להבטיח שהקוד יישאר קריא ומסודר והכי חושב הפרוייקט ירוץ ולא יהיה איזה Error, ואפשר יהיה לעקוב אחרי כל שלב בכתיבתו.
לדוגמה
- פרומפט 1: "Add a function to validate email addresses."
Commit: הוספת הפונקציהvalidateEmail. - פרומפט 2: "Write unit tests for validateEmail."
Commit: הוספת בדיקות יוניט לפונקציה. - פרומפט 3: "Integrate validateEmail into the user registration process."
Commit: שילוב הפונקציה בתהליך הרישום.
אם יתגלה באג, קל לאתר אותו כי כל שלב תועד בנפרד.
זרימת עבודה ברורה יותר בצוות
בצוות פיתוח, Commitים קטנים משפרים תקשורת ושיתוף פעולה. כשאפשר לראות מה כל פרומפט יצר ואיך הוא מתקשר לקוד הקיים, קל יותר לדון על שינויים, לבדוק אותם, ולשפר את התהליך.
לסיכום
שימוש בפרומפטים כ-Commitים קטנים הופך את העבודה עם AI לממוקדת יותר, מקטין את הסיכון לטעויות ומקל על המעקב אחרי הקוד. נסו לחשוב על כל פרומפט כעל צעד ברור ומוגדר, כך שבמקרה של בעיה תוכלו לחזור אחורה לנקודת השמירה האחרונה בקלות.
גילוי נאות: הפוסט נכתב בעזרת AI בשיטה המתוארת כדלהלן 😊
