What do you mean? Like not pushing at all until you’re making the MR? Because if the branch has ever been pushed before and you rebase, you’re gonna need to force push the branch to update it.
Not everyone works in large orgs that require pull requests. We have a dev branch multiple devs push to and just branch off for test phase. So I commit locally (also interactive rebasing when fixing stuff from earlier). When I’m ready to push, I fetch, rebase and push. I never force push here.
Uh, it’s definitely a bad idea to be concurrently developing on the same branch for a lot of reasons, large org or not. That’s widely considered a bad practice and is just a recipe for trouble. My org isn’t that huge, and on our team for our repo we have 9 developers working on it including myself. We still do MRs because that’s the industry standard best practice and sidesteps a lot of issues.
Not everyone works in large orgs that require pull requests. We have a dev branch multiple devs push to and just branch off for test phase. So I commit locally (also interactive rebasing when fixing stuff from earlier). When I’m ready to push, I fetch, rebase and push. I never force push here.
Uh, it’s definitely a bad idea to be concurrently developing on the same branch for a lot of reasons, large org or not. That’s widely considered a bad practice and is just a recipe for trouble. My org isn’t that huge, and on our team for our repo we have 9 developers working on it including myself. We still do MRs because that’s the industry standard best practice and sidesteps a lot of issues.
Like, how do you even do reviews? Patch files?