Earlier quoted context omitted.
For those of us who are uneducated / haven't seen this before: how do you use rebase to merge a separate branch? Are you suggesting you just `git rebase my-branch` from master / develop? How do you coordinate this with multiple team members. Merges appear to work better when you have multiple team members with separate feature branches that may have some overlap (conflicts may occur, but those can be handled as they…
First off, see [0] for a very helpful insight into the rebase command's syntax. With multiple team members (each on their own feature branch), I encourage what I call the "pitchfork" approach [1], where the feature branches get stacked up into an integration branch to preview what the master branch would ultimately be when all the feature branches are merged in via pull requests. A key part of building and recreating…
1) git-rerere is really cool, and can probably make things very convenient, especially if you do several rebase operations to stack your integration branch. Without git-rerere, I can't imagine this workflow being remotely sane (resolving the same conflict every time you try to add an additional commit on one of the branches would get old fast).
2) This approach could probably help in "merging" (not git-merge, but you know) several feature branches with lots of conflicts, but does sort of rely on "As long as you make clean commits on the correct feature branches". While it's a laudable goal, how often can this really be the case, especially in projects where contributors are not composed of a single, core team (i.e. open source or research based projects)? I would think that ensuring clean commits is hard enough without a fixed team, so I am genuinely curious how hard it is to enforce this assumption.
See, here's the thing -> integration like this seems to work really well, especially if you're sharing branches across the repository with several teammates / coworkers. But what if you're not sharing branches? In the example you provided at [1], you have three branches: A, B, and C. Because you have access to all branches, it's easy to make an integration branch that does master -> Ai -> Bi -> Ci, and to handle all the conflicts with rerere. Then as A, B, C evolve and more commits are pushed, you could even have a build-bot of some sort assist in rebuilding the integration branch and checking for significant conflicts or errors. Of course, this all works great, but git is distributed.
What that means in practice is you may have master and branch A on your machine, and your two coworkers might have B and C on their machines, but none of you have rights to push these branches to the main repository location. This is common in BDFL-type projects, where one person or a handful of people are the only ones capable of pushing branches to the main repo. If your organization is split up like this, and individual developers tend to work on fixing single issues at a time, then you really never get the opportunity to use the integration branches, since you're only ever integrating your own (single) branch! If there's a bottleneck on upstream whatsoever, then the difference between this model and merging isn't really apparent, as you're not really getting any benefit either way (rebase -i non-withstanding). It would seem this would just kick the can down the road for the next developer to rebase off of the new master (with A rebased/merged in) and then solve their problems locally. This could be a significant duplication of effort if handled poorly.
I suppose you could have an intermediate "integration" repo where everyone pushes their branches, and build this sort of setup in assistance with some sort of CI, but I wonder how that scales if you have > 20 issue branches. The reason I ask this is because in the pitchfork workflow, how do you know which branch gets integrated first, second, etc.? I'm sure there's somewhat of a natural ordering in practice, as some issues or features probably take priority over others for some reason or another, but what if you don't know? What's the best way to keep the history? Certainly history isn't everything, but you may want to bisect down the road and A -> B -> C may cause more problems than B -> C -> A (you might not know at this point in time). Furthermore, do you not need someone / several people working together to resolve these conflicts? Is it sane to keep bothering your coworkers with "hey I just made a new integration branch, what do I do about conflict X", while they're still pushing new commits to B or C?
I think the pitchfork strategy for rebasing onto master is intriguing, and I'd have to play with it for an extended period of time to really get answers to some of these questions. Unfortunately, it seems that the bottleneck issue isn't something that can be easily solved for most projects. I don't come across many projects that allow every contributor to push branches, especially if they allow for pull-requests of any kind (even for one-off contributions). Nonetheless, I've definitely learned something here, and I think I understand better why one might want to rebase instead of merge. Then again, pull-requests are very heavily tied to merge-based flows, and if the project I'm contributing to wants to use them, then I'm probably hooped to begin with. Git is great for letting teams decide how they want to work, but it can be very painful if even one contribution doesn't follow guidelines (both to break a consistent history / commit graph, as well as if you ever have to git-bisect over it).
[1] https://gist.github.com/dkaminski/c8e59221bea74ab1fea615a468...