Hacker News new | ask | show | jobs
by V-2 1734 days ago
"You don't actually want these changes to end up in the main branch before they are done."

True - and it sounds like a textbook scenario for introducing a feature branch... this approach has worked well for me.

The idea of queueing up "sub-requests" is interesting, but it comes at the cost of creating another layer of complexity (in my view).
2 comments
gocartStatue 1729 days ago
Feature branches introduce more complexity than real value (bold statement, right)?

I really enjoy Dave Farley's videos on youtube - "Continuous Delivery" channel. A friend recently sent me this piece from Atlassian: https://www.atlassian.com/git/tutorials/comparing-workflows/...

link
KronisLV 1734 days ago
Agreed! I guess what i'm trying to say (in an awfully wordy way) is that we could probably improve the UI for pull/merge requests and gain a lot from it.

I mean, GitHub and GitLab already improved many development workflows with their inline comments (as well as other features, like code recommendations) and it feels like sooner or later more improvements are bound to come!

link
WorldMaker 1734 days ago
I don't have as much experience with GitLab, but I actually think Github has a lot of tools in their PR system today for doing "early" or "work in progress" PRs incrementally. You can start a PR on an empty branch. You can apply a label "Work in Progress" and start discussion immediately. If you review a chunk of code the PR is pretty good about showing you what you've already reviewed versus what is new in the most recent update. If for some reason you feel a need to start over and force push an entirely new branch to the PR, Github's PR system handles it better than you would expect (and auto-closes old comments, etc).

I've found the tools are better than people expect them to be and the hard part for me is convincing junior developers that it is "okay" to start PRs "early", that they don't have to feel like they've finished a task to get comments/reviews on work in progress. There's a lot of embarrassment/group politics in the way sometimes from using "PR early" workflows.

link
boleary-gl 1734 days ago
GitLab employee here - that is true of GitLab too.

But I agree the bigger challenge than any tooling challenge is getting the team convinced that starting a PR/MR early is not only okay but also the way to operate. Creating physiological safety around it as well as making iteration a part of the day to day workflow is a challenge but an important one.

link