Why can’t you view your changes locally?
I’m a fan of this and do it as well and most of the counterpoints here don’t really make any sense.
This is one feature I really love and hate that my last few teams use Bitbucket.
Dunno… I prefer having just a branch with what I’m doing, and when ready to merge, open the PR. Status updates go in Work items (aka issues or tickets) and unready code goes into a separate branch. If the PR needs changes, it gets marked that way in the review.
>If everyone on the team did it, it would super easy to see what’s being worked on.
You’re proposing that in order to see what the team is working on, I dig through a bunch of open draft PRs and read some number of recent commit messages on them?
You and I have different definitions of “super easy to see.”
I do it for me; there’s no expectation that anyone else will see it.
Generally most useful when you have a whyTF did that stop working.
I squash down a bit before taking it out of draft for actual PR tho.
I do that if I want other people on the team to be able to peek on progress and give feedback as I go. Like for UI and presentation changes where the direction isn’t obvious sometimes.
I rarely hear people talk about what to do when a dev works in private for several days, and then a PR turns up that’s in the wrong direction or the wrong approach, but the PR ends up getting merged anyway because nobody is going to ask the dev to redo large chunks of it and/or there’s no time. Early work-in-progress previews are a great way to avoid this.
I’ve never thought to do that; if nobody notices, all good.
No, because that triggers a deployment and every commit after that one until the PR is merged.
I can still see all my commits in a nice way with git log --oneline.
Lennon said:
No, because that triggers a deployment and every commit after that one until the PR is merged.
I can still see all my commits in a nice way with git log --oneline.
Damn, good point!
I check out repos every morning before I start to review PRs.
I HATE when people have PRs open that aren’t ready for review.
For the most part, PRs should be open when you are done. Maybe there is a case for demoing your work to someone so opening a draft PR would be valid, but rarely. When this is the case, I recommend adding “in progress” or “not for review” at the beginning of the title.
Just my 2 cents.
I open draft PRs for a different reason. When working on a large web app, it’s really annoying getting GitHub notifications when someone rebases their branch to master and it notifies every single dev team that released code since you last merged master. Draft PRs don’t notify the reviewers of our codeowners file which ensures that I can get my PR polished before sending it to the correct person.
For my pet projects, sometimes for bigger features (the smaller ones I tend to merge without PRs).
Raising a PR generally triggers a CI build every time you commit (unless you explicitly tell it not to), I wouldn’t want to waste build time on a branch that isn’t ready.
I’m all for draft PRs. No reason to put it up early unless I want others to see it though. Feels like a waste and it can send unnecessary emails to my team.
Yeah I wish there was a way to set it as a default per repo.
I only do it if I want somebody to give feedback on something specific. Other than that, it can happen in the regular PR.
It’s a lot of pressure to be giving that much visibility. Some people are more suited to note-taking than others. It’s great that you are, but imagine now making it a reflection of your job performance. I fully support you providing this as a service to your team and leveraging your communication skills as a way to stand out and provide value, rather than worrying about what extra value you should be expecting from your team.
Anyone can compare your branch anytime. Why would you want to create draft PRs?
You got Jira to see who is working on what.
Unnecessary noise in a sea of already open PRs that actually matter.