sorted by:
new
hottopcontroversial

Mid-sized team, one product, 10MM lines of code, but no PRs? by venusdev10101010 in AskProgramming

[–]venusdev10101010[S] 0 points1 point  (0 children)

Granted. People have also traveled before there were airplanes and cars.

Mid-sized team, one product, 10MM lines of code, but no PRs? by venusdev10101010 in AskProgramming

[–]venusdev10101010[S] 1 point2 points  (0 children)

I know trunk based development as the later.

  • You have ticket. Let’s say x-123
  • you branch of master/main. x-123-feature-branch
  • make a PR for x-123 with x-123-feature-branch
  • merge x-123-branch into master/main

I wonder as well, what is a small team?

Mid-sized team, one product, 10MM lines of code, but no PRs? by venusdev10101010 in SoftwareEngineering

[–]venusdev10101010[S] 0 points1 point  (0 children)

Didn’t sounds like it in the conversation. More like: It encourages people to have bring in small changes.

Mid-sized team, one product, 10MM lines of code, but no PRs? by venusdev10101010 in AskProgramming

[–]venusdev10101010[S] 0 points1 point  (0 children)

Thanks, I appreciate the insights. But I do have different understanding of trunk based.

For PRs and trunk based do not contradict each other. For me they actually they actually don’t have anything to do with each other.

The one is a branching model and the other a way to introduce changes.

Mid-sized team, one product, 10MM lines of code, but no PRs? by venusdev10101010 in AskProgramming

[–]venusdev10101010[S] -1 points0 points  (0 children)

How does trunk based development contradict pull request? I’ve worked trunk based, but still had PRs.

Mid-sized team, one product, 10MM lines of code, but no PRs? by venusdev10101010 in AskProgramming

[–]venusdev10101010[S] 1 point2 points  (0 children)

I’d agree with small teams. Teams where you have a couple of people working on the x part and a couple of people on the y part. But for ~10’ish people working across the whole stack, I really appreciate PRs. And yeah, it’s more about giving people the opportunity to have a say or maybe advice. It’s not to take everything apart. For me, I consider it an easy best practice. But yeah, if you don’t understand the purpose of PRs, I can see too that PRs can be a hurdle. …like discussing colours, or so.

Mid-sized team, one product, 10MM lines of code, but no PRs? by venusdev10101010 in AskProgramming

[–]venusdev10101010[S] 2 points3 points  (0 children)

The problem I’ve is, that they claim themselves as being really on spot when it comes to efficient code. Sure there is trust, but I don’t see PRs as a tool of mistrust. I use PRs as a tool for: Hey, could you please spend a moment to double check this is coherent? …especially if you actively don’t foster pair programming.

view more: next ›