Hacker News Reader

Comment by jedberg | Hacker News Reader

Help me understand something -- right now my workflow is to create a new branch when I'm working on a new feature. One branch per feature. I check in frequently and push up so my work is saved.

Sometimes I ask people to look at the code in progress when I want opinions on architecture or just overall code quality.

When I think the feature is ready for merging, I'll create a pull request.

How does a draft PR help me? What do I get with a draft PR that I don't already have?

I assume it's a good idea, and everyone here seems to think so too, so I think I'm missing something obvious.

Edit: Lots of great points below, mostly pointing out features that I don't really use a lot, which is why I didn't see the improvement. Thanks everyone!

View on HN

Opening a Draft PR-

* Signifies that the work is being done, preventing duplicate efforts.

* Shows people all the work being done in a single location, rather than having to hunt down forks and branches.

* Gives a nice UI showing the exact changes, without having to compare to specific commits.

* Gives a review interface, where people can comment on the code itself or even on specific lines.

All your other points still stand- you still create one branch per feature, check in frequently and push up work. If you explicitly want a review you can ask people for it (as you already do), but now they have a nice place to do it.

All great points, thanks for the explanation!

I see PRs with titles prefixed "DO NOT MERGE" or "WIP". People want the UI that goes along with a PR, prior to it being ready to merge.

Right, this is a much better approach than such titles (or equivalent labels, which I've also seen), because it directly impacts GitHub's "ready to merge" checks at the bottom of the PR (without needing an outside bot/service for it).

You don't have a review mandate before merge?

Yeah, but people might approve it for merge when it is not obvious that it isn't ready.

Wouldn't this same person do the same for a Draft PR? i.e. if they're just reviewing things wouldn't they just set the Draft PR 'ready to review' and then review it?

Or maybe I'm confused by your answer, are people commonly reviewing PR's without being asked?

What the OP is saying is that someone can review a PR even when it's not ready by accident (not seeing WIP in title/tag), while with a draft, the reviews are disabled until its ready for review.

This basically is a better WIP system than before because it can prevent accidental reviews and wasting time of re-reviewing when it actually is ready.

I use and ask other team members to make draft PRs now (ad-hoc, basically the subject includes "WIP").

#1. PR triggered checks will fire

#2. You use the same tools for reviewing and can leave better comments

#3. I like PR comments to be detailed and explain the changes well for non-team members. Composing the draft message can help reveal items I need to make clearer or need to still do.

#4. It's clearer which branches/tasks are still being worked on, and how the work is progressing.

> PR triggered checks will fire

Ah, didn't even think of this one. Thanks!

This works well on your own project, when you have permission to create branches... but what if you're trying to contribute to some other large and complex project? "Go look at my forked branch" isn't a great way to discuss a feature.

Ok this is an excellent point. Thanks!

The blog post seems to specifically answer this question far better than anyone here could. It essentially formalizes a workflow like the one you describe.

Remember than anything GH does “can be done by email”, to cite some early commentary. But collectively, the ease of use, and defaulting to best practice, that GH introduced have vastly improved and enlarged the open source community.

I know I never submitted patches in the 10+ years in the industry pre-Github. Now, barely a week goes by without at least one PR.

> The blog post seems to specifically answer this question far better than anyone here could.

Clearly not, otherwise I wouldn't have asked. :)

> It essentially formalizes a workflow like the one you describe.

How though? What do I gain by doing it this way that I can't already get? What's easier now? That's the part I'm not seeing.

If you are happy with your workflow you can continue as usual. In other work-cultures people might not like your approach which is why a draft PR can be helpful. Basically what this feature does is that it avoids having to point to a branch and tell your coworker that it is WIP that you want feedback on. Usually a PR will also show the changes directly.

I've used sr.ht for some time and it's not that hard to work with e-mail flow. It's still not as easy (the main problem is setting up SMTP settings but that's done once). From my perspective most of the issues with git that GH solves is tooling, that same could be achieved with ML.

That said, having worked with git internals and models of repo access I'm pretty sure GH introduced forks to work-around the issues with repository control. Conceptually there is no need for forks, one could push to private branches of the target repo directly. Unfortunately git doesn't have tools for per-branch level controls directly. More details in https://github.com/rescrv/gitswitch

In a draft PR you can add a description and annotate lines of code with comments - making it easier for your peers. A branch can be harder to find and in your case you had to manually notify that you wanted them to have look at your code, whereas with a draft PR you probably get a notification.

So basically it's for the code competing interface? I guess that makes sense. I've never worked with a team that made good use of those, so maybe that's why I didn't think of it. Thanks!

> competing

I assume you meant commenting? It took me a minute.

Reply on news.ycombinator.com