3 ms·

For our (smallish, fast moving) team we disabled history rewrites on all branches on the server, have all the developers manage their git workflow using the (ve

For our (smallish, fast moving) team we disabled history rewrites on all branches on the server, have all the developers manage their git workflow using the (very awesome) osx app called gitup, and have everybody rebase and resolve conflicts before pushing. We always rebase and only merge in unusual circumstances where preserving the merge conflict resolution decisions might make sense (which almost never occurs). Everybody on our team including very junior developers and designers are able to quickly pick up this workflow and almost never have problems - and when they do it's always obvious that they should get help from someone -- and typically this is exactly the scenario where some analysis is needed -- so its a good use of time for a second pair of eyes.

vkjv 10y ago
I'd be interested to know how this scales on a larger team. Looking at the number of open PRs on some of our repos, I would guess doing this in a larger organization would cause an unnecessary amount of busy work when everyone scrambles to rebase after each merge.
- breatheoften 10y ago
  I think it would scale pretty far based on my experience with the process on our team. I'd see more blockers to scaling team size coming more from other factors rather than the merge strategy -- things like the quality of tests and probability of problematic merge conflicts -- which I think would depend ultimately more on the code organization/team-member communication than the merge strategy. I think Facebook uses a souped up version of this strategy (based on how I interpret their presentation on it anyway). It seems like the engineer ships off a commit, and then it goes into a review branch where it gets automatically rebased against master continuously while waiting for review. When it passes review it goes onto master as the newest commit -- if a conflict happens before the review completes or during the final rebase then the engineer is notified to resolve the conflict and push again -- I think review needs to happen again in this case -- but it makes sense to do so as the first review was done without awareness of the change that caused the conflict ... I'm sure I don't describe their actual process accurately but I think it something along these lines ...

vkjv 10y ago

I'd be interested to know how this scales on a larger team. Looking at the number of open PRs on some of our repos, I would guess doing this in a larger organization would cause an unnecessary amount of busy work when everyone scrambles to rebase after each merge.

breatheoften 10y ago
I think it would scale pretty far based on my experience with the process on our team. I'd see more blockers to scaling team size coming more from other factors rather than the merge strategy -- things like the quality of tests and probability of problematic merge conflicts -- which I think would depend ultimately more on the code organization/team-member communication than the merge strategy. I think Facebook uses a souped up version of this strategy (based on how I interpret their presentation on it anyway). It seems like the engineer ships off a commit, and then it goes into a review branch where it gets automatically rebased against master continuously while waiting for review. When it passes review it goes onto master as the newest commit -- if a conflict happens before the review completes or during the final rebase then the engineer is notified to resolve the conflict and push again -- I think review needs to happen again in this case -- but it makes sense to do so as the first review was done without awareness of the change that caused the conflict ... I'm sure I don't describe their actual process accurately but I think it something along these lines ...