לא מזמן נתקלתי בפרויקט דמו שנוצר באמצעות LLM, המחבר שלו יצר אותו עם גיטהאב קופיילוט והציג אותו לראווה בלינקדין. תוך כמה שניות היו לי את ה secret credentials שלו לכמה שירותים ומסמכים סודיים נוספים כמו כל התכתובת של עם הקופיילוט שתועדה מסיבה מסוימת.
הקבצים האלו לא היו בפרויקט, לא בדקתי בכלל את הפרויקט עצמו. בדקתי את החלק היותר מעניין: היסטורית הקומיטים. המידע הזה היה היסטורית בפרוייקט אבל מתישהו היוצר שם לב לכך ומחק (או ביקש מהקופיילוט שלו) למחוק את הקבצים האלו. אבל ההיסטוריה לא שוכחת כלום.
פסקת הסבר למי שלא מכיר גיט
גיט ובאנגלית git זו מערכת לניהול גרסאות. מדובר במערכת שמסייעת לנו לנהל תוכנה גם בהיקפים עצומים. גיט נוצרה לפני עשרים שנה, בשנת 2005 על ידי לינוס טורוולדס, ממציא לינוקס והיום היא הסטנדט המלא בתחום ניהול הגרסאות ואין כמעט אף אחד שלא משתמש בה. חברות קטנות, גדולות וכמובן אנשים פרטיים. מי שרוצה ללמוד – יש גם קורס קצר פה וגם ספר מקיף שכתבתי שבחלקו הראשון יש הסבר על גיט ועל גיטהאב, מערכת סופר פופולרית לאחסון גיט מרוחק.
LLM וגיט
גם וייב קודרים שמשתמשים במערכות מבוססות LLM (מודלי שפה גדולים, השם המקצועי ל״בינה מלאכותית״ שאינה בינה בכלל אלא מחולל טקסט סביר סטטיסטית) משתמשים בגיט ובגיטהאב, אבל בניגוד למתכנתים מקצועיים, לא תמיד יש הבנה מלאה מה זה הדבר הזה ולא מעט פעמים מתייחסים לגיט כאל מערכת גיבוי. כמו סוג של ״שמירה״ מקומית ואם דוחפים לגיטהאב, אז סוג של ״שמירה״ בענן שמבטיחה שגם אם ה-LLM יתחרפן, נוכל לחזור לגיבוי.
חשוב לשמור וללחוץ קונטרול S (או תלחץ קומנד אם אתה על מק), אבל זה לא המהות של גיט!
ההתייחסות לגיט כמערכת שמירה בלבד וחוסר הנחיה ועבודה נכונה בגיט זו הסיבה שבלא מעט פרויקטים שנוצרו על ידי LLM לסוגיו השונים אנחנו לא רואים שימוש בגיט פלואו נכון. כלומר פול ריקווסט מסודר, שימוש בבראנצ׳ים, ריבייס או squash. זה מאפשר לנו גם תיקונים מהירים במקרה שדברים משתבשים (הרבה יותר קל להפעיל למשל git bisect) והבנה של התפתחות הפרויקט, חזרה לגרסאות אחרות ועבודה במקביל. כשעובדים לבד בפרויקט פשוט ועוד נותנים ל LLM לנהל את הגיט בלי הכוונה מסודרת, זה נראה לא מקצועי.
זה לא אומר ש-LLM לא יודע לעבוד עם גיט. אבל צריך לומר לו.
הנה למשל הוראות של cursor שמסדירות את נושא העבודה מול גיט שאני עובד איתם. שימו לב רק שהקישור לג׳ירה שיש פה הוא דמה וכן תחילית הטיקט BU היא דמיונית ולא מייצגת משהו אמיתי. בפועל הקישור הוא למערכת ג׳ירה אמיתית והטיקט עונה לסטנדרטים שלנו, שהם סטנדרט של FedRAMP (למי שלא יודע סטנדרט אמריקאי שעובדים לפיו ומחייב למשל קשר בין כל שינוי שנעשה בקוד לטיקט ובקישור יש מידע על זה כולל פרק בפודקאסט על זה)
---
alwaysApply: true
---
# GitHub Workflow Rules
## MANDATORY: uv run pylint Before Git Push
**CRITICAL RULE**: Before executing ANY `git push` command, you MUST:
1. Run `uv run pylint` first
2. Ensure it passes successfully
3. Only proceed with push if `uv run pylint` passes
4. If `uv run pylint` fails, fix all issues before pushing
This rule applies to ALL file types and ALL changes in the repository.
## Git Workflow and Pull Requests
### Branch Naming Convention
All branches MUST follow this template:
```
BU-TICKETNUMBER-[feature|issue]-description
```
Examples:
- BU-1234-feature-add-session-logging`
- `BU-5678-issue-fix-memory-leak`
### Commit Message Format
All commits MUST follow this template:
```
BU-TICKETNUMBER: [feature|issue]: header: description
```
Examples:
- `BU-1234: feature: session logging: Add comprehensive session event logging`
- `BU-5678: issue: memory leak: Fix memory leak in event processor`
### Creating Pull Requests
Use GitHub CLI (`gh`) to create pull requests:
```bash
# Create PR with proper title and description
gh pr create --title "IAI-1234: feature: description" --body "Detailed description of changes"
```
**IMPORTANT**: After creating the PR, you MUST properly fill out the PR template:
- Use `gh pr edit <PR_NUMBER> --body "..."` to update the PR description
- Complete ALL sections of the template:
- Description with JIRA ticket number AND link (e.g., "JIRA Ticket: BI-1234 - https://my-company-jira.com:8443/browse/IAI-1234")
- Type of Change (mark appropriate boxes)
- Changes Made (list all key changes)
- Testing section (confirm all requirements)
- Test Details (describe tests)
- Checklist (check all applicable items)
- Additional Notes (provide context for reviewers)
- Mark checkboxes with `[x]` for completed items
- Mark N/A for items that don't apply (e.g., documentation-only changes)
- ALWAYS include a clickable JIRA ticket link in the PR description
העבודה הנכונה עם גיט מאפשרת לי לא להתייחס אליו רק כמערכת שמירה אלא גם להבין בו ואת היכולות שלו.
למה אני צריך להבין בזה?
למה זה חשוב? מלבד התועלת הברורה בלהבין מערכת שאתה עובד איתה והיא תשתית מרכזית של תחום פיתוח התוכנה, הבעיה שגיט זו לא מערכת ששומרת דברים כמו איזה save אלא מערכת לניהול גרסאות שחלק מהפיצ׳רים שלה היא לחזור לקוד. כלומר אם אני מכניס לתוכה משהו, בלי מאמץ מאד מאד מאד גדול ומודע? זה גם יישאר שם.
למשל, אם שמתי לב שה-LLM הוסיף לי קובץ שנקרא secrets ויש שם מפתחות סודיים ומחקתי אותו ועשיתי שוב קומיט? הקובץ יהיה גלוי לכולם. איפה? לא בקבצי הפרויקט עצמם כפי שרואים אותם בגיט אלא בהיסטורית הקומיטים. איך רואים את ההיסטוריה? מתחת לכפתור הירוק של Code בגיטהאב יש קומיטים.
לחיצה על האייקון עם השעון תביא את רשימת הקומיטים:
לחיצה על כל שורה מראה את כל השינויים שהיו בין שינוי לשינוי.
The world is dark and full of errors
במקרה של פרויקט הדמו זה היה מביך, אבל לא מזיק. איש לא השתמש באפליקציה ולא ישתמש בה. היא נבנתה מתוך ניסיון לבנות תיק עבודות ולא נגרם נזק מלבד אולי לאגו של היוצר כאשר פניתי אליו והצגתי בפניו למשל את ההתכתבות המלאה שלו עם הקופיילוט שנשמרה גם באחד הקומיטים ולמרות שהוא מחק אותה מאוחר יותר, היא תשאר לדראון עולם. אבל זה מראה כמה סיכונים יש בעולם פיתוח התוכנה שמבוסס על ידי LLM שפשוט שקופים. פיתוח תוכנה זה לא רק עניין של קוד אלא גם של תשתיות ולמרות שיש תחושה ש״הכל אפשרי״, לעתים התחושה הזו היא מטעה.
מה עושים אם קובץ בעייתי נכנס לקומיטים שלי?
הדבר הראשון הוא להניח שהקובץ נחשף (אנשים רעים מפעילים סורקים בגיטהאב ומנצלים מייד כל מפתח שהם מוצאים) ולעשות rotate לטוקנים או למידע. אם מדובר במפתח, שינוי שלו בדרך כלל הוא הפתרון המיידי.
אם מדובר בקובץ סודי שרוצים למחוק אותו – כמו למשל כל ההערות שלי לגיטהאב וההתכתבות שלי איתו – אז ריבייס זה בדרך כלל מה שפותר את העניין. לא כל הקומיטים… יכולים להיות טובים:
פתרון הבעיה מהשורש
בדרך כלל פתרון הבעיה הוא עבודה עם פול ריקווסטים מסודרים (כן, גם בפרויקט יחיד) ובחינה מדוקדקת של כל מה שנכנס. זה גם אומר שעובדים בסייקלים קצרים ומהירים כדי שנוכל לבחון כל שינוי, בעבודה מתוכננת ובטוחה ובעצם בדיוק הפוך מכל תכנות לפי תחושה.
אם כן רוצים לעשות וייב קודינג, אז אפשר לעבוד מקומית ורק אחר כך לסרוק את כל הבושות. או להיות מוכנים לעבוד עם ריפו סגור ופרטי ואחר כך לנקות את ההיסטוריה ולדחוף את הקוד כריפו ציבורי. אם אתם מתכנתים וזה לא אומר לכם כלום – זה הזמן המעולה ללמוד. המקצוע הולך ומשתנה, לכתוב קוד מעולם לא היה עיקר המקצוע עבור סניורים אבל עכשיו זה כבר לא עיקר המקצוע עבור כולם. הבנה עמוקה בתשתיות ובמערכות השונות תסייע לכם להמנע משגיאות וכמובן להאיץ את העבודה. העובדה שאני יודע לעבוד היטב עם גיט מאפשרת לי להנחות את ה-LLM בצורה מיטיבית וגם לבחון את הקוד שלו ביותר קלות.
היום זו היסטורית קומיטים, מחר זה משהו אחר. תקנות הפרטיות החדשות זה גיהנום לא קטן בדליפות מידע ואתם אחראים על הקוד שלכם. כל הקוד. גם זה שלא תמיד נכתב או מופיע בגרסה האחרונה של הפרויקט.
