Learn Git - GitHub Issues, Labels & Milestones

#Introduction

In episode 11 we discussed Pull Requests as the gateway for code entering main. A PR answers the question of how code changes. But before any PR exists, a team must first agree on what needs to be done — and that is the territory of GitHub Issues. An issue is a unit of work, a discussion space, and a decision trail that can be tracked from birth to completion.

Why does this matter in the real world? A healthy repository is not just about clean code, but also an organized backlog. Good teams do not rely on memory or private chat — everything is recorded in an issue: who is working on it, what category it belongs to, and when it should be done. This episode covers creating issues, organizing them with labels, assignees, and milestones, and linking them to commits and PRs so issues close automatically.

#What Are GitHub Issues?

An issue is an entry that represents a single piece of work or discussion: it can be a bug report, a feature request, or a plain task. Every issue has a unique number (e.g. #12) that stays stable for the life of the repository, so it can be referenced from commits, PRs, or other issues.

The issue lifecycle is simple: created → discussed → assigned → worked on via a PR → closed. All conversations and cross-references are recorded, forming documentation that can be traced years later.

#Creating an Issue on the GitHub UI

Open the Issues tab, click New issue, choose a template if available, then fill in the title and body. Writing a good body is a skill: a vague description produces a wrong implementation.

A suggested structure for the three issue types:

• Bug report — reproduction steps, expected result, actual result, environment (OS, version, browser).
• Feature request — the problem to be solved, the proposed solution, alternatives already tried.
• Task — goal, acceptance criteria, and dependencies if any.

## Deskripsi
Setelah submit form login, pengguna tidak dialihkan ke dashboard.
 
## Langkah reproduksi
1. Buka /login
2. Isi email dan password valid
3. Klik tombol Masuk
 
## Hasil yang diharapkan
Dialihkan ke /dashboard
 
## Lingkungan
Linux, Chrome 120, Git 2.45

#Organizing with Labels, Assignees, Milestones

Three main tools turn a pile of issues into an organized backlog:

Labels — colored categories that mark the type of issue. GitHub provides built-in labels, and you can create your own:

Assignees — the responsible people. One issue should ideally have one assignee to avoid split responsibility. Milestones — grouping issues toward a single goal, for example the v1.3 release or this week's sprint, complete with a due date.

With this combination, the board changes from a random list into a work map: filtering the bug label plus the "Sprint 12" milestone immediately shows what must be done this week.

#Managing Labels and Milestones from the CLI

Labels and milestones can also be managed from the terminal. Create labels with gh label create and milestones with gh milestone create:

gh label create bug --color "d73a4a" --description "Kerusakan fungsi"
gh label create good-first-issue --color "7057ff"
gh milestone create v1.3 --due-date 2026-09-01

When attaching an issue to a label or milestone, make sure the choices are consistent with the team's rules — for example, every issue tagged bug must have an assignee before entering the sprint.

#Creating Issues via GitHub CLI

The whole flow above can be run from the terminal with gh issue create:

gh issue create \
  --title "Bug: tidak dialihkan setelah login" \
  --body "Setelah submit form, pengguna tidak menuju dashboard." \
  --label "bug" \
  --assignee @me

Supporting commands that are often used:

gh issue list --label "bug" --state open
gh issue view 12
gh issue close 12 --reason completed

#Linking Issues to Commits & PRs

To close an issue automatically, use a keyword in the commit message or PR description: Fixes #12, Closes #45, Resolves #89. When a PR containing that keyword is merged into the default branch, the linked issue closes automatically and is linked to the PR — no need to open the issue page.

git commit -m "fix: arahkan pengguna ke dashboard setelah login
 
Menutup bug redirect setelah autentikasi.
 
Fixes #12"

When creating a PR via the UI, put the keyword in the most visible part of the description:

## Ringkasan
Memperbaiki redirect setelah login berhasil.
 
## Issue terkait
Closes #45

After pushing and creating the PR, add the keyword to the PR description if it is not there yet. GitHub supports many keyword forms: close, closes, closed, fix, fixes, fixed, resolve, resolves, resolved — all followed by the issue number.

#Closing

This episode turns GitHub from a place to store code into a work management system: understanding the role of Issues for bug reports, feature requests, and tasks; organizing a backlog with labels, assignees, and milestones; creating and managing issues through the UI or gh issue create; and closing issues automatically with the Fixes, Closes, and Resolves keywords in a commit or PR description.

The points to take with you:

• An issue is a unit of work and a discussion space that is tracked permanently.
• A good bug report always includes reproduction steps.
• Labels, assignees, and milestones turn a pile of issues into a managed backlog.
• Keywords like Fixes #12 in a commit or PR close issues automatically when merged.
• The entire flow is available in GitHub CLI, not only in the browser.

The more people collaborate on one repository, the more important security boundaries become. In episode 13 we cover Repository Security & Branch Protection Rules — protecting main from merges without approval, preventing API key and database credential leaks, and making use of GitHub Secret Scanning and Dependabot Alerts. See you in episode 13!