How to link a GitHub pull request to a task
The code is written and the pull request is open, but the task still says To do. Here is how to link a GitHub pull request to the task it closes, follow its status and checks, and let a merge finish the job.
The UnaTask team, Building UnaTask. Jul 26, 2026. 5 min read.
You finish the code. You open the pull request. And the task that started all of it still sits in To do, on a board in another tab, quietly out of date.
It is a small gap, but it adds up. Someone asks whether the login work shipped, and the honest answer is a shrug and a trip through GitHub. The plan and the repo drift, and standup turns into a status meeting.
A pull request is the work on a task that already exists, not a new task of its own. So in UnaTask it links to that task, carries its status onto it, and can close it when it merges. Here is how to set that up, start to finish.
First, connect GitHub once
Open Settings, then Integrations, then GitHub, and hit Connect. You sign in on GitHub and grant access once. The connection covers both linking pull requests and importing Issues, and it reads private repositories too, so nothing about your setup has to be public.
The token stays on our server and never touches the page. You only do this step one time.
Link a pull request to a task
Open the task and find the GitHub pull requests section. There are two ways to attach one:
- Search your open PRs. Start typing and your own open pull requests show up to choose from, across every repository you can see. Pick one and it links.
- Paste a link. Have a specific pull request in mind, or a teammate’s? Paste the link and it attaches.
A task can hold as many pull requests as the work needs, so a change that spans the API and the web app can carry both, each with its own status.
Or let the pull request link itself
If you would rather not open UnaTask at all, use the Copy reference button on the task. It puts a short marker on your clipboard. Drop that marker into the pull request description or the branch name, and the pull request attaches to that task on its own the moment it opens. Your normal GitHub flow does the linking for you.
Follow the status without leaving the task
Once a pull request is linked, its live state sits right on the task: open, draft, merged, or closed. A green tick tells you the checks pass, a clear mark tells you they do not, so you can see whether the code is ready without opening GitHub. You can refresh a link any time, or jump straight to it on GitHub in one click.
Across a whole project, those badges become a quiet map of what is coding, what is in review, and what already merged.
Decide what a merge should do
In the GitHub settings you pick what happens to a task when its pull request merges, for your whole workspace:
- Just update the badge. The task shows the pull request as merged and you decide what comes next.
- Notify the assignees. The people on the task hear that their code landed, with no one posting an update by hand.
- Move the task to Done. The task closes itself when the code ships.
The task and the code finally tell the same story, without anyone keeping them in sync by hand.
While you are there, pull your Issues in too
The same connection imports your GitHub Issues as tasks. Pick the repositories you care about and bring their open Issues in, on demand or automatically. Priority comes from the labels, the due date from the milestone, and a link back to the Issue rides along. Then you can time block them like anything else on your week.
Run that same moment again. You open the pull request, the task already knows, and when the checks go green and it merges, the task moves to Done on its own. Nobody asks whether it shipped, because the board already said so.
See the full GitHub integration