There are two ways to resolve a GitHub issue. You can click the Close issue button manually, or you can have it close automatically by including "Closes #X" in a Pull Request description. Automatic closing is preferred because it links the fix to the issue, creating a clear record of what was changed and why.
How Issue Resolution Works on GitHub
When a task is done or a bug is fixed, the corresponding GitHub issue should be closed. Closing an issue signals to your team that the work is complete. There are two approaches. The first is manual: open the issue and click the Close issue button. This works when the fix does not involve code — for example, a question that was answered or a task that was handled outside GitHub. The second approach is automatic: when a developer or AI tool like Lovable creates a Pull Request, they include "Closes #X" (where X is the issue number) in the PR description. When that Pull Request is merged, GitHub closes the issue automatically and creates a visible link between the issue and the PR. This automatic method is preferred because it creates a traceable chain from problem to solution. Closed issues are not deleted — they move to the Closed tab and can be reopened at any time.
Prerequisites
- A free GitHub account
- A repository with at least one open issue
- A modern web browser
Step-by-step guide
Open the issue you want to resolve
Open the issue you want to resolve
Navigate to your repository on github.com. Click the "Issues" tab in the top menu bar. You will see a list of open issues. Click on the issue you want to close. Make sure you are on the correct issue by checking the title and number (like #15) at the top of the page. Read through any comments to confirm the work is actually complete before closing.
Expected result: You see the individual issue page with its title, description, comments, and a comment box at the bottom.
Close the issue manually using the Close issue button
Close the issue manually using the Close issue button
Scroll to the bottom of the issue page where the comment box is. Next to the green "Comment" button, you will see a dropdown arrow. Click it to reveal options: "Close as completed" (the task is done) and "Close as not planned" (you decided not to do it). Choose the appropriate option. You can also type a final comment explaining why you are closing it — for example, "This was fixed in the latest update" — and then click "Close with comment." The issue moves from the Open tab to the Closed tab.
Expected result: The issue shows a purple "Closed" badge and moves to the Closed issues list.
Auto-close an issue by linking it to a Pull Request
Auto-close an issue by linking it to a Pull Request
This is the preferred method for code-related issues. When creating or editing a Pull Request, type one of these keywords followed by the issue number in the PR description: "Closes #15", "Fixes #15", or "Resolves #15." When the Pull Request is merged into the main branch, GitHub automatically closes the linked issue. The issue page will show a reference to the PR that closed it, creating a complete audit trail. AI tools like V0 create Pull Requests automatically — you can edit the PR description to add "Closes #X" before merging.
Expected result: The Pull Request description shows a linked issue, and merging the PR will close the issue automatically.
Verify the issue is closed and linked correctly
Verify the issue is closed and linked correctly
After the Pull Request is merged, go back to the Issues tab and click "Closed" to switch from the Open issues list to the Closed issues list. Find your issue and click on it. You should see a timeline entry saying something like "closed this via PR #23." Click the PR link to see exactly what code changes resolved the issue. This link between issues and PRs is one of GitHub's most powerful features for project tracking.
Expected result: The closed issue shows a reference to the Pull Request that resolved it, with a clickable link.
Reopen an issue if it was closed by mistake
Reopen an issue if it was closed by mistake
If an issue was closed prematurely — maybe the fix did not actually work, or it was closed by accident — you can reopen it. Open the closed issue and scroll to the bottom. Click the "Reopen issue" button next to the comment box. The issue moves back to the Open list, and everyone assigned to it gets a notification. Add a comment explaining why you are reopening it, like "The bug is still happening on mobile devices."
Expected result: The issue badge changes from "Closed" back to "Open" and it reappears in the Open issues list.
Complete working example
1# Keywords That Auto-Close GitHub Issues23Use any of these keywords in a Pull Request description4followed by the issue number to auto-close when merged:56## Supported Keywords7- `Closes #15`8- `closes #15`9- `Fixes #15`10- `fixes #15`11- `Resolves #15`12- `resolves #15`1314## Multiple Issues15You can close multiple issues in one PR:16- `Closes #15, closes #16, closes #17`1718## Cross-Repository19To close an issue in a different repository:20- `Closes owner/repo#15`2122## Example PR Description23```24## Changes25- Added email validation to signup form26- Updated error messages for clarity2728Closes #1529```Common mistakes when markking a GitHub Issue as Resolved
Why it's a problem: Closing an issue without verifying the fix actually works
How to avoid: Always test or confirm that the feature or bug fix is complete before closing. If the issue gets reopened repeatedly, it wastes everyone's time.
Why it's a problem: Closing issues without leaving a comment explaining why
How to avoid: Add a brief closing comment: "Fixed in PR #23" or "Decided to handle this differently in issue #30." This helps future team members understand the decision.
Why it's a problem: Typing the closing keyword in a PR comment instead of the PR description
How to avoid: Auto-close keywords only work in the Pull Request description (the main body text), not in comments on the PR.
Why it's a problem: Deleting issues instead of closing them
How to avoid: Always close issues, never delete them. Closed issues preserve the history of decisions and fixes. You can filter them out of your default view.
Best practices
- Use "Closes #X" in Pull Request descriptions to auto-close linked issues when merged
- Always add a closing comment explaining what resolved the issue
- Use "Close as completed" for done tasks and "Close as not planned" for cancelled ones
- Verify the fix actually works before closing an issue
- Reopen issues promptly if the fix turns out to be incomplete
- Review closed issues periodically to make sure nothing slipped through the cracks
- Link every Pull Request to at least one issue for a complete audit trail
Still stuck?
Copy one of these prompts to get a personalized, step-by-step explanation.
Explain how GitHub's auto-close keywords work in Pull Request descriptions. I'm a non-technical founder and I want to understand how issues and PRs are linked together.
Frequently asked questions
What is the difference between closing and deleting a GitHub issue?
Closing marks an issue as resolved but keeps it in the repository's history — you can search and reopen it. Deleting removes it permanently. Always close issues; never delete them.
Can a merged Pull Request close issues in a different repository?
Yes. Use the full reference format: "Closes owner/repo#15" in the PR description. Both repositories must be in the same GitHub organization or the same user account.
What happens if I close an issue by mistake?
Open the closed issue and click the "Reopen issue" button at the bottom. The issue moves back to the Open list immediately.
Do AI tools like Lovable auto-close issues?
Lovable pushes code directly to the main branch rather than creating Pull Requests, so it does not use auto-close keywords by default. You can manually close issues after verifying the Lovable changes address them. V0 creates Pull Requests where you can add closing keywords.
Can I close multiple issues with one Pull Request?
Yes. Include multiple keywords in the PR description: "Closes #10, closes #12, closes #15." All listed issues will close when the PR is merged.
Can RapidDev help set up automated issue tracking for my project?
Yes. RapidDev helps teams configure issue templates, auto-close workflows, and GitHub Projects boards so your task tracking is efficient and organized from the start.
Where do closed issues go?
Closed issues move to the Closed tab on the Issues page. Click "Closed" next to the search bar to view them. They are never deleted and remain fully searchable.
Talk to an Expert
Our team has built 600+ apps. Get personalized help with your project.
Book a free consultation