> ## Documentation Index > Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt > Use this file to discover all available pages before exploring further. # Different Pull Request Statuses > Guide to GitHub pull request lifecycle and statuses Draft Open Closed Merged with actions, CI considerations, review tips, and merge strategies. In this lesson we explain the common statuses a GitHub pull request (PR) goes through from creation to final resolution. Understanding PR states helps teams manage workflows, coordinate code review, and interpret CI results efficiently. This guide covers the typical lifecycle and practical tips for each status. Key PR states * Draft * Open * Closed * Merged | State | What it means | Typical actions | | ------ | --------------------------------------------------------- | ----------------------------------------------------------- | | Draft | Work-in-progress PR; not ready for final review or merge. | Run CI, share early feedback, convert to open when ready. | | Open | Active review and CI evaluation. | Reviewers comment, request changes, authors push commits. | | Closed | PR terminated without integration into the base branch. | Archive discussion, reopen if needed, or create a new PR. | | Merged | Changes have been integrated into the base branch. | PR conversation remains for history; branch may be deleted. | ## Draft A draft PR indicates the author intends to share ongoing work but the changes are not yet ready for a formal review or merge. In the Draft state: * The Merge button is disabled. * Automated notifications to code owners are often reduced. * CI can still run, so you can validate tests and integrations early. * Draft PRs are ideal for seeking informal feedback and iterating without signaling completion. Example: create a draft PR from the GitHub UI (select **Create pull request** → **Convert to draft**) or with the GitHub CLI: ```bash theme={null} gh pr create --draft ``` Use draft PRs to run CI and validate integration early. This helps catch build or test regressions before formal review. ## Open An open PR signifies active collaboration: reviewers evaluate the compare branch against the base branch, leave comments, and may request changes. Authors typically respond by pushing additional commits, updating the branch, or addressing requested changes. The image shows a pull request status indicating an open request to add 'Test' text to the file index.html, with notes about active collaboration, code review, and commit updates. During this state you should expect: * Continuous integration to validate the branch (status checks, linters, tests). * Reviewers to use comments, suggestions, and change requests. * Authors to update their branch; each push updates the PR and re-triggers CI. Best practices while a PR is open: * Keep commits focused and use descriptive messages. * Respond to review comments promptly and push follow-up commits rather than force-pushing when possible. * If multiple changes are required, consider using draft status until the PR stabilizes. ## Closed A closed PR means the proposed changes were not integrated into the base branch. Common reasons: * The feature or fix was abandoned. * The approach was replaced by a different solution on another branch. * The PR was superseded or no longer relevant. Closed PRs retain the conversation and commit history for reference and can often be reopened if required. If a PR is closed and you want to continue the work, consider: * Reopening the PR (if appropriate). * Creating a new branch and PR with a refined approach. ## Merged A merged PR indicates successful integration: the commits from the compare branch were incorporated into the base branch. Merging is performed by users with appropriate write or maintain permissions. After merging: * The PR becomes part of the base branch history. * The PR conversation remains accessible for audits and context. * The source branch may be deleted (depending on repository settings). Common merge strategies: | Strategy | Result | | ---------------- | ----------------------------------------------------------------------------------------- | | Merge commit | Preserves all commits and creates a merge commit on the base branch. | | Squash merge | Combines all PR commits into a single commit on the base branch. | | Rebase and merge | Reapplies commits onto the base branch, preserving commit history without a merge commit. | The image shows a pull request status indicating that a change titled "add japanease" has been merged, with a few notes about integration and permissions. Be mindful of branch protections and required status checks. Repositories may block merging until CI passes, required reviews are completed, or specific approvals are given. ## Quick reference and links * GitHub Docs: [About pull requests](https://docs.github.com/en/pull-requests) * GitHub CLI: [gh pr create documentation](https://cli.github.com/manual/gh_pr_create) This overview should help you interpret PR lifecycle states, streamline reviews, and ensure CI and permissions are handled correctly during each stage.