Git

Pull Requests

Pull Request (PR) - או Merge Request ב-GitLab - הוא הדרך הרשמית להצעה למזג שינויים מ-branch אחד לאחר. זה מנגנון מרכזי של עבודה צוותית: מאפשר code review, דיון, בדיקות אוטומטיות והתאמות לפני שהשינוי נכנס ל-main.

מהו PR בעצם?

טכנית, PR הוא "אני מבקש לקחת את ה-commits מ-branch X ולמזג אותם ל-branch Y". מסביב לבקשה הזו, GitHub מציע:

• צפייה ב-diff
• תגובות על שורות קוד ספציפיות
• אישורים (approvals)
• בדיקות אוטומטיות (CI)
• היסטוריה של דיונים

איך יוצרים PR?

דרך CLI עם gh

gh pr create --title "Add user profile" --body "Description here"

דרך GitHub UI

1. דוחפים את ה-branch לשרת: git push -u origin feature/user-profile
2. נכנסים ל-GitHub - יוצא באנר "Compare & pull request"
3. ממלאים title ו-description
4. בוחרים reviewers
5. לוחצים "Create pull request"

כתיבת תיאור PR טוב

תיאור טוב חוסך זמן ל-reviewers. הוא עונה על השאלות: - מה השתנה? - למה? - איך לבדוק?

פורמט מומלץ

## Summary
- Add user profile component with avatar and bio
- Wire profile data fetching from /api/users/me
- Add edit button that opens modal

## Changed files
| File | Change |
|------|--------|
| `src/screens/UserProfile.jsx` | New component |
| `src/api/users.js` | Add fetchCurrentUser |
| `src/components/EditModal.jsx` | New shared modal |

## Related PR
- DojoAppOrg/dojoadmin#42 (admin side)

## Test plan
- [ ] Open profile screen, verify avatar loads
- [ ] Edit bio, save, verify it updates
- [ ] Test on iOS + Android
- [ ] Verify error state when API fails

כללים לכתיבת PR

✅ עשה

• כותרת קצרה ותמציתית (פחות מ-70 תווים)
• תיאור מסביר את הלמה
• קישור ל-issue או PR קשורים
• checklist לבדיקות
• screenshots / GIFs לשינויי UI

❌ אל תעשו

• אל תפתחו PR ענק עם 50 קבצים שונים - חלקו אותו לכמה PRs קטנים
• אל תכתבו "fixes stuff" - היו ספציפיים
• אל תמזגו בלי אישור (אלא אם אתם עובדים לבד)
• אל תמזגו עם CI נכשל

גודל PR

PR טוב הוא קטן. ככלל אצבע: - פחות מ-400 שורות שינוי - פחות מ-10 קבצים - מטרה אחת ברורה

PR ענק קשה לעשות לו review כראוי, ולכן יקבל "LGTM" שטחי או יישכח לימים.

Code Review

כשאתם בודקים PR

• קראו את התיאור קודם
• קראו את ה-diff מתחילה לסוף
• שאל שאלות אם משהו לא ברור
• הציעו חלופה אם יש לכם רעיון, אבל תנו למחבר להחליט
• אישור (approve) רק אחרי שאתם מבינים את כל השינוי

כשאתם כותבי ה-PR

• ענה על כל תגובה (גם ב-thumbs up)
• אל תיקחו ביקורת באופן אישי
• עדכן את הקוד או הסבר למה לא
• מסמן comments כ-Resolved רק אחרי תיקון

תגובה על השינויים

GitHub מאפשר 3 סוגי תגובות:

merge strategies ב-GitHub

GitHub מציע 3 דרכים למזג PR:

הבחירה תלויה בקונבנציה של הצוות. הרבה ארגונים מעדיפים Squash and merge לפיצ'רים, כי זה משאיר את main עם commit אחד ברור לכל פיצ'ר.

דוגמת זרימה מלאה

# 1. עבדת על feature/login, סיימת
git add .
git commit -m "Add login form with validation"
git push -u origin feature/login

# 2. יוצרים PR
gh pr create --title "Add login form" --body "$(cat <<'EOF'
## Summary
- Add login form with email + password
- Wire to /api/auth/login
- Show error message on failure

## Test plan
- [ ] Login with valid credentials
- [ ] Login with wrong password (shows error)
- [ ] Loading state during request
EOF
)"

# 3. ה-CI רץ, reviewer מסתכל, מבקש שינוי
# 4. עובדים על השינוי
git add .
git commit -m "Address PR feedback: add password visibility toggle"
git push

# 5. ה-reviewer מאשר
# 6. squash and merge
# 7. מנקים
git switch main
git pull
git branch -d feature/login