3 ms·

I feel like I must be unaware of how other people use git, if this is remotely relevant. Everywhere I've worked has used a similar flow. Commits in master corr

I feel like I must be unaware of how other people use git, if this is remotely relevant. Everywhere I've worked has used a similar flow. Commits in master correspond 1:1 to PRs. Your personal flow of local commits or branches is irrelevant; your PR is reviewed as a unit, and merged as a squashed commit on top of master. The description of the PR is either exactly identical to the commit message, or only slightly modified. Clearly lots of people don't work that way, because that doesn't leave any room for a messy git history. I also don't know why I should care about the in-progress commits of my coworkers when I'm reviewing a PR as a unit.

eplanit 5y ago
That's the model I'm accustomed to, as well. Most shops I have worked with in the past 10 years use Gerrit, which facilitates that (transparently).
croo 5y ago
Yeah but... What happens when you work with a new college who put two features in a branch because he forgot to switch and someone did a shitty review and it's now in master but you can't revert because its release day and three other colleges already did a rebase and you cannot take the time to revert this mess anymore because other bugs and... I mean commits in need of repair happens, however good your workflow is.
- delecti 5y ago
  That's why new members of the team get extra attention for their first few changes, PRs require two reviews, and we don't rebase master. I've really just never needed to do major repairs to the master branch of a project I was working on. We're probably missing out on git features that could be nifty, but it's also easier to avoid shooting ourselves in the foot.
omegalulw 5y ago
This doesn't seem like a good idea. What about features that take 10000+ lines of code? I'm guessing you ask your devs to split them across PRs. Is it really a far cry then to pull commits via rebase. If your PR commits are good it shouldn't be a big deal. Not to mention how do you revert commits on master? A big PR that broke prod will lead to nastyy merge conflicts when reverting.
- delecti 5y ago
  We don't have features that take 10,000 lines of code. Our biggest features get split among a couple smaller PRs to review them along the way. I know there's a case for larger feature branches that accumulate an entire large feature before being merged into master, but in a world of microservices, it's just not a use case we've had to consider. And reverting PRs happens occasionally, but because changes are much smaller than the scale of what I assume you deal with, we never have many (if any) merge conflicts to deal with. We primarily deploy new features with feature flags, so it's vastly easier to just turn them off until we can fix the issue.
  - cellularmitosis 5y ago
    > I know there's a case for larger feature branches that accumulate an entire large feature before being merged into master, I think you are tempering your stance in the name of arguing charitably, but I’ll push against that. No, there is no case for this. Branches are pain accumulators. The longer they live, the more pain they will bring to everyone involved. If you need to work on something big, that’s what feature flags are for.

eplanit 5y ago

That's the model I'm accustomed to, as well. Most shops I have worked with in the past 10 years use Gerrit, which facilitates that (transparently).

croo 5y ago

Yeah but... What happens when you work with a new college who put two features in a branch because he forgot to switch and someone did a shitty review and it's now in master but you can't revert because its release day and three other colleges already did a rebase and you cannot take the time to revert this mess anymore because other bugs and... I mean commits in need of repair happens, however good your workflow is.

delecti 5y ago
That's why new members of the team get extra attention for their first few changes, PRs require two reviews, and we don't rebase master. I've really just never needed to do major repairs to the master branch of a project I was working on. We're probably missing out on git features that could be nifty, but it's also easier to avoid shooting ourselves in the foot.

omegalulw 5y ago

This doesn't seem like a good idea. What about features that take 10000+ lines of code? I'm guessing you ask your devs to split them across PRs. Is it really a far cry then to pull commits via rebase. If your PR commits are good it shouldn't be a big deal. Not to mention how do you revert commits on master? A big PR that broke prod will lead to nastyy merge conflicts when reverting.

delecti 5y ago
We don't have features that take 10,000 lines of code. Our biggest features get split among a couple smaller PRs to review them along the way. I know there's a case for larger feature branches that accumulate an entire large feature before being merged into master, but in a world of microservices, it's just not a use case we've had to consider. And reverting PRs happens occasionally, but because changes are much smaller than the scale of what I assume you deal with, we never have many (if any) merge conflicts to deal with. We primarily deploy new features with feature flags, so it's vastly easier to just turn them off until we can fix the issue.
- cellularmitosis 5y ago
  > I know there's a case for larger feature branches that accumulate an entire large feature before being merged into master, I think you are tempering your stance in the name of arguing charitably, but I’ll push against that. No, there is no case for this. Branches are pain accumulators. The longer they live, the more pain they will bring to everyone involved. If you need to work on something big, that’s what feature flags are for.