Git

שיטות עבודה מומלצות

אוסף עקרונות שאספתי לאורך השנים. ככל שתעבוד עם git יותר, תאמץ את העקרונות האלה אוטומטית.

הודעות commit

הכלל החשוב ביותר: למה, לא מה

הקוד מראה מה השתנה. ההודעה צריכה להסביר למה.

❌ רע: Update LoginForm.jsx ✅ טוב: Fix login race condition when user double-clicks submit

❌ רע: Add new file ✅ טוב: Extract useIsMentor hook to remove duplication across screens

פורמט

• כותרת: עד 50 תווים
• שורה ריקה
• תיאור (אופציונלי): פסקאות ארוכות יותר עם פרטים

Stabilize DojoHomeScreen layout

Memoize photos array to prevent unnecessary re-renders.
Add early return when state is null to avoid flashing.
Resolves flicker reported by QA on slow networks.

זמן ציווי (Imperative)

כותבים כאילו נותנים הוראה לקוד:

✅ Add validation to login form ❌ Added validation to login form ❌ Adding validation to login form

פעלים נפוצים

• Add - הוספת פיצ'ר חדש
• Fix - תיקון באג
• Update - שיפור פיצ'ר קיים
• Refactor - ארגון מחדש בלי שינוי התנהגות
• Remove - מחיקה
• Extract - הוצאת קוד לפונקציה / hook
• Wire - חיבור בין רכיבים
• Stabilize - תיקון יציבות

ללא קונבנציות לא נחוצות

לא חייבים feat:, fix:, chore: (Conventional Commits) אלא אם הצוות שלכם משתמש בזה. גם לא צריכים אימוג'ים.

Commits אטומיים

כל commit צריך לעשות דבר אחד. אם אתם משתמשים ב"and" בהודעה - זה סימן לחלק את ה-commit:

❌ רע: Add login form and fix dashboard styling ✅ טוב: שני commits נפרדים

יתרונות של commits אטומיים: - קל לעשות revert ל-commit ספציפי - היסטוריה ברורה - code review קל יותר - bisect (חיפוש באג בינארי) עובד טוב

Branches

שמות תיאוריים

feature/user-profile-page
bugfix/login-error-message
hotfix/security-patch-cve-2024
chore/upgrade-react-19

branches קצרי-חיים

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

מחיקה אחרי merge

אל תשאירו branches שכבר מוזגו. נקו אחרי עצמכם:

git branch -d feature/done
git push origin --delete feature/done

סנכרון תכוף

פעם ביום לפחות

git switch main
git pull
git switch your-feature
git rebase main      # או git merge main

ככה אתם לא מגיעים למצב של 50 קונפליקטים ביום שאתם מנסים למזג ל-main.

.gitignore נקי

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

דוגמאות נוספות בשיעור 14.

אבטחה

לעולם לא לdcommit סודות

• API keys
• סיסמאות
• private keys
• access tokens
• קבצי .env

אם בטעות הוספתם סוד וכבר עשיתם push: 1. שנה את הסוד מיד (זה הצעד הקריטי) 2. השתמשו ב-BFG Repo-Cleaner או git filter-repo כדי להסיר מההיסטוריה 3. force push (אחרי תיאום עם הצוות)

בדיקה לפני git add .

git status      # לפני
git diff        # לפני
git add .       # רק אחרי שראית שהכל ok

פעולות הרסניות - בזהירות

אסור על branches משותפים

• git push --force ל-main
• git rebase של commits שכבר נדחפו
• git reset --hard ל-commits שכבר נדחפו

השתמשו בחלופות בטוחות

• git push --force-with-lease במקום --force
• git revert במקום git reset --hard
• merge במקום rebase ל-branches משותפים

Pull Requests קטנים

PR שמכיל 1000 שורות שינוי לא יקבל review טוב. עדיף 5 PRs של 200 שורות כל אחד.

חוקי הפלדה

1. לעולם אל תעשו force push ל-main
2. לעולם אל תcommit סודות
3. לפני push - תמיד git status ו-git diff --staged
4. לפני pull - תמיד git status שלא מאבד עבודה
5. בכל ספק - git stash ושאל מישהו

כלי עזר מומלצים

Aliases חוסכי זמן

git config --global alias.co checkout
git config --global alias.br branch
git config --global alias.ci commit
git config --global alias.st status
git config --global alias.unstage 'reset HEAD --'
git config --global alias.last 'log -1 HEAD'
git config --global alias.visual 'log --graph --oneline --all'
git config --global alias.adog 'log --all --decorate --oneline --graph'

Hooks

ב-.git/hooks/ אפשר להגדיר scripts שרצים אוטומטית. לדוגמה, pre-commit שמריץ linter לפני כל commit.

Husky (ל-Node.js)

ספרייה שמקלה על ניהול hooks ושיתופם בין מפתחים.

סיכום: הרגלים יומיומיים

• 🌅 בוקר: git pull במצב נקי
• 💻 לפני עבודה: branch חדש מ-main מעודכן
• ✏️ commits אטומיים, הודעות ברורות
• 🔄 לפני סיום יום: git push
• 🧹 אחרי merge: ניקוי branches
• 🚫 בכל ספק: git status, אל תעשו כלום הרסני