GitHub Projects — ניהול פרויקטים כמו מקצוען

5.1 מה זה GitHub Projects ולמה לא לנהל משימות ב-Issues בלבד

רוב המפתחים מכירים Issues — פותחים issue לכל באג, משימה או feature request. הפותח נכנס, מקליד כותרת, אולי מוסיף label, ובזה נגמר. זה עובד כשיש 10 issues. כשיש 50, 100, או 300 — Issues בלבד הם רשימה שטוחה. אי אפשר לראות מי עמוס, מה דחוף, מה תקוע, ואיפה הפרויקט עומד בכללותו.

חשבו על זה ככה: Issues הם כמו פתקים על השולחן. כל פתק אומר "תעשה X". אבל אף פתק לא אומר "הנה כל מה שצריך לעשות השבוע", "אלו 3 האנשים הכי עמוסים", או "ככה נראית ההתקדמות שלנו ב-4 שבועות אחרונים". בשביל זה צריך שכבת ניהול מעל הפתקים.

GitHub Projects הוא בדיוק השכבה הזו. הוא לא מחליף Issues — הוא מוסיף להם מבנה, ראייה, ואינטליגנציה. Projects חי מעל Issues ו-PRs, ונותן ארבע יכולות שלא קיימות ב-Issues רגילים:

• שדות מותאמים — Priority, Effort, Sprint, Due Date — מטא-דאטה שלא קיים ב-Issues רגילים. במקום label "high-priority" שמרגיש כמו פלסטר, שדה Priority אמיתי עם אפשרויות מוגדרות וצבעים
• תצוגות מרובות — אותם נתונים, פרספקטיבה שונה. מנהל רואה Roadmap, מפתח רואה Board, PO רואה Table עם priorities. אף אחד לא צריך לוח נפרד
• אוטומציות — כש-PR מתמזג, הסטטוס מתעדכן ל-Done. כש-issue נפתח עם label "bug", הוא מתווסף אוטומטית לפרויקט. אף אחד לא צריך לזכור לעדכן את הלוח
• Insights — גרפים שמראים את המצב האמיתי. Burn-up chart שמוכיח אם אתם מתקדמים או עומדים במקום. התפלגות לפי assignee שמראה מי עמוס ומי פנוי

חשוב לדעת: Classic Project Boards (הגרסה הישנה) הוסרו בחלוטין ביוני 2025. כל מה שנלמד בפרק הזה הוא Projects v2 — הגרסה היחידה שנתמכת. אם יש לכם classic boards ישנים, הם הומרו אוטומטית. אם אתם קוראים מדריכים ישנים שמדברים על "Project boards" עם notes ו-columns בלבד — זה Classic, וזה כבר לא קיים.

ההבדלים העיקריים בין Classic ל-v2:

5.2 יצירת Project — מאפס ללוח עובד תוך 5 דקות

יש שתי דרכים עיקריות ליצור Project, ושתיהן לוקחות פחות מדקה. הבחירה ביניהן תלויה בסגנון העבודה שלכם — אם אתם אנשי UI, תלכו על הדרך הראשונה. אם למדתם את פרק 2 על gh CLI, הדרך השנייה תרגיש טבעית יותר.

דרך 1: מה-UI

1. לכו לפרופיל שלכם (או לעמוד הארגון) → טאב Projects
2. לחצו New project
3. בחרו template — Board הוא הנפוץ ביותר להתחלה, אבל יש גם Table, Team backlog, Feature, ו-Roadmap
4. תנו שם (למשל: "Sprint Board" או "Product Roadmap")
5. לחצו Create project

org-level vs repo-level — ההבדל הקריטי: Project ברמת ארגון יכול לאגד issues מכמה ריפוזיטורים — למשל, frontend, backend ו-infra בלוח אחד. Project ברמת repo מוגבל לאותו repo. תמיד העדיפו org-level — גם אם יש לכם repo אחד היום, מחר יהיו שניים. אם אתם עובדים עם חשבון אישי (לא ארגון), Project ברמת user עובד כמו org-level ומאפשר issues מכמה repos.

מה ההבדל פרקטי? אם יש לכם repo בשם frontend ועוד repo בשם api, ואתם רוצים לראות את כל המשימות בלוח אחד — אתם חייבים project ברמת org (או user). Project ברמת repo יראה רק issues של אותו repo.

דרך 2: מ-CLI

# ודאו שיש scope לprojects
gh auth refresh -s project

# צרו project חדש
gh project create --owner "@me" --title "Sprint Board"

# או ברמת ארגון
gh project create --owner "my-org" --title "Product Roadmap"

ה-CLI מחזיר את ה-URL של הפרויקט שנוצר — שמרו אותו. תצטרכו את מספר הפרויקט (הספרה האחרונה ב-URL) לפקודות הבאות.

הוספת items ללוח

Project ריק לא שווה כלום. הוסיפו items — ויש שלושה סוגים:

• Issues קיימים: מתוך הלוח, לחצו + → חפשו issue → הוסיפו. ה-issue נשאר ב-repo המקורי, אבל מופיע גם בלוח
• Pull Requests: אותו תהליך — PRs הם items לגיטימיים בלוח. מצוין לעקוב אחרי קוד שמחכה ל-review
• Draft issues: פריטים שקיימים רק בלוח — אין להם issue number, אין repo. מצוין לסיעור מוחות ולתכנון מוקדם. אפשר להמיר draft issue ל-issue אמיתי בקליק אחד אחרי שמחליטים שזה באמת משימה

# הוספת issue קיים ללוח (נדרש project number)
gh project item-add 1 --owner "@me" \
  --url https://github.com/user/repo/issues/42

# יצירת draft issue ישירות בלוח
gh project item-create 1 --owner "@me" \
  --title "לחקור אפשרויות caching" --body "draft for now"

# הוספת PR ללוח
gh project item-add 1 --owner "@me" \
  --url https://github.com/user/repo/pull/15

Project Templates

ארגונים יכולים ליצור project templates — תבניות עם תצוגות, שדות, draft issues ו-workflows מוכנים. במקום להגדיר הכל מאפס, בחרו template ותקבלו לוח מוכן. Templates נוצרים מ-Settings של project קיים → Make a template.

זה שימושי במיוחד כשמנהלים כמה צוותות — כל צוות מקבל template אחיד עם אותם שדות, אותם workflows, ואותם views. זה מונע מצב שכל צוות ממציא את הלוח שלו מחדש ואי אפשר להשוות ביניהם.

5.3 שדות מותאמים — המטא-דאטה שמשנה הכל

שדה Status מובנה כבר בכל Project — אבל Status בלבד לא מספיק. אם כל מה שאתם יודעים על משימה זה "Todo", "In Progress" או "Done", אתם מפספסים מידע קריטי. מה הדחיפות? כמה מאמץ? לאיזה ספרינט? מתי ה-deadline? שדות מותאמים נותנים את התשובות.

חשבו על שדות כמו עמודות ב-Excel — כל עמודה מוסיפה מימד של מידע. Issue בלי שדות מותאמים הוא כמו שורה עם כותרת בלבד. Issue עם שדות הוא שורה מלאה שמספרת את כל הסיפור: מי אחראי, כמה דחוף, כמה מאמץ, לאיזה ספרינט, ומתי ה-deadline.

סוגי שדות

ב-Projects v2 יש 5 סוגי שדות מותאמים, ועוד שדות מובנים שתמיד קיימים:

פירוט כל סוג שדה ומתי להשתמש בו:

• Text — טקסט חופשי. טוב להערות, קישורים חיצוניים, ותיאורים קצרים. דוגמה: "Notes" שבו כותבים הקשר נוסף שלא מתאים לגוף ה-issue
• Number — ערך מספרי. מצוין ל-effort points, story points, או ציון עדיפות מספרי. GitHub מציג סיכומים (sum) בתצוגת Table, מה שמאפשר לראות total effort per sprint
• Date — תאריך עם picker. משמש ל-due dates, start dates, target dates. ב-Roadmap view, שדות Date קובעים את מיקום ה-item על ציר הזמן
• Single Select — בחירה מרשימה מוגדרת מראש עם צבעים. הסוג הנפוץ ביותר — Priority, Team, Category, Risk Level. הצבעים עוזרים לזהות ערכים מהר
• Iteration — מחזור עבודה (ספרינט) עם תאריך התחלה ומשך. שונה מ-Date כי הוא מייצג טווח ולא נקודה — ויש תמיכה בהפסקות (breaks) בין iterations

הוספת שדה מותאם: מתוך תצוגת Table, לחצו על + בכותרת העמודות → New field → בחרו סוג → תנו שם. ב-Single Select, הגדירו אפשרויות עם צבעים. ב-Iteration, הגדירו start date ו-duration.

Issue Types ו-Sub-issues (חדש 2025)

שני פיצ'רים שהגיעו ל-GA באפריל 2025 ומשנים את הדרך שבה מארגנים עבודה:

• Issue Types — סיווג סטנדרטי ברמת ארגון: Bug, Task, Initiative. כל issue מקבל type, ואפשר לסנן ולקבץ לפי type בכל Project. זה שונה מ-labels כי types הם אחידים לכל הארגון — לא צריך ליצור label "bug" בכל repo בנפרד
• Sub-issues — מבנה parent-child: issue ראשי (למשל "Redesign homepage") עם sub-issues מתחתיו ("Update header", "New hero section", "Mobile responsive"). עד 50 sub-issues per parent ו-8 רמות קינון. אפשר להמיר checklist items ל-sub-issues בקליק אחד — שימושי מאוד כשיש issue עם checklist ארוך שכל item דורש עבודה משמעותית

ההבדל בין Issue Type ל-Label: Labels הם per-repo וכל אחד יכול ליצור מה שהוא רוצה — "bug", "Bug", "BUG". Issue Types הם per-org ומנוהלים מרכזית. כשמסננים Project שמכיל issues מ-10 repos שונים, Issue Types עובדים אחיד. Labels לא.

5.4 תצוגות — Board, Table, Roadmap

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

Board View (Kanban)

התצוגה הקלאסית: עמודות לפי Status (או כל שדה Single Select). גוררים items בין עמודות. כשגוררים item מ-"Todo" ל-"In Progress", שדה ה-Status מתעדכן אוטומטית. הכי טוב ל: ניהול יומי, stand-up meetings, סקירת סטטוס מהירה. Board נותן תמונת מצב ויזואלית תוך שנייה — רואים כמה items בכל עמודה ואיפה יש צבירה.

טיפ מתקדם: אפשר לשנות את העמודות מ-Status לכל שדה Single Select. למשל, Board grouped by Priority — עמודות Critical, High, Medium, Low. או Board grouped by Team — עמודה לכל צוות. זה Board אחר לגמרי עם אותם נתונים.

Table View

כמו spreadsheet — שורות ועמודות עם כל השדות גלויים. מיון בקליק על כותרת עמודה. ב-Table אפשר לראות את כל המטא-דאטה בבת אחת — Priority, Effort, Due Date, Team, Status — בשורה אחת. הכי טוב ל: מיון לפי priority, סינון מורכב, sprint planning (סידור items ב-sprint לפי effort ו-priority), ועבודה עם הרבה שדות.

טיפ מתקדם: ב-Table, GitHub מציג sum של שדות מספריים בתחתית. אם יש לכם Effort field מספרי, תראו את סך ה-effort של כל ה-items הגלויים. עם פילטר iteration:@current, תראו את total effort של הספרינט הנוכחי — מספר אחד שמספר אם יש עומס.

Roadmap View

ציר זמן שמציג items כפסים אופקיים. דורש שדה Date או Iteration. גוררים פסים לשנות תאריכים, מזיזים items בין sprints. הכי טוב ל: תכנון לטווח ארוך, sprint planning ויזואלי, הצגה למנהלים. Roadmap הוא התצוגה שמנהלים אוהבים — ציר זמן ברור עם milestones.

מה צריך ל-Roadmap: לפחות שדה Date אחד (Due Date), ורצוי שניים (Start Date + Due Date) כדי שה-items יהיו פסים עם אורך ולא רק נקודות על ציר. אם משתמשים ב-Iteration, ה-items ממוקמים אוטומטית בתוך ה-sprint שלהם.

יצירת View חדש: לחצו על + לצד שם ה-View הנוכחי → בחרו layout (Board, Table, או Roadmap) → תנו שם. אפשר ליצור כמה views שרוצים — כל אחד עם פילטרים, sorting, grouping ו-layout שונים. כל view נשמר בנפרד.

5.5 פילטרים, קיבוצים ו-Slicing — למצוא מה שחשוב

עם 8 items, הלוח ברור. עם 80? צריך כלים למצוא מה שחשוב. GitHub Projects תומך בשלושה כלים לארגון מידע — ואפשר לשלב את שלושתם בו-זמנית:

פילטרים (Filters)

לחצו על שורת הפילטר בראש ה-view והקלידו. התחביר דומה ל-GitHub Search אבל ייחודי ל-Projects:

# פילטרים בסיסיים
status:Todo                          # רק items בסטטוס Todo
assignee:username                    # רק של משתמש מסוים
assignee:@me                         # רק שלי
label:bug                            # רק עם label "bug"
is:open                              # רק issues פתוחים
is:closed                            # רק סגורים
milestone:"v2.0"                     # רק של milestone ספציפי

# פילטרים מורכבים (Advanced Search — GA 2025)
(label:bug OR label:critical) AND assignee:@me
priority:High AND status:"In Progress"
NOT status:Done                       # הכל חוץ מ-Done
(team:Frontend OR team:Backend) AND priority:Critical

# פילטרים לפי iteration
iteration:@current                   # רק בספרינט הנוכחי
iteration:@next                      # רק בספרינט הבא
iteration:@previous                  # מה נשאר מהספרינט הקודם

חדש ב-2025: Advanced Search מאפשר שימוש ב-AND, OR, NOT ו-סוגריים לפילטרים מקוננים. לפני כן, היו רק פילטרים פשוטים עם AND מרומז. עכשיו אפשר לכתוב שאילתות מורכבות כמו: "הראה לי כל מה שהוא Critical או High, ששייך לצוות Frontend, ושלא ב-Done".

קיבוצים (Grouping)

קיבוץ מחלק את ה-view לקבוצות לפי שדה. ב-Board, כל קבוצה הופכת לשורת עמודות נפרדת — כלומר שני Boards זה מתחת לזה. ב-Table, כל קבוצה מקבלת כותרת מפרידה עם סיכום (count ו-sum של שדות מספריים).

שימושים נפוצים:

• Group by Assignee — לראות מי עמוס. אם לאדם אחד יש 15 items ולכולם 3 — יש בעיה
• Group by Priority — מה דחוף מעל הכל. Critical בראש, Low בתחתית
• Group by Iteration — מה בספרינט הנוכחי, מה בהבא, מה ב-backlog
• Group by Team — כל צוות רואה את המשימות שלו בנפרד

Grouping + Sorting בו-זמנית: אפשר לקבץ לפי Priority ובתוך כל קבוצה לסדר לפי Due Date. זה נותן "תראה לי את כל ה-Critical items, מהדחוף ביותר למאוחר ביותר".

Slicing

Slicing מוסיף סרגל צד (sidebar) שמסנן את ה-view לפי ערך של שדה. למשל, slice by Team — ובצד שמאל מופיעה רשימת הצוותות. לחצו על צוות ותראו רק את ה-items שלו. לחצו על צוות אחר — התצוגה מתעדכנת מיד.

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

הפעלת Slicing: ב-view, לחצו על Slice by → בחרו שדה (Team, Priority, Iteration, או כל Single Select).

5.6 אוטומציות מובנות — הרובוט שמעדכן בשבילך

הבעיה הגדולה של כל לוח ניהול: אנשים לא מעדכנים סטטוס. issue סגור ב-GitHub, אבל בלוח הוא עדיין "In Progress". PR מורג, אבל ה-item עדיין "In Review". זה יוצר לוח שמשקר — ואם הלוח משקר, אף אחד לא סומך עליו, ואף אחד לא משתמש בו.

אוטומציות פותרות את זה על ידי סנכרון הלוח עם המציאות. כש-issue נסגר — הסטטוס מתעדכן. כש-PR מורג — ה-item עובר ל-Done. אף אחד לא צריך לזכור לעדכן ידנית.

GitHub Projects כולל 6 built-in workflows שאפשר להפעיל בקליק:

הפעלה: בפרויקט, לחצו על ... (שלוש נקודות) → Workflows → בחרו workflow → Edit → הפעילו. אפשר לשנות את הסטטוס שנקבע — למשל, "Item added" יעדכן ל-"Todo" או ל-"Backlog".

Workflow 3 (Item added) — למה להפעיל: בלי workflow 3, כל item חדש מגיע בלי Status ומופיע בעמודה "No Status" שנראית כמו ברדק. עם workflow 3, כל item חדש מקבל אוטומטית Status = Todo ונופל לעמודה הנכונה.

Workflow 6 (Auto-add) — הכי חזק: מאפשר להגדיר פילטר כמו label:feature — וכל issue חדש עם label זה יתווסף אוטומטית לפרויקט. זה אומר שאף אחד לא צריך לזכור להוסיף issues ידנית. אפשר גם לסנן לפי repo, assignee, או כל שילוב — למשל, "כל issue עם label bug ב-repo frontend יתווסף אוטומטית".

Workflow 5 (Auto-archive) — ניקיון אוטומטי: items שב-Done כבר שבועיים מסתירים את הנתונים החשובים. Auto-archive מעביר אותם לארכיון אוטומטית. הם לא נמחקים — אפשר לשחזר — אבל הם לא מבלבלים את הלוח. הגדירו את הקריטריון: "Status is Done AND last updated more than 14 days ago".

5.7 אוטומציה עם Actions — כשה-built-in לא מספיק

Built-in workflows מכסים את הבסיס — עדכון Status אוטומטי. אבל מה אם רוצים יותר? ברגע שצריך לעדכן שדה שאינו Status, לשלב שירות חיצוני, או להריץ לוגיקה מותאמת — צריך Actions workflow שמדבר עם ה-Projects API.

דוגמאות לדברים שרק Actions יכול לעשות:

• לעדכן שדה Priority לפי labels — issue עם label "critical" מקבל אוטומטית Priority = Critical
• לשים Date אוטומטית כש-issue נוצר — "Created At" field שנקבע בלי מגע אנושי
• לשלוח Slack notification כשיש 3+ items ב-Critical
• להעביר items בין projects כש-milestone מושלם

הדרך הפשוטה: actions/add-to-project

ה-action הרשמי של GitHub מוסיף issues ו-PRs לפרויקט. זה כל מה שהוא עושה — אבל הוא עושה את זה טוב:

name: Add to Project
on:
  issues:
    types: [opened]
  pull_request:
    types: [opened]

jobs:
  add-to-project:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/add-to-project@v1
        with:
          project-url: https://github.com/orgs/my-org/projects/1
          github-token: ${{ secrets.PROJECT_PAT }}
          # labeled: bug, feature   # אופציונלי: רק issues עם labels ספציפיים

מתי להשתמש ב-action הזה: כשרוצים שכל issue חדש (או רק issues עם labels מסוימים) יתווסף לפרויקט. זה חלופה ל-built-in workflow 6, עם יותר גמישות — אפשר לסנן לפי כל מאפיין של ה-event, לא רק labels.

הדרך המתקדמת: GraphQL mutations

כש-add-to-project לא מספיק ורוצים לעדכן שדות, עובדים ישירות עם ה-GraphQL API. זה דורש יותר קוד אבל נותן שליטה מלאה:

name: Update Project on PR Merge
on:
  pull_request:
    types: [closed]

jobs:
  update-project:
    if: github.event.pull_request.merged == true
    runs-on: ubuntu-latest
    steps:
      - name: Get Project Item
        env:
          GH_TOKEN: ${{ secrets.PROJECT_PAT }}
        run: |
          # שלב 1: מצא את ה-item בפרויקט
          ITEM_ID=$(gh api graphql -f query='
            query {
              node(id: "${{ github.event.pull_request.node_id }}") {
                ... on PullRequest {
                  projectItems(first: 1) {
                    nodes { id }
                  }
                }
              }
            }' --jq '.data.node.projectItems.nodes[0].id')

          echo "ITEM_ID=$ITEM_ID" >> $GITHUB_ENV

      - name: Update Status to Done
        if: env.ITEM_ID != ''
        env:
          GH_TOKEN: ${{ secrets.PROJECT_PAT }}
        run: |
          # שלב 2: עדכן את השדה Status ל-Done
          gh api graphql -f query='
            mutation {
              updateProjectV2ItemFieldValue(input: {
                projectId: "PROJECT_ID_HERE"
                itemId: "'"$ITEM_ID"'"
                fieldId: "STATUS_FIELD_ID_HERE"
                value: { singleSelectOptionId: "DONE_OPTION_ID_HERE" }
              }) {
                projectV2Item { id }
              }
            }'

איך למצוא את ה-IDs: ה-IDs (project, field, option) הם מחרוזות ייחודיות שצריך לשלוף פעם אחת ולשמור. הנה הפקודות:

# מצא Project ID (החליפו 1 במספר הפרויקט שלכם)
gh api graphql -f query='{ viewer { projectV2(number: 1) { id } } }'

# מצא Field IDs ו-Option IDs
gh api graphql -f query='{
  node(id: "PROJECT_ID") {
    ... on ProjectV2 {
      fields(first: 20) {
        nodes {
          ... on ProjectV2SingleSelectField {
            id name
            options { id name }
          }
          ... on ProjectV2Field { id name }
          ... on ProjectV2IterationField { id name }
        }
      }
    }
  }
}'

שמרו את ה-IDs: אחרי שמצאתם, שמרו אותם כ-repository secrets או כ-environment variables ב-workflow. אל תשימו אותם hardcoded בקוד — IDs יכולים להשתנות אם מוחקים ויוצרים שדה מחדש.

5.8 Insights — גרפים שמראים את האמת

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

לכו לטאב Insights בפרויקט (ליד Settings). תראו שני סוגי charts:

Current Charts

מציגים snapshot של המצב הנוכחי — מה קורה עכשיו:

• Status distribution — כמה items בכל Status (bar chart). עמודת "In Progress" ענקית? יש bottleneck
• Assignee distribution — מי הכי עמוס. אם למישהו יש 20 items וליתר 5 — צריך לאזן
• Priority breakdown — כמה Critical, כמה High, כמה Medium, כמה Low. אם 80% Critical — כלום לא באמת critical
• Iteration load — כמה items בכל sprint. Sprint 3 עם 30 items ו-Sprint 4 עם 5? לא מאוזן

Historical Charts

מציגים שינוי לאורך זמן — מה קרה בשבועות/חודשים האחרונים:

• Burn-up chart (ברירת מחדל) — שני קווים: "Total" (כמה items בסך הכל) ו-"Completed" (כמה הושלמו). אם הקווים מתקרבים — אתם מתקדמים. אם Total עולה מהר מ-Completed — נוספות יותר משימות ממה שמסיימים
• Custom historical — אפשר לבנות historical chart לפי כל שדה: burn-up של bugs בלבד, או progress לפי team

יצירת custom chart: Insights → New chart → בחרו layout (bar, line, stacked area) → הגדירו X-axis (Time ל-historical, field ל-current) → Group by (Status, Priority, Assignee) → Filter → Save.

שלושה charts ש-כל פרויקט צריך:

1. Burn-up by Status — ברירת המחדל. מראה אם מתקדמים
2. Current by Priority — bar chart שמראה כמה Critical יש עכשיו. אם המספר עולה — בעיה
3. Current by Assignee — bar chart שמראה עומס per person. אם מישהו בולט — צריך לאזן

מגבלה חשובה: Insights לא עוקב אחרי items שארכבתם או מחקתם. אם ארכבתם 50 items, הם נעלמים מהגרפים. ה-burn-up "יזכור" אותם (כי הוא historical), אבל ה-current charts לא יציגו אותם. לכן, אל תארכבו items בזמן sprint — רק אחרי sprint review. אחרת, ה-Insights לא ישקפו את המציאות.

5.9 Iterations ו-Roadmap — ספרינטים ותכנון לטווח ארוך

אם הצוות שלכם עובד בספרינטים (sprints), Iterations הם הפיצ'ר שמחבר את GitHub Projects לעולם ה-Agile. Iteration הוא לא סתם תאריך — הוא מחזור עבודה שלם עם התחלה, סוף, ותמיכה בהפסקות.

הגדרת Iterations

1. בפרויקט, לכו ל-Settings → Custom fields
2. לחצו New field → בחרו Iteration
3. תנו שם (למשל: "Sprint")
4. הגדירו Start date — תאריך ההתחלה של ה-iteration הראשון
5. הגדירו Duration — 1 שבוע, 2 שבועות, 3 שבועות, או 4 שבועות
6. אופציונלי: הוסיפו breaks — הפסקות בין iterations (חגים, חופשות צוות). GitHub ידלג על ההפסקות ויצור iterations רציפים

אחרי שהגדרתם, GitHub יוצר אוטומטית iterations עתידיים. כל iteration מקבל שם (Sprint 1, Sprint 2...) ותאריכים מדויקים. אפשר לשנות שמות ל-sprints ספציפיים — למשל "Sprint 4: Auth Refactor".

Iteration vs Date — ההבדל: Date הוא נקודה על ציר הזמן (30 בינואר). Iteration הוא טווח (Sprint 3: 20 ינואר - 2 פברואר). כש-item מוקצה ל-Iteration, הוא שייך לכל ה-sprint. כש-item מקבל Date, הוא ממוקם בנקודה ספציפית. אם עובדים בספרינטים — תמיד Iteration. אם יש deadlines קשיחים — Date.

שימוש ב-Iterations

• הקצאה: בכל item, בחרו את ה-Sprint שהוא שייך אליו. ב-Table, עמודת Sprint עם dropdown
• סינון: iteration:@current — רק items בספרינט הנוכחי. iteration:@next — בהבא. iteration:@previous — מה נשאר מהקודם
• קיבוץ: Group by Sprint — לראות כל ספרינט בנפרד, עם count ו-sum של effort
• Insights: צרו chart grouped by Sprint — לראות עומס per sprint. אם Sprint 3 עמוס פי 3 מ-Sprint 4 — צריך לאזן

Roadmap View עם Iterations

ב-Roadmap, כל item מופיע כפס אופקי על ציר הזמן. אם ל-item יש Date (start + due), הוא ממוקם לפי תאריכים ואורך הפס מייצג את משך הזמן. אם יש Iteration, הוא ממוקם בתוך ה-sprint שלו. אפשר לגרור פסים לשנות תאריכים, להזיז items בין sprints, ולראות קווים אנכיים (vertical markers) ל-milestones ולתאריך הנוכחי.

Vertical markers: הקו הוורוד של "Today" מראה איפה אתם עכשיו על ציר הזמן. אפשר להוסיף markers נוספים — למשל, תאריך release, תאריך demo, או deadline חיצוני. Markers עוזרים לראות מה צריך להיגמר לפני נקודת ציון.

Cross-sprint items: items שנמשכים יותר מ-sprint אחד (למשל "Redesign dashboard") מופיעים כפס שחוצה כמה sprints. זה נורמלי ל-items גדולים — אבל אם רוב ה-items חוצים sprints, כנראה שה-sprints קצרים מדי או שה-items לא מפורקים מספיק.

Sprint Planning Workflow

הנה workflow מעשי לניהול sprints עם GitHub Projects — שלושה שלבים, שלוש תצוגות:

1. לפני Sprint (Planning) — עברו לתצוגת Table, סננו iteration:@next. ודאו שיש מספיק items ושה-total effort סביר. הוסיפו items מה-backlog, סדרו priorities, וודאו שכל item מוקצה למישהו
2. בזמן Sprint (Execution) — עברו לתצוגת Board, סננו iteration:@current. זה ה-view לדיילי — גוררים items בין Todo, In Progress, ו-Done. בדקו מה blocked, מה ב-review, מה הושלם
3. אחרי Sprint (Review) — עברו ל-Insights, בדקו burn-up chart. כמה items הושלמו? כמה נשארו? עברו ל-Table עם iteration:@previous AND NOT status:Done — אלו ה-items שנשארו ושצריך להעביר לספרינט הבא או ל-backlog

5.10 gh CLI — ניהול Projects מהטרמינל

אם למדתם את פרק 2 (GitHub CLI), אתם יודעים שכל דבר שעושים ב-UI אפשר לעשות מהטרמינל — יותר מהר, ועם אפשרות לסקריפט. Projects לא יוצא דופן. כל הפקודות שנראה כאן דורשות project scope — שהוספנו כבר בסעיף 5.7.

Setup: הוספת scope

# ברירת מחדל, gh לא כולל project scope
gh auth status    # בדקו scopes נוכחיים

# הוסיפו project scope (פעם אחת)
gh auth refresh -s project

פקודות בסיסיות — ניהול Projects

# רשימת projects
gh project list                              # של המשתמש שלכם
gh project list --owner "my-org"             # של ארגון

# צפייה בפרויקט (מידע בסיסי + items)
gh project view 1                            # לפי מספר
gh project view 1 --owner "@me" --web        # פתיחה בדפדפן

# יצירת project חדש
gh project create --owner "@me" --title "New Sprint"

# העתקת project (כולל fields ו-views, בלי items)
gh project copy 1 --source-owner "my-org" \
  --target-owner "@me" --title "My Copy"

# מחיקת project
gh project delete 1 --owner "@me"

ניהול Items — הוספה, עריכה, ארכוב

# הוספת issue קיים
gh project item-add 1 --owner "@me" \
  --url https://github.com/user/repo/issues/42

# יצירת draft issue ישירות בלוח
gh project item-create 1 --owner "@me" \
  --title "Research caching options" \
  --body "Look into Redis vs Memcached"

# רשימת items (JSON output לעיבוד)
gh project item-list 1 --owner "@me" --format json

# רשימת items בפורמט טבלה (קריא)
gh project item-list 1 --owner "@me"

# ארכוב item (לא מוחק — מעביר לארכיון)
gh project item-archive 1 --owner "@me" --id ITEM_ID

ניהול Fields — יצירה ומחיקה

# רשימת fields (כולל IDs — חשוב לעריכת items)
gh project field-list 1 --owner "@me"

# יצירת field חדש
gh project field-create 1 --owner "@me" \
  --name "Team" --data-type "SINGLE_SELECT"

# מחיקת field
gh project field-delete --id FIELD_ID

עריכת Items — שינוי ערכי שדות

# עדכון שדה Single Select (כמו Priority)
gh project item-edit \
  --project-id PROJECT_ID \
  --id ITEM_ID \
  --field-id FIELD_ID \
  --single-select-option-id OPTION_ID

# עדכון שדה Date
gh project item-edit \
  --project-id PROJECT_ID \
  --id ITEM_ID \
  --field-id DATE_FIELD_ID \
  --date "2026-04-15"

# עדכון שדה Number
gh project item-edit \
  --project-id PROJECT_ID \
  --id ITEM_ID \
  --field-id NUMBER_FIELD_ID \
  --number 3

# עדכון שדה Text
gh project item-edit \
  --project-id PROJECT_ID \
  --id ITEM_ID \
  --field-id TEXT_FIELD_ID \
  --text "Updated note"

שימו לב: item-edit דורש IDs — לא שמות. השתמשו ב-field-list (לField IDs ו-Option IDs) וב-item-list --format json (ל-Item IDs) כדי למצוא את ה-IDs. זה מרגיש מסורבל בהתחלה, אבל ברגע ששמרתם את ה-IDs — העדכון הוא שורה אחת.

שילוב עם פקודות אחרות

הכוח האמיתי של CLI הוא שילוב עם פקודות gh אחרות:

# הוספת כל ה-issues הפתוחים מ-repo ספציפי לפרויקט
gh issue list --repo user/repo --state open --json url \
  --jq '.[].url' | while read url; do
    gh project item-add 1 --owner "@me" --url "$url"
  done

# מציאת items בלי assignee (שנפלו בין הכיסאות)
gh project item-list 1 --owner "@me" --format json \
  --jq '.[] | select(.assignees == null) | .title'

#!/bin/bash
# sprint-triage.sh — מוסיף issues פתוחים חסרים לפרויקט
# שימוש: ./sprint-triage.sh [project_number] [owner] [repo]

PROJECT_NUM=${1:-1}
OWNER=${2:-"@me"}
REPO=${3:-"user/repo"}

echo "=== Sprint Triage ==="
echo "Project: $PROJECT_NUM | Owner: $OWNER | Repo: $REPO"
echo ""

# מצא issues פתוחים ב-repo
OPEN_ISSUES=$(gh issue list --repo "$REPO" --state open \
  --json url --jq '.[].url')

# מצא items שכבר בפרויקט
EXISTING=$(gh project item-list "$PROJECT_NUM" --owner "$OWNER" \
  --format json --jq '.[].content.url' 2>/dev/null)

ADDED=0
for issue_url in $OPEN_ISSUES; do
  if ! echo "$EXISTING" | grep -q "$issue_url"; then
    echo "Adding: $issue_url"
    gh project item-add "$PROJECT_NUM" --owner "$OWNER" \
      --url "$issue_url"
    ADDED=$((ADDED + 1))
  fi
done

echo ""
echo "=== Triage Complete: $ADDED issues added ==="

5.11 Issues vs Projects vs Discussions — מתי מה

שלושה כלים, שלושה שימושים. הטעות הנפוצה: לנסות להשתמש בכלי אחד לכל דבר. "בואו נפתח issue לכל דבר" — ואז יש 500 issues, חלקם באגים, חלקם רעיונות, חלקם שאלות, ואי אפשר למצוא שום דבר. "בואו נשים הכל ב-Project" — ואז הלוח מפוצץ ב-items שחלקם לא באמת משימות.

הפתרון הוא לדעת מתי לפתוח מה:

5.12 סיכום ומבט קדימה

בפרק הבא: נלמד לפרסם packages — npm, Docker images — עם GitHub Packages. תגלו שהרגיסטרי הפרטי שלכם כבר קיים, חינמי, ומשולב ישירות ב-GitHub. ה-Project board שבניתם בפרק הזה ילווה אתכם כשתנהלו features ו-releases של ה-packages.