בוובינר השבוע דיברנו על גיט מנקודת המבט של עבודה עם סוכני קידוד. ראינו שתי תבניות עבודה פופולריות עם סוכנים, Spec Driven Development ו Step By Step Prompts ואיך גיט משתלב בכל אחת. בואו ניזכר מה היה שם.

1. גיט ו Spec Driven Development

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

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

$ git add spec/
$ git commit -m 'SPEC: new design'

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

$ git restore . && git clean -f -d

שיפרנו את קובץ הפרומפט, הכנסנו לגיט את הקובץ המתוקן:

$ git add spec/
$ git commit --amend

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

$ git add .
$ git commit -m 'IMPL: new design'

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

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

$ git branch new-design

פקודת git branch יצרה ענף חדש אבל השאירה אותי על main. אחרי זה לקחנו "צעד אחורה" וביטלנו את הקומיט של ה spec עם:

$ git reset --hard HEAD~

ואז יצרנו קובץ spec חדש ואת המימוש בשביל הפיצ'ר שהיה חסר, אחרי הקומיט החזרנו את הקומיט מהענף באמצעות ריבייס:

$ git switch new-design
$ git rebase main
$ git switch main
$ git merge new-design
$ git branch -d new-design

וכך קיבלנו:

<commit hash> SPEC: new design
<commit hash> IMPL: bugfix in webapp
<commit hash> SPEC: bugfix in webapp
<commit hash> IMPL: app start
<commit hash> SPEC: app start

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

2. פיתוח Step By Step

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

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

- prompt -> generate code -> commit
- prompt -> generate code -> commit
- prompt -> generate code -> commit
- prompt -> generate code -> commit
- prompt -> generate code -> commit
- prompt -> generate code -> commit
- prompt -> generate code -> commit

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

$ git switch -c new-design

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

$ git reset --hard HEAD~3

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

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

$ git merge --squash new-design

פקודה זו לוקחת את כל הקבצים מענף new-design, מעתיקה אותם לענף main ומכניסה ל Staging בלי לקחת את הקומיטים. עכשיו נשאר לי רק לכתוב git commit ולנסח הודעת קומיט אחת שמתאימה לכל הפיצ'ר וכך אני זורק את כל היסטוריית הקומיטים של הענף ונשאר רק עם הגרסה החדשה ביותר שלו והודעת קומיט טובה. פקודת branch -d מוחקת את הענף ואפשר להמשיך בחיים:

$ git commit
$ git branch -d new-design

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

$ git switch new-design
$ git rebase -i main

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

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

https://chatgpt.com/share/6a59b2cf-ddcc-83eb-b176-49db4d3ecf37