GitHub CLI — שליטה מלאה מהטרמינל

2.1 מעבר לבסיס — מה רוב המפתחים לא יודעים

שאלו מפתח ממוצע מה הוא יודע על GitHub CLI ותקבלו שתי פקודות: gh pr create ו-gh repo clone. אולי גם gh pr view אם הוא מתקדם. זה כמו להכיר רק Copy ו-Paste ב-Excel ולחשוב שמיצית את הפוטנציאל.

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

• Aliases — קיצורים מותאמים שהופכים תהליך של 5 פקודות לפקודה אחת. ברמה הפשוטה זה קיצור שם, ברמה המתקדמת זה shell script שלם
• gh api — גישה ישירה לכל endpoint של GitHub API, בלי curl ובלי token ידני. כולל GraphQL. כולל pagination אוטומטי. כולל JQ מובנה
• JQ filtering — סינון JSON בשורה אחת, מובנה ישירות ב-gh. לא צריך להתקין jq בנפרד (אם כי אפשר)
• Extensions — אקוסיסטם שלם של תוספים מהקהילה, כולל gh-dash (dashboard אינטראקטיבי), gh-poi (ניקוי branches), ועוד מאות. ואפשר לבנות extensions משלכם
• Scripting — אוטומציות שלמות שמנהלות ריפוזיטורים, issues, PRs ו-releases. הדפוס הבסיסי: שליפה, עיבוד, פעולה — והכל בכמה שורות shell

הנתון הכי מפתיע: לפי הסקר השנתי של GitHub, רק כ-15% מהמפתחים שמשתמשים ב-gh CLI ממצים יותר מ-20% מהיכולות שלו. ב-85% המפתחים, השימוש מוגבל לפקודות הבסיסיות. הפער הזה הוא ההזדמנות שלכם.

בפרק הזה נחקור את כל הרבדים האלה, צעד אחרי צעד. בסוף הפרק, הטרמינל יהיה הממשק הראשי שלכם ל-GitHub — ותתפלאו איך עבדתם בלי זה.

# בדיקת גרסה — צריך 2.60 ומעלה
gh --version

# בדיקת אימות — צריך להיות logged in
gh auth status

# רשימת aliases — כנראה ריק. בקרוב נמלא
gh alias list

מה נכסה בפרק הזה

הפרק בנוי בצורה הדרגתית — מתחילים מדברים פשוטים ומתקדמים:

1. Aliases (סעיף 2.2) — נתחיל מהקל ביותר. קיצורים מותאמים שאפשר ליצור ב-10 שניות ולהשתמש מיד. שלוש רמות — מפשוט למורכב.
2. gh api (סעיף 2.3) — נפתח את הדלת לכל ה-API של GitHub. REST ו-GraphQL, עם דוגמאות מעשיות שתוכלו להריץ מיד.
3. JQ (סעיף 2.4) — נלמד לסנן JSON כמו מקצוענים. ספר המתכונים שנבנה כאן ילווה אתכם הרבה אחרי הפרק.
4. PR, Issue, Repo (סעיף 2.5) — מחזורי חיים מלאים מהטרמינל. כל מה שעושים ב-GitHub.com, ב-CLI.
5. gh run (סעיף 2.6) — ניטור CI/CD בזמן אמת. חיבור ישיר למה שלמדנו בפרק 1.
6. Scripting (סעיף 2.7) — שם הכל מתחבר. סקריפטים שמשלבים את כל מה שלמדנו לאוטומציות אמיתיות.
7. Extensions (סעיף 2.8) — תוספים מהקהילה ויצירת extensions משלכם.
8. אוטומציות מורכבות (סעיף 2.9) — שני תרחישים מהעולם האמיתי שמשלבים הכל.

מוכנים? בואו נתחיל מהדבר שישנה לכם את החיים מיד — aliases.

2.2 Aliases — קיצורים מותאמים אישית

alias ב-gh הוא בדיוק מה שנשמע: שם קצר שמחליף פקודה ארוכה. אבל ב-gh יש שלוש רמות של aliases, מפשוט למורכב, וההבדל ביניהן הוא קריטי.

רמה 1 — alias פשוט

ברמה הבסיסית ביותר, alias הוא פשוט שם חדש לפקודה קיימת. זה חוסך הקלדה ומפשט פקודות ארוכות:

# הפקודה המקורית — 42 תווים:
gh pr list --state open --assignee @me

# אחרי alias — 10 תווים:
gh alias set my-prs 'pr list --state open --assignee @me'
gh my-prs

# עוד דוגמאות:
gh alias set my-issues 'issue list --assignee @me --state open'
gh alias set repos 'repo list --limit 20 --sort updated'

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

רמה 2 — alias עם פרמטרים

פרמטרים הופכים את ה-alias לגמיש — אתם מעבירים ארגומנטים שמשתנים בכל הרצה:

# $1 הוא הארגומנט הראשון שתעבירו
gh alias set pr-for 'pr list --search "author:$1"'

# שימוש:
gh pr-for octocat       # PRs של octocat
gh pr-for nadav         # PRs של nadav

# alias עם שני פרמטרים:
gh alias set find-issue 'issue list --label "$1" --state "$2"'

# שימוש:
gh find-issue bug open           # issues פתוחים עם label "bug"
gh find-issue enhancement closed # issues סגורים עם label "enhancement"

הפרמטרים $1, $2, $3 מחליפים את הארגומנטים שתעבירו. זה מספיק לרוב המקרים.

רמה 3 — shell alias עם pipes ולוגיקה

הרמה הכי חזקה. --shell אומר ל-gh שהפקודה היא shell script, לא פקודת gh רגילה. זה פותח דלת לכל מה ש-shell יכול לעשות — pipes, לולאות, תנאים, ופקודות חיצוניות:

# alias שמריץ shell command מלא
gh alias set --shell stale-issues \
  'gh issue list --json number,title,updatedAt \
    --jq ".[] | select(now - (.updatedAt | fromdateiso8601) > 30*24*3600) | \"#\(.number) \(.title)\""'

# alias שמשלב כמה פקודות gh
gh alias set --shell pr-stats \
  'echo "Open PRs: $(gh pr list --json number --jq \"length\")"
   echo "My PRs: $(gh pr list --json number --assignee @me --jq \"length\")"
   echo "Draft PRs: $(gh pr list --json isDraft --jq \"[.[] | select(.isDraft)] | length\")"'

# alias עם תנאי
gh alias set --shell safe-merge \
  'PR=$1
   STATUS=$(gh pr checks "$PR" --json state --jq ".[].state" | sort -u)
   if echo "$STATUS" | grep -q "FAILURE"; then
     echo "Cannot merge — CI failed"
   else
     gh pr merge "$PR" --squash --delete-branch
   fi'

shell aliases הם חזקים, אבל דורשים זהירות. כל טעות בתחביר shell תגרום ל-alias לא לעבוד, וה-debugging לא תמיד פשוט. כלל אצבע:

• רמה 1 — כשאתם רוצים רק לקצר פקודה קיימת. פשוט ומהיר.
• רמה 2 — כשהפקודה צריכה להיות גמישה (פרמטרים משתנים). הכי נפוץ ביום-יום.
• רמה 3 — כשצריכים לוגיקה (תנאים, לולאות, שילוב פקודות). חזק אבל מורכב. אם ה-alias ארוך מ-3 שורות, שקלו להפוך אותו לסקריפט נפרד.

ניהול aliases

ה-aliases שלכם נשמרים בקובץ קונפיגורציה של gh. אפשר לנהל אותם כך:

# רשימת כל ה-aliases שהגדרתם
gh alias list

# מחיקת alias
gh alias delete my-prs

# ייבוא aliases מקובץ YAML (שיתוף עם צוות!)
gh alias import aliases.yml

# צפייה בהגדרת alias ספציפי
gh alias list | grep my-prs

טיפ למתקדמים — גיבוי ושיתוף aliases: כל ה-aliases נשמרים בקובץ ~/.config/gh/config.yml (או %APPDATA%\GitHub CLI\config.yml ב-Windows). אפשר לייצא אותם עם gh alias list, לשמור בקובץ YAML ב-dotfiles repo, ולייבא במכונה חדשה עם gh alias import aliases.yml. כך תוכלו:

• לשחזר את כל ה-aliases שלכם בכל מכונה חדשה עם פקודה אחת
• לשתף aliases עם חברי צוות — כולם עובדים עם אותם קיצורים
• לגרסן את ה-aliases שלכם ב-Git — ככה יש לכם היסטוריה של שינויים

דוגמה לקובץ aliases.yml:

# aliases.yml — Team aliases
my-prs: pr list --state open --assignee @me
my-issues: issue list --assignee @me --state open
repos: repo list --limit 20 --sort updated

חמשת ה-aliases שכל מפתח צריך

אלה ה-aliases שנשמרים אצלי ואני משתמש בהם כל יום:

# 1. PRs שמחכים לי
gh alias set my-prs 'pr list --state open --assignee @me'

# 2. יצירת PR מהירה
gh alias set --shell quick-pr \
  'gh pr create --title "$1" --body "Auto-created via CLI" --assignee @me'

# 3. צפייה ב-CI של ה-PR הנוכחי
gh alias set --shell ci \
  'gh pr checks $(gh pr view --json number --jq .number)'

# 4. ניקוי branches ממוזגים
gh alias set --shell cleanup \
  'git branch --merged main | grep -v main | xargs -r git branch -d && echo "Cleaned!"'

# 5. דוח יומי
gh alias set --shell daily \
  'echo "=== My Open PRs ==="
   gh pr list --assignee @me --json number,title --jq ".[] | \"#\(.number) \(.title)\""
   echo ""
   echo "=== My Open Issues ==="
   gh issue list --assignee @me --json number,title --jq ".[] | \"#\(.number) \(.title)\""'

# alias 1: PRs שלי
gh alias set my-prs 'pr list --state open --assignee @me'

# alias 2: issues שלי
gh alias set my-issues 'issue list --assignee @me --state open'

# alias 3: יצירת PR מהירה
gh alias set --shell quick-pr \
  'gh pr create --title "$1" --body "Auto-created via CLI" --assignee @me'

# בדקו שהם נוצרו:
gh alias list

gh alias set --shell ci-status \
  'echo "Last 5 workflow runs:"
   gh run list --limit 5 --json status,name,conclusion \
     --jq ".[] | \"\(.name): \(.status) (\(.conclusion // \"running\"))\""'

# נסו:
gh ci-status

2.3 gh api — כל ה-API של GitHub בפקודה אחת

gh api הוא הכלי החבוי הכי חזק ב-gh. בזמן שרוב המפתחים משתמשים ב-gh בשביל פקודות מוכנות כמו gh pr list, מי שמכיר gh api יכול לגשת לכל דבר שה-GitHub API מציע — כולל endpoints שאין להם פקודת gh ייעודית.

למה gh api ולא curl?

בואו נשווה שליפת מידע על ריפוזיטורי ב-curl מול gh api:

# curl — ארוך, מסורבל, חושף token:
curl -H "Authorization: Bearer ghp_xxxxxxxxxxxx" \
     -H "Accept: application/vnd.github+json" \
     https://api.github.com/repos/octocat/Hello-World

# gh api — קצר, מאובטח, אוטומטי:
gh api repos/octocat/Hello-World

ההבדל דרמטי, וזה רק ההתחלה. הנה היתרונות המלאים:

• אימות אוטומטי — gh api משתמש ב-token שכבר הגדרתם ב-gh auth. אף פעם לא צריכים לחשוף PAT בפקודה
• URL קצר — לא צריך https://api.github.com/, רק את הנתיב: repos/owner/repo
• Pagination אוטומטי — הוסיפו --paginate והוא יביא את כל הדפים בשבילכם, בלי לנהל Link headers
• JQ מובנה — --jq מסנן את ה-JSON ישירות, בלי pipe חיצוני
• HTTP methods מובנים — -X POST, -f field=value — הכל עובד חלק
• Template variables — {owner}/{repo} מוחלפים אוטומטית לפי ה-repo הנוכחי

REST API — דוגמאות בסיסיות

# קבלת מידע על ריפוזיטורי
gh api repos/{owner}/{repo}

# רשימת collaborators
gh api repos/{owner}/{repo}/collaborators

# יצירת issue
gh api repos/{owner}/{repo}/issues -f title="Bug report" -f body="Details here"

# עדכון issue (הוספת label)
gh api repos/{owner}/{repo}/issues/42/labels -f "labels[]=bug" -f "labels[]=priority"

# מחיקת branch
gh api repos/{owner}/{repo}/git/refs/heads/old-branch -X DELETE

# רשימת כל ה-releases
gh api repos/{owner}/{repo}/releases --paginate --jq '.[].tag_name'

POST, PATCH, DELETE — כתיבה ל-API

ברירת המחדל של gh api היא GET. לפעולות כתיבה, משתמשים ב-flags:

# POST — יצירה (ברירת מחדל כשיש -f)
gh api repos/{owner}/{repo}/issues \
  -f title="New issue" \
  -f body="Created via gh api" \
  -f "labels[]=enhancement"

# PATCH — עדכון
gh api repos/{owner}/{repo}/issues/42 \
  -X PATCH \
  -f state="closed" \
  -f state_reason="completed"

# PUT — הוספת collaborator
gh api repos/{owner}/{repo}/collaborators/username \
  -X PUT \
  -f permission="push"

# DELETE — מחיקה
gh api repos/{owner}/{repo}/issues/42/labels/bug -X DELETE

GraphQL עם gh api

GitHub מציע שני APIs: REST ו-GraphQL. gh api graphql מאפשר לשלוח שאילתות GraphQL שמחזירות בדיוק את מה שצריכים — בלי שדות מיותרים:

# שאילתת GraphQL בסיסית — 5 ריפוזיטורים אחרונים
gh api graphql -f query='
  query {
    viewer {
      login
      repositories(first: 5, orderBy: {field: UPDATED_AT, direction: DESC}) {
        nodes { name stargazerCount }
      }
    }
  }'

# שאילתה עם משתנים — חיפוש PRs של משתמש
gh api graphql -f query='
  query($owner: String!, $repo: String!) {
    repository(owner: $owner, name: $repo) {
      pullRequests(first: 10, states: OPEN) {
        nodes {
          number
          title
          author { login }
          createdAt
        }
      }
    }
  }' -f owner="{owner}" -f repo="{repo}"

מתי GraphQL ומתי REST? זה תלוי בצורך שלכם:

• GraphQL עדיף כשצריכים נתונים מכמה מקורות בקריאה אחת — למשל, PRs עם reviews שלהם ו-checks status, הכל בשאילתה אחת. ב-REST זה דורש 3 קריאות נפרדות
• GraphQL עדיף כשצריכים רק שדות ספציפיים — REST מחזיר את כל השדות, GraphQL מחזיר בדיוק מה שביקשתם. פחות data transfer = מהיר יותר
• REST פשוט יותר לפעולות כתיבה — יצירת issue, עדכון PR, הוספת label. התחביר של mutations ב-GraphQL מסורבל יותר
• REST קל יותר ללמוד — endpoints ושיטות HTTP פשוטות. GraphQL דורש ללמוד שפת שאילתות

כלל אצבע: התחילו עם REST. עברו ל-GraphQL רק כשנתקלתם במגבלה — יותר מדי קריאות, שדות חסרים, או ביצועים איטיים.

# 1. פרטי הריפוזיטורי שלכם (החליפו {owner}/{repo})
gh api repos/{owner}/{repo} --jq '{name: .name, stars: .stargazers_count, language: .language}'

# 2. רשימת branches
gh api repos/{owner}/{repo}/branches --jq '.[].name'

# 3. בדיקת rate limit — כמה קריאות נשארו
gh api rate_limit --jq '.rate | "Used: \(.used)/\(.limit), Reset: \(.reset | strftime("%H:%M:%S"))"'

2.4 JQ — סינון ופרסור JSON כמו קסם

כמעט כל פלט של gh הוא JSON. בלי סינון, תקבלו מסה של נתונים שקשה לקרוא. JQ היא השפה שמסננת, ממפה ומעצבת JSON — וב-gh היא מובנית ישירות דרך --jq.

חשבו על JQ כ-SQL של JSON. כמו ש-SQL מאפשר לשלוף, לסנן ולמיין נתונים ממסד נתונים, JQ עושה את אותו הדבר עם JSON. ברגע שתלמדו 5-6 דפוסים בסיסיים, תוכלו לענות על כמעט כל שאלה שיש לכם על הנתונים שחוזרים מ-GitHub.

שתי דרכים לעבוד עם JQ ב-gh

דרך 1: --jq (מובנה — הכי נפוצה ומומלצת):

# שמות כל ה-PRs הפתוחים
gh pr list --json title --jq '.[].title'

# PRs שנוצרו על ידי משתמש ספציפי
gh pr list --json title,author --jq '.[] | select(.author.login == "octocat") | .title'

# פורמט מותאם — מספר + כותרת
gh pr list --json number,title --jq '.[] | "#\(.number) \(.title)"'

דרך 2: --json + pipe ל-jq חיצוני:

# כשצריכים JQ מתקדם יותר (sort_by, group_by, וכו')
gh pr list --json title,createdAt | jq 'sort_by(.createdAt) | reverse | .[0:5]'

# קיבוץ issues לפי label
gh issue list --json number,labels | jq 'group_by(.labels[0].name) | .[] | {label: .[0].labels[0].name, count: length}'

מתי --jq ומתי pipe? בשביל סינון בסיסי, --jq מספיק ועדיף (פחות תלויות). כש-pipe ל-jq חיצוני, יש גישה לפונקציות מתקדמות יותר כמו group_by ו-env.

ספר המתכונים — דפוסי JQ חיוניים

אלה הדפוסים שתשתמשו בהם שוב ושוב:

# 1. בחירת שדה אחד מכל אלמנט
--jq '.[].name'

# 2. בחירת כמה שדות
--jq '.[] | {name: .name, stars: .stargazers_count}'

# 3. סינון עם select
--jq '.[] | select(.state == "open")'
--jq '.[] | select(.labels | length > 0)'
--jq '.[] | select(.title | test("fix"; "i"))'     # regex case-insensitive

# 4. פורמט מותאם (string interpolation)
--jq '.[] | "#\(.number): \(.title) [\(.author.login)]"'

# 5. ספירה
--jq 'length'                                        # כמה אלמנטים
--jq '[.[] | select(.state == "open")] | length'     # כמה פתוחים

# 6. מיון
--jq 'sort_by(.stargazerCount) | reverse'            # מיון יורד
--jq 'sort_by(.createdAt)'                           # מיון לפי תאריך

# 7. חיתוך — רק N ראשונים
--jq '.[0:5]'                                        # 5 ראשונים
--jq 'sort_by(.updatedAt) | reverse | .[0:3]'        # 3 אחרונים

# 8. שרשור פעולות
--jq '[.[] | select(.state == "open")] | sort_by(.createdAt) | .[0] | "#\(.number) \(.title)"'

# שלב 1: כל ה-PRs הפתוחים — רק מספר ושם
gh pr list --json number,title --jq '.[] | "#\(.number) \(.title)"'

# שלב 2: כמה PRs פתוחים יש?
gh pr list --json number --jq 'length'

# שלב 3: ה-PR הכי ישן (לפי תאריך יצירה)
gh pr list --json number,title,createdAt --jq 'sort_by(.createdAt) | .[0] | "#\(.number) \(.title) (created: \(.createdAt[:10]))"'

gh api user/repos --paginate --jq \
  'sort_by(.stargazers_count) | reverse | .[:5] | .[] | "\(.full_name): \(.stargazers_count) stars"'

2.5 gh pr, gh issue, gh repo — השליטה המלאה

שלוש קבוצות הפקודות המרכזיות של gh CLI הן pr, issue ו-repo. כל אחת מנהלת מחזור חיים שלם — מיצירה ועד סגירה. אלה הפקודות שתשתמשו בהן הכי הרבה ביום-יום, הרבה יותר מ-gh api או scripting. נעבור על כל קבוצה בפירוט, עם כל הפקודות החשובות, flags שימושיים, ודוגמאות מעשיות שתוכלו להריץ מיד.

gh pr — מחזור חיים מלא של Pull Request

זו קבוצת הפקודות שהכי משתמשים בה ביום-יום. כל שלב במחזור החיים של PR — מיצירה, דרך review, ועד merge — אפשר לעשות מהטרמינל. זה לא רק יותר מהיר — זה גם מאפשר אוטומציה. מה שלוקח 2 דקות בדפדפן (פתיחת tab, ניווט לריפו, לחיצה על New PR, מילוי פרטים, לחיצה על Create) לוקח 5 שניות ב-CLI.

מחזור חיים מלא של PR:

# שלב 1: יצירת PR
gh pr create --title "feat: add login page" --body "Description of changes"
gh pr create --fill                    # מלא אוטומטית מ-commits
gh pr create --draft                   # יצירת draft PR
gh pr create --reviewer user1,user2    # עם reviewers מיידית
gh pr create --label "feature" --milestone "v2.0"  # עם label ו-milestone

# שלב 2: סקירה וניהול
gh pr list --state open                # רשימת PRs פתוחים
gh pr view 42                          # צפייה ב-PR ספציפי
gh pr view 42 --web                    # פתיחה בדפדפן
gh pr checkout 42                      # checkout ל-branch של ה-PR
gh pr diff 42                          # צפייה בשינויים
gh pr checks 42                        # סטטוס CI

# שלב 3: Code review
gh pr review 42 --approve              # אישור
gh pr review 42 --request-changes --body "Please fix X"  # בקשת שינויים
gh pr review 42 --comment --body "Looks good overall"     # הערה

# שלב 4: מיזוג
gh pr merge 42 --squash --delete-branch   # squash merge + מחיקת branch
gh pr merge 42 --rebase                    # rebase merge
gh pr merge 42 --merge                     # merge commit

# פעולות נוספות
gh pr ready 42                          # הפיכת draft ל-ready
gh pr edit 42 --add-label "priority"    # הוספת label
gh pr edit 42 --add-reviewer octocat    # הוספת reviewer
gh pr close 42                          # סגירה בלי merge

שימו לב לעוצמה של gh pr create --fill — הוא לוקח את ה-commit messages ומשתמש בהם ככותרת ותיאור של ה-PR אוטומטית. אם ה-commits שלכם כתובים טוב, זה חוסך את הצורך לכתוב תיאור מחדש.

טיפ נוסף: gh pr checkout 42 עושה את מה ש-git לבד לא יכול — הוא יודע לעשות checkout ל-PR מ-fork אחר, לא רק מ-branches מקומיים. זה שימושי במיוחד ל-maintainers שרוצים לבדוק PR מ-contributor חיצוני.

gh issue — ניהול issues מקצה לקצה

# יצירה
gh issue create --title "Bug: login fails" --label bug
gh issue create --title "Feature: dark mode" --label enhancement --assignee @me
gh issue create --template bug_report    # שימוש ב-issue template

# סינון וחיפוש
gh issue list --label bug --assignee @me     # סינון לפי label ו-assignee
gh issue list --state closed --limit 10      # 10 issues סגורים אחרונים
gh issue list --search "login in:title"      # חיפוש טקסט חופשי
gh issue list --milestone "v2.0"             # issues לפי milestone

# ניהול
gh issue view 15                             # צפייה
gh issue close 15 --reason completed         # סגירה עם סיבה
gh issue reopen 15                           # פתיחה מחדש
gh issue pin 15                              # הצמדה (pinning)
gh issue unpin 15                            # הסרת הצמדה
gh issue transfer 15 other-repo              # העברה לריפו אחר
gh issue edit 15 --add-label "in-progress"   # הוספת label
gh issue edit 15 --add-assignee user1        # הוספת assignee

# הערות
gh issue comment 15 --body "Working on this"  # הוספת הערה
gh issue develop 15 --base main               # יצירת branch עבור issue

שימו לב לפקודה gh issue develop 15 --base main — היא יוצרת branch חדש מקושר ל-issue. כשתפתחו PR מה-branch הזה, GitHub יקשר אותו אוטומטית ל-issue. כשה-PR ימוזג, ה-issue ייסגר אוטומטית. זה pattern חזק שחוסך עבודה ידנית.

עוד פקודה שרבים לא מכירים: gh issue pin מצמידה issue לראש הרשימה ב-GitHub.com. שימושי ל-issues חשובים שאתם רוצים שכולם יראו — כמו roadmap או contributing guidelines.

gh repo — ניהול ריפוזיטורים

# יצירה
gh repo create my-project --public --clone             # יצירה + clone
gh repo create my-project --private --add-readme       # עם README
gh repo create org/project --team developers           # בארגון, עם צוות

# Clone ו-Fork
gh repo clone owner/repo                                # clone
gh repo fork owner/repo --clone                         # fork + clone מקומי
gh repo fork owner/repo --clone --remote                # fork + clone + remote

# מידע וצפייה
gh repo view                                            # מידע על הריפו הנוכחי
gh repo view owner/repo                                 # מידע על ריפו אחר
gh repo view --web                                      # פתיחה בדפדפן

# ניהול
gh repo rename new-name                                 # שינוי שם
gh repo edit --default-branch main                      # שינוי branch ברירת מחדל
gh repo edit --enable-issues=false                      # כיבוי issues
gh repo archive                                         # ארכוב (הפיכה ל-readonly)
gh repo delete --confirm                                # מחיקה (!)

# רשימות
gh repo list                                            # הריפוזיטורים שלי
gh repo list --source --no-archived --limit 30          # רק מקור, לא ארכיון
gh repo list org-name --limit 50                        # ריפוזיטורים של ארגון

# 1. צרו branch חדש
git checkout -b test-cli-workflow

# 2. צרו קובץ ו-commit
echo "# CLI Workflow Test" > cli-test.md
git add cli-test.md
git commit -m "test: CLI workflow demo"

# 3. דחפו ל-remote
git push -u origin test-cli-workflow

# 4. צרו PR
gh pr create --title "test: CLI workflow demo" --body "Created entirely from the terminal"

# 5. בדקו סטטוס CI (אם יש workflow)
gh pr checks

# 6. צפו ב-PR בדפדפן לוידוא
gh pr view --web

# 7. סגרו את ה-PR (זה רק תרגול)
gh pr close --comment "Test completed"

2.6 gh run — ניטור Actions מהטרמינל

בפרק 1 בנינו workflows עם GitHub Actions — CI/CD pipelines שבודקים קוד, מריצים tests, ופורסים אוטומטית. אבל עד עכשיו, כדי לראות אם ה-workflow עבר, היינו צריכים לפתוח את הדפדפן ולנווט לטאב Actions. עכשיו נלמד לנטר את כל זה מהטרמינל — בזמן אמת, בלי לצאת מהקונטקסט של העבודה. אם לא עשיתם את פרק 1, לא נורא — תוכלו לחזור לסעיף הזה אחרי שתגדירו workflow ראשון.

הפקודות הבסיסיות

# רשימת הרצות אחרונות
gh run list                                   # כל ההרצות
gh run list --workflow ci.yml                  # רק workflow ספציפי
gh run list --limit 5                          # 5 אחרונות
gh run list --status failure                   # רק כשלונות
gh run list --branch main                      # רק ב-main

# צפייה בהרצה ספציפית
gh run view 12345                              # פרטי הרצה
gh run view 12345 --log                        # לוגים מלאים
gh run view 12345 --log-failed                 # לוגים רק של מה שנכשל
gh run view --web                              # פתיחה בדפדפן

# צפייה בזמן אמת — הפקודה הכי שימושית
gh run watch                                   # צפייה ב-run האחרון
gh run watch 12345                             # צפייה ב-run ספציפי

# הרצה מחדש
gh run rerun 12345                             # הרצה מחדש מלאה
gh run rerun 12345 --failed                    # רק jobs שנכשלו (!)
gh run rerun 12345 --debug                     # עם debug logging

# Artifacts
gh run download 12345                          # הורדת כל ה-artifacts
gh run download 12345 -n my-artifact           # artifact ספציפי

הזרימה האידיאלית — push, watch, fix, rerun

ככה נראה workflow טיפוסי של מפתח שמשתמש ב-gh run:

# 1. דחפתם קוד
git push origin main

# 2. מצאו את ה-run שהתחיל
gh run list --limit 1

# 3. צפו בו בזמן אמת
gh run watch

# 4. אם נכשל — ראו מה נכשל
gh run view --log-failed

# 5. תקנו את הקוד, דחפו שוב
git push origin main

# 6. או — הריצו מחדש רק את מה שנכשל
gh run rerun --failed

הקסם הוא ב-gh run watch — זה פותח תצוגה חיה בטרמינל שמתעדכנת כל כמה שניות, עם סטטוס של כל job. כמו לצפות ב-progress bar, אבל ב-CI/CD. כשכל ה-jobs עוברים, תראו סטטוס ירוק ותוכלו להמשיך לעבוד. אם משהו נכשל, gh run view --log-failed מראה לכם בדיוק מה קרה — בלי לנווט דרך ממשק הוובוי, ללחוץ על job, ואז על step, ואז לגלול. הכל מגיע ישירות לטרמינל.

עוד יתרון משמעותי: gh run rerun --failed מריץ מחדש רק את ה-jobs שנכשלו, לא את כל ה-workflow. אם יש לכם matrix build עם 10 jobs ו-2 נכשלו, זה מריץ רק את ה-2 — חוסך זמן ו-Actions minutes.

דפוסים מתקדמים — שילוב עם scripting

# alias שדוחף ומיד צופה
gh alias set --shell push-watch \
  'git push origin HEAD && sleep 2 && gh run watch'

# בדיקה אם ה-CI האחרון עבר
gh alias set --shell ci-ok \
  'STATUS=$(gh run list --limit 1 --json conclusion --jq ".[0].conclusion")
   if [ "$STATUS" = "success" ]; then
     echo "CI passed"
   else
     echo "CI failed: $STATUS"
     exit 1
   fi'

# דחפו שינוי (אפילו קטן)
echo "# Updated $(date)" >> README.md
git add README.md && git commit -m "docs: trigger CI" && git push

# מיד אחרי — צפו ב-run
gh run watch

2.7 Scripting Patterns — אוטומציות עם gh

הכוח האמיתי של gh CLI מתגלה כשמשלבים אותו עם shell scripting. עד עכשיו ראינו פקודות בודדות — alias שמריץ פקודה אחת, שאילתת API שמחזירה נתונים, סינון JQ שמעצב פלט. עכשיו נחבר את הכל לסקריפטים שלמים שמבצעים תהליכים מורכבים אוטומטית.

הדפוס הבסיסי הוא תמיד אותו דבר: שליפה, עיבוד, פעולה. שולפים נתונים מ-GitHub (עם gh list או gh api), מעבדים אותם עם JQ (סינון, מיון, בחירת שדות), ומבצעים פעולה על כל אלמנט (עם while read ו-gh edit / gh api). נראה חמישה דפוסים שמכסים כמעט כל תרחיש.

דפוס 1 — לולאה פשוטה על issues

#!/bin/bash
set -euo pipefail

# הוספת label "needs-triage" לכל issue פתוח בלי label
gh issue list --json number,labels --jq \
  '.[] | select(.labels | length == 0) | .number' | \
  while read -r num; do
    gh issue edit "$num" --add-label "needs-triage"
    echo "Labeled issue #$num"
  done

מה קורה פה? בואו נפרק את זה שורה אחרי שורה:

1. gh issue list --json number,labels — שולף את כל ה-issues הפתוחים עם מספר ו-labels בפורמט JSON
2. --jq '.[] | select(.labels | length == 0) | .number' — מסנן רק issues בלי labels, ומוציא רק את המספר
3. while read -r num — לולאה שרצה על כל מספר שחוזר מהצינור (pipe)
4. gh issue edit "$num" --add-label "needs-triage" — מוסיף label ל-issue הספציפי

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

דפוס 2 — batch operations על PRs

#!/bin/bash
set -euo pipefail

# סגירת כל PRs ישנים (יותר מ-90 יום)
CUTOFF=$(date -d "90 days ago" +%Y-%m-%dT%H:%M:%SZ 2>/dev/null || date -v-90d +%Y-%m-%dT%H:%M:%SZ)

gh pr list --json number,createdAt --jq \
  ".[] | select(.createdAt < \"$CUTOFF\") | .number" | \
  while read -r num; do
    gh pr close "$num" --comment "Auto-closed: stale PR (90+ days with no activity)"
    echo "Closed PR #$num"
    sleep 0.5   # מניעת rate limit
  done

דפוס 3 — pipeline מלא (שליפה, עיבוד, הצגה)

#!/bin/bash
set -euo pipefail

# דוח contributors מדורג
echo "=== Top 10 Contributors ==="
gh api repos/{owner}/{repo}/contributors --paginate \
  --jq '.[] | "\(.login): \(.contributions) commits"' | \
  sort -t: -k2 -rn | head -10

echo ""
echo "=== Repo Stats ==="
gh api repos/{owner}/{repo} --jq \
  '"Stars: \(.stargazers_count) | Forks: \(.forks_count) | Issues: \(.open_issues_count)"'

דפוס 4 — תנאים ולוגיקה

#!/bin/bash
set -euo pipefail

# Auto-assign issues לפי label
gh issue list --state open --json number,labels --jq \
  '.[] | {num: .number, labels: [.labels[].name]}' | jq -c '.' | \
  while read -r issue; do
    NUM=$(echo "$issue" | jq -r '.num')
    LABELS=$(echo "$issue" | jq -r '.labels[]')

    if echo "$LABELS" | grep -q "bug"; then
      gh issue edit "$NUM" --add-assignee "bug-team-lead"
      echo "#$NUM (bug) -> assigned to bug-team-lead"
    elif echo "$LABELS" | grep -q "feature"; then
      gh issue edit "$NUM" --add-assignee "feature-team-lead"
      echo "#$NUM (feature) -> assigned to feature-team-lead"
    fi
  done

דפוס 5 — Error handling נכון

#!/bin/bash
set -euo pipefail

# סקריפט עם error handling מלא
LOG_FILE="/tmp/gh-automation-$(date +%Y%m%d).log"

log() {
  echo "[$(date +%H:%M:%S)] $*" | tee -a "$LOG_FILE"
}

# בדיקת prerequisites
if ! gh auth status &>/dev/null; then
  log "ERROR: Not authenticated. Run 'gh auth login' first."
  exit 1
fi

REPO=$(gh repo view --json nameWithOwner --jq '.nameWithOwner' 2>/dev/null)
if [ -z "$REPO" ]; then
  log "ERROR: Not in a git repository."
  exit 1
fi

log "Starting automation for $REPO"

# פעולה עם retry
perform_with_retry() {
  local cmd="$1"
  local max_retries=3
  local attempt=1

  while [ $attempt -le $max_retries ]; do
    if eval "$cmd" 2>/dev/null; then
      return 0
    fi
    log "WARN: Attempt $attempt failed, retrying..."
    attempt=$((attempt + 1))
    sleep 2
  done

  log "ERROR: Failed after $max_retries attempts: $cmd"
  return 1
}

# שימוש
gh issue list --json number --jq '.[].number' | \
  while read -r num; do
    perform_with_retry "gh issue edit $num --add-label needs-review" && \
      log "Labeled #$num" || \
      log "Failed to label #$num"
  done

log "Automation complete. Log: $LOG_FILE"

# דוח issues — מספר, כותרת, labels
gh issue list --json number,title,labels --jq \
  '.[] | "#\(.number) \(.title) [\(.labels | map(.name) | join(", "))]"'

#!/bin/bash
set -euo pipefail

echo "=== PR Report for $(gh repo view --json nameWithOwner --jq '.nameWithOwner') ==="
echo ""

COUNT=$(gh pr list --json number --jq 'length')
echo "Open PRs: $COUNT"
echo ""

if [ "$COUNT" -gt 0 ]; then
  echo "--- PR List ---"
  gh pr list --json number,title,author,createdAt --jq \
    '.[] | "#\(.number) \(.title) by \(.author.login) (\(.createdAt[:10]))"'
  echo ""

  echo "--- Oldest PR ---"
  gh pr list --json number,title,createdAt --jq \
    'sort_by(.createdAt) | .[0] | "#\(.number) \(.title) (created \(.createdAt[:10]))"'
else
  echo "No open PRs!"
fi

2.8 Extensions — הרחבת gh עם תוספים

Extensions הם תוספים שמרחיבים את gh עם יכולות שלא קיימות בגרסה הבסיסית. כל extension מוסיף פקודת gh חדשה — כאילו היא חלק מהכלי המקורי. יש מאות extensions מהקהילה, מ-dashboards אינטראקטיביים דרך כלי ניקוי branches ועד generators של changelogs. והחלק הכי טוב: ליצור extension משלכם זה עניין של דקות, לא ימים.

Extension יכול להיות כתוב בכל שפה — Bash, Go, Python, Ruby, ואפילו compiled binary. כשמתקינים extension, gh מוריד אותו ל-directory מיוחד ומנגיש אותו כפקודה. אין צורך ב-PATH ידני או קונפיגורציה — הכל אוטומטי.

מציאה והתקנה של extensions

# חיפוש extension לפי מילת מפתח
gh extension search dashboard
gh extension search changelog
gh extension search "branch cleanup"

# התקנה
gh extension install dlvhdr/gh-dash        # dashboard אינטראקטיבי (TUI)
gh extension install seachicken/gh-poi     # ניקוי branches ממוזגים
gh extension install vilmibm/gh-changelog  # יצירת changelog אוטומטי
gh extension install mislav/gh-branch      # ניהול branches מתקדם
gh extension install gennaro-tedesco/gh-f  # fuzzy finder לריפו

# שימוש — פשוט מריצים
gh dash                                    # פותח dashboard
gh poi                                     # מנקה branches ישנים
gh changelog                               # מייצר changelog
gh f                                       # fuzzy find

ניהול extensions מותקנים

# רשימת כל ה-extensions המותקנים
gh extension list

# עדכון extension ספציפי
gh extension upgrade gh-dash

# עדכון כל ה-extensions בבת אחת
gh extension upgrade --all

# הסרה
gh extension remove gh-dash

Extensions מומלצים

gh extension install dlvhdr/gh-dash
gh dash

יצירת extension משלכם

יצירת extension ב-gh היא פשוטה להפתיע. בבסיסו, extension הוא פשוט סקריפט executable שמתחיל ב-gh-. אפשר לכתוב אותו ב-Bash, Go, Python, או כל שפה אחרת.

# 1. יצירת extension חדש (Bash)
gh extension create my-stats
cd gh-my-stats

# 2. זה יצר מבנה תיקיות עם קובץ gh-my-stats
# ערכו אותו:

#!/bin/bash
# gh-my-stats — Extension שמציג סטטיסטיקות ריפו
set -euo pipefail

REPO=$(gh repo view --json nameWithOwner --jq '.nameWithOwner' 2>/dev/null)
if [ -z "$REPO" ]; then
  echo "Error: not in a git repository"
  exit 1
fi

echo "=== Stats for $REPO ==="
echo ""

# נתונים בסיסיים
gh api repos/{owner}/{repo} --jq \
  '"Stars:    \(.stargazers_count)
Forks:    \(.forks_count)
Watchers: \(.subscribers_count)
Language: \(.language)
License:  \(.license.spdx_id // "None")"'

echo ""

# PRs ו-Issues
echo "Open PRs:     $(gh pr list --json number --jq 'length')"
echo "Open Issues:  $(gh issue list --json number --jq 'length')"

echo ""

# Top 5 contributors
echo "--- Top 5 Contributors ---"
gh api repos/{owner}/{repo}/contributors --jq \
  '.[:5] | .[] | "  \(.login): \(.contributions) commits"'

# 3. הפכו ל-executable
chmod +x gh-my-stats

# 4. התקינו מהתיקייה המקומית
gh extension install .

# 5. עכשיו אפשר להשתמש
gh my-stats

שימו לב למבנה: extension הוא פשוט קובץ executable שמתחיל ב-gh-. כשמריצים gh my-stats, gh מחפש קובץ בשם gh-my-stats בתיקיית ה-extensions ומריץ אותו. כל מה שהסקריפט מדפיס ל-stdout נראה למשתמש.

אם ה-extension עובד טוב ואתם רוצים לשתף אותו עם הקהילה:

# צרו ריפוזיטורי ב-GitHub (שם חייב להתחיל ב-gh-)
gh repo create gh-my-stats --public --source . --push

# עכשיו כולם יכולים להתקין:
# gh extension install your-username/gh-my-stats

2.9 אוטומציות מורכבות — Release ו-Issue Triage

עכשיו שיש לנו aliases, gh api, JQ, scripting ו-extensions — הגיע הזמן לשלב הכל לאוטומציות מורכבות שפותרות בעיות אמיתיות. הסעיפים הקודמים נתנו לנו את חלקי הלגו; עכשיו נבנה מהם מבנים שלמים.

נראה שני תרחישים שכל מפתח או maintainer נתקל בהם באופן קבוע: release workflow (שחרור גרסה) ו-issue triage (מיון issues). שני התרחישים האלה כוללים כמה צעדים שחוזרים על עצמם, דורשים זהירות, וקל לטעות בהם ידנית — בדיוק סוג המשימות שכדאי לאטמט.

אוטומציה 1: Release workflow מלא

Release הוא תהליך שמערב כמה צעדים מוגדרים: יצירת tag, דחיפה ל-remote, יצירת release עם changelog, ולפעמים גם עדכון documentation ושליחת התראות. כשעושים את זה ידנית, קל לשכוח צעד (למשל, לשכוח לדחוף את ה-tag), או לעשות טעות (למשל, ליצור tag על branch לא נכון). סקריפט release אוטומטי מצמצם את כל התהליך לפקודה אחת ומבטיח שכל הצעדים מתבצעים בסדר הנכון עם הבדיקות הנכונות:

#!/bin/bash
set -euo pipefail

# release.sh — Release automation
# שימוש: ./release.sh 1.2.0

VERSION=$1

if [ -z "$VERSION" ]; then
  echo "Usage: ./release.sh "
  echo "Example: ./release.sh 1.2.0"
  exit 1
fi

# בדיקה שאנחנו על main
BRANCH=$(git branch --show-current)
if [ "$BRANCH" != "main" ]; then
  echo "Error: Must be on 'main' branch (currently on '$BRANCH')"
  exit 1
fi

# בדיקה שאין שינויים לא שמורים
if ! git diff --quiet HEAD; then
  echo "Error: Uncommitted changes. Commit or stash first."
  exit 1
fi

echo "Creating release v${VERSION}..."

# יצירת tag
git tag -a "v${VERSION}" -m "Release v${VERSION}"
echo "  Tag v${VERSION} created"

# דחיפה
git push origin main --tags
echo "  Pushed to remote"

# יצירת release עם changelog אוטומטי
gh release create "v${VERSION}" \
  --title "Release v${VERSION}" \
  --generate-notes \
  --latest
echo "  Release created"

# הדפסת URL
URL=$(gh release view "v${VERSION}" --json url --jq '.url')
echo ""
echo "Release v${VERSION} published!"
echo "URL: $URL"

שימו לב לבדיקות בתחילת הסקריפט — הן מונעות טעויות נפוצות. בלעדיהן, אפשר בטעות ליצור release מ-branch לא נכון, או עם שינויים לא שמורים שלא ייכנסו ל-release. זה דוגמה מצוינת ל-"defensive scripting" — הסקריפט מגן על עצמו מפני שגיאות אנוש.

עכשיו במקום תהליך ידני של 5-10 דקות (שבמהלכו אפשר לשכוח צעד), זה שורה אחת:

./release.sh 1.2.0

ואם רוצים לשלב את הסקריפט עם GitHub Actions — אפשר ליצור workflow dispatch שמקבל את מספר הגרסה כ-input ומריץ את אותם צעדים. בפרק 8 (API & Webhooks) נראה איך לעשות את זה.

אוטומציה 2: Issue triage אוטומטי

ריפוזיטורים פעילים צוברים issues בקצב מהיר — ללא label, בלי assignee, ובלי אף אחד שטיפל בהם. אחרי כמה שבועות יש עשרות (או מאות) issues לא מטופלים, ואי אפשר להבין מה דחוף ומה לא. סקריפט triage אוטומטי עובר על כל ה-issues, מסווג אותם, מקצה אחראיים, ומסמן issues ישנים. במקום לבזבז שעה בשבוע על triage ידני, הסקריפט עושה את זה ב-30 שניות:

#!/bin/bash
set -euo pipefail

# triage.sh — Issue triage automation
echo "=== Issue Triage for $(gh repo view --json nameWithOwner --jq '.nameWithOwner') ==="
echo "Started at $(date)"
echo ""

TOTAL=0

# 1. Issues בלי label — סימון ל-triage
echo "--- Unlabeled Issues ---"
gh issue list --json number,labels --jq \
  '.[] | select(.labels | length == 0) | .number' | \
  while read -r num; do
    gh issue edit "$num" --add-label "needs-triage"
    echo "  #$num -> needs-triage"
    TOTAL=$((TOTAL + 1))
  done

# 2. Issues עם label "bug" בלי assignee — הקצאה אוטומטית
echo ""
echo "--- Unassigned Bugs ---"
gh issue list --label bug --json number,assignees --jq \
  '.[] | select(.assignees | length == 0) | .number' | \
  while read -r num; do
    gh issue edit "$num" --add-assignee @me
    echo "  #$num -> assigned to me"
    TOTAL=$((TOTAL + 1))
  done

# 3. Issues ישנים מאוד (יותר מ-180 יום) — הוספת label "stale"
echo ""
echo "--- Stale Issues (180+ days) ---"
CUTOFF=$(date -d "180 days ago" +%Y-%m-%dT%H:%M:%SZ 2>/dev/null || date -v-180d +%Y-%m-%dT%H:%M:%SZ)
gh issue list --json number,updatedAt --jq \
  ".[] | select(.updatedAt < \"$CUTOFF\") | .number" | \
  while read -r num; do
    gh issue edit "$num" --add-label "stale"
    gh issue comment "$num" --body "This issue has been open for 180+ days without activity. Marking as stale."
    echo "  #$num -> stale"
    TOTAL=$((TOTAL + 1))
  done

echo ""
echo "=== Triage complete ==="
echo "Processed actions: $TOTAL"

שילוב: Alias שמפעיל את הסקריפטים

הדבר האחרון שנעשה הוא לחבר את הסקריפטים ל-aliases. למה? כי aliases זמינים מכל ריפוזיטורי — לא צריכים שהסקריפט יהיה בתיקייה הנוכחית. שמרו את הסקריפטים במקום קבוע (למשל ~/scripts/) והפנו אליהם מ-aliases:

# alias ל-release
gh alias set --shell release \
  'bash ~/scripts/release.sh "$1"'

# alias ל-triage
gh alias set --shell triage \
  'bash ~/scripts/triage.sh'

# שימוש:
gh release 1.2.0
gh triage

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

מה ללמוד הלאה

הפרק הזה כיסה את הבסיס והבינוני של gh CLI. מכאן יש כמה כיוונים להמשיך:

• gh Codespaces — ניהול סביבות פיתוח בענן מהטרמינל. gh codespace create, gh codespace ssh
• gh Projects — ניהול project boards (v2) מהטרמינל. gh project list, gh project item-add
• gh Secret — ניהול secrets של ריפוזיטורי וארגון. gh secret set, gh secret list
• gh Variable — ניהול environment variables. gh variable set
• Advanced scripting — שילוב gh עם כלים כמו fzf (fuzzy finder), tmux (terminal multiplexer), ו-notify-send (notifications)

את כל אלה תוכלו לחקור לבד — עם הבסיס שבניתם בפרק הזה, כל פקודת gh חדשה תיראה מוכרת.

בפרק הבא: נלמד להקים אתרים חינמיים עם GitHub Pages — ונשתמש ב-Actions (פרק 1) ו-CLI (הפרק הנוכחי) כדי לפרסם אותם אוטומטית. אם יצרתם aliases בפרק הזה, הם כבר יעזרו לכם שם.