Regarding PRs. I have a an opinion which has become very unpopular since the rise of github.

The way github does PRs is great for open source projects where you have submissions from a very diverse set of developers. You need to evaluate the whole PR as whole and accept it or reject it.

But it is not ideal where you have a small team working on single product. The PR review becomes a gate and it has been my experience as a developer that you spend a LOT of time trying to get your PR reviewed.

My preferred approach is to do smaller and more frequent commits that are merged directly to the main branch. Developers learn to break a problem into very small changes which is a skill by itself. It is the responsibility of a lead or Sr engineer to check the commits as they come so they can provide feedback as soon as possible. This was the spirit of the original continuous integration ideas back in the day.

▲

steveklabnik 6 hours ago | parent | next [-]

Stacked diffs let you not have to evaluate the whole PR as a whole, and encourages smaller and more frequent commits.

Basically, I agree with you that large PRs are a problem, I just don't think it means you need to throw pre-land code review out the window.

▲

sharts 3 hours ago | parent [-]

Agree too bad stacked PRs aren’t really native to GH and you probably need to go with not so standard tools to manage them

	▲	steveklabnik 2 hours ago \| parent [-]
		Yes, it is unfortunate. I did link an announcement below that some form of this feature is coming, we'll see what it actually looks like when it goes public.

▲

gdulli 6 hours ago | parent | prev | next [-]

Modern software engineering culture is a treadmill ever in search of the next best practice that must be applied to a field made up of bespoke scenarios.

▲

htobc 2 hours ago | parent | prev | next [-]

That's pretty much how Google does dev, though not everyone there is consistent about small CLs or the <24 hour SLO for code review.

But yeah, if the team lead is aware of what everyone is working on, and prioritizes fast CLs review, huge amounts of friction and slowdown are removed from the process

▲

dhosek an hour ago | parent [-]

What I’ve seen is things like I ask a question about a piece of code during a PR, the author changes that code and my question vanishes into the ether with no indication (unless it’s lost in the noise of email notifications) that the code was changed and my question is no longer relevant (and if there was, perhaps an answer, the answer is also lost).

	▲	steveklabnik an hour ago \| parent [-]
		Yes. This specific aspect of GitHub is the reason why many teams don't want you to modify commits, but instead, add more commits. Which then also leads to squash-merging branches. Other systems, like Gerrit, handle this much better!

▲

2 hours ago | parent | prev | next [-]

[deleted]

▲

bardackx 2 hours ago | parent | prev | next [-]

this is how we work using graphite

▲

gib444 3 hours ago | parent | prev | next [-]

What does the full story look like in your preferred approach? Regarding releasing for example

▲

huflungdung 3 hours ago | parent | prev [-]

[dead]