Draft pull request always, only me?

Discussion
1

When I start working on a new branch, I always open a draft PR on GitHub immediately. Anyone else do that?

I like seeing all my commits appear and explain stuff as I go along.

If everyone on the team did it, it would be super easy to see what’s being worked on. I guess mostly because we use JIRA and not GitHub issues.

2

We encourage draft PRs at our company. They are great.

  • Transparency; It makes it easy for anyone to see what’s in progress. Branches are not the same. They can be used for throwaway WIPs, release candidates, etc.
  • Tooling integration; We use Linear for project management. You can configure it so that draft PRs mark an issue as in-progress, which is useful.
  • CI; You can run limited CI on drafts, and then full-fledged CI when the draft is converted to an open PR.
  • Diffs; It’s a quick way to see the diffs. When working on multiple branches, I, personally, find it useful to see what changes I have going in a draft. Branches can do this, too, but drafts are much easier to navigate to.
  • Early reviews / feedback; Although not common, I’ve found that drafts are useful to get feedback from the rest of the team if you have questions early on. You can fill in the description, provide some images or videos, and change course if needed. Before having to do things like complete code coverage.

To me, it’s a no-brainer. Use drafts. Encourage drafts.

3

@Paxton
Early review is one of the best reasons to do it. I always write them, then share them with the SME and the potential reviewers. More than a few times I’ve missed important in-scope parts of a ticket or included something out of scope and was corrected earlier rather than burning a bunch of effort.

4

Entire feature in a single commit squad reporting in.

Does anyone actually look at unfinished PRs and individual commits though? I know I definitely haven’t in my entire career.

5

Bex said:
Entire feature in a single commit squad reporting in.

Does anyone actually look at unfinished PRs and individual commits though? I know I definitely haven’t in my entire career.

For me, individual commits matter when using git blame to find out when and why something was done that way. As long as the commit message is useful for that, I don’t care how much changes are in a single commit. Does mean there’s a limit of course; at some point, a single commit message can’t be useful for git blame anymore.

6

@Reagan
Places I’ve worked lately squash every merge so commits really just show the ticket number (which is helpful). But some commits are full features.

7

Laken said:
@Reagan
Places I’ve worked lately squash every merge so commits really just show the ticket number (which is helpful). But some commits are full features.

Best practice with squash merge is to have a useful PR description template, and then have the whole PR description go into the commit message.

This is how I’ve done it now in multiple projects, and it’s extremely useful.

8

Bex said:
Entire feature in a single commit squad reporting in.

Does anyone actually look at unfinished PRs and individual commits though? I know I definitely haven’t in my entire career.

I use individual commits when I’m doing a multi-iteration PR for especially junior staffers. I only want to see what’s changed since I last looked at their PR.

9

Bex said:
Entire feature in a single commit squad reporting in.

Does anyone actually look at unfinished PRs and individual commits though? I know I definitely haven’t in my entire career.

I do. When there’s a push to an already made PR, it should be made in a single individual commit as to see what’s changed compared to the previous state of commit.

10

@Finian
You can branch from the PR branch, and then squash merge it back to the PR branch. Best of both worlds.

11

I don’t see a good reason for this. If anyone wants to see the branch and commits, they can just take a look without a PR. Polluting the PR tab is annoying.

12

Skyler said:
I don’t see a good reason for this. If anyone wants to see the branch and commits, they can just take a look without a PR. Polluting the PR tab is annoying.

But draft doesn’t have to pollute… You can filter out drafts with something like status:open.

13

Skyler said:
I don’t see a good reason for this. If anyone wants to see the branch and commits, they can just take a look without a PR. Polluting the PR tab is annoying.

I agree. It feels like unnecessary paperwork to me. Everyone is different, and I wouldn’t say it is categorically wrong. But while working on a change, I frequently find that there will be some small piece of it that I want to carve out and submit earlier. It might be some README improvement, a utility script, or some other piece of what I’m working on that is ready to go early and might help the team. If I opened the PR first, it would be more work to adjust when I’m submitting. I mean, it’s a pretty micro detail. But you asked for opinions…

14

Skyler said:
I don’t see a good reason for this. If anyone wants to see the branch and commits, they can just take a look without a PR. Polluting the PR tab is annoying.

That’s definitely a valid point.

15

I’m a fan of this. Not sure everyone’s got the time to watch your feature saga unfold, but it’s transparency, which is always a good policy. So often the PR is like that last afterthought; just get it up there and hit save so you can move on with your life.

16

I’d only ever use a draft PR if I wanted someone to take a look before it’s ready. Otherwise nah, it just creates clutter and makes me feel watched.

17

Reagan said:
I’d only ever use a draft PR if I wanted someone to take a look before it’s ready. Otherwise nah, it just creates clutter and makes me feel watched.

Same here.

18

I don’t open a draft immediately, but I do after I committed an important part of the task, that way my team members can check -if they want- the progress of the task or multiple tasks in case there’s one on hold.

19

I also do this, no one else on the team does…

20

Also use JIRA for work, but never open a PR until ready to review / push code. I’ve found the further into my career I go, the less I believe commits / team visibility matters, but might also be because I build a lot of side projects where time is more important than documentation.