How do you deal with non-fast-forwardable situations in the git rebase workflow?

Question

I have been reading about git rebase and the advantage of using a rebase workflow instead of a merge workflow. (I haven't actually been in the situations below as I am new to git)

I have read that one of the standard workflows for projects with multiple contributors is for the contributor to regularly regularly rebase their topic branch with the master branch of the "main (central/truth/canonical) repository". Rebasing before making a pull request leads to merges becoming fast-forwards.

While this part of it makes sense to me, I see many situations where merges will not be fast forwards. I want to know what happens in these situations. Does the project master (the owner of the canonical branch) pull the topic branch onto a local branch, rebase and merge (to ensure it remains a fast forward) or does the project manager just make a non-fast-forward merge?

Once a contributor rebases and pushes his/her topic branch to a public repository, pushing a second rebase is not possible. What happens if those reviewing the contribution want to see some of the code refined/tweaked before merging? The master branch would probably have changed by the time the contributor makes the fixes and the contributor cannot rebase since that would mean rewriting the history of a public repository.

Another situation where a fast-forward won't be possible would be when multiple submissions are made before the project manager can merge any into the master branch. While the first merge will be a fast forward, the remaining will not.

To summarize my question: What happens in situations where the branch that needs to be pulled in not based on master and cannot be rebased by the contributor? Does the project manager do the rebasing himself/herself before merging or does he/she just make a non-fast-forward merge?

Answer 1

The way GitHub has solved this problem is by allowing contributors:

• to have their own repo on the server side ("fork") where they can git push --force at their heart's content)
• to propose patches (pull requests) to the main repo (not branches, only commits to be applied or not), and that in a way for the maintainer to easily see if those patches can be applied in a fast-forward manner or not.

In the case where a fork isn't possible, you mention:

Once a contributor rebases and pushes his/her topic branch to a public repository, pushing a second rebase is not possible.

Pushing should be possible, maybe by deleting your published branch first, and re-creating it by pushing it again.
As long as said branch has been rebased on top of the canonical branch, the new branch will be able to be "fast-forward" merged.

More generally, the maintainer is rarely the one doing the work of solving non-trivial merges: if there is no fast-forward step in sight, he/she will simply reject that branch and will ask the contributor for a new one.

Answer 2

I think it would be simpler for everyone if the contributor got the new master and put his fixes in a new branch. This would allow the manager to quickly do a FF merge and be done with it. If the managers are like mine, that'll be the closest they get to the actual source:)

Answer 3

That's a lot of questions there. I'll toss in my two cents to say that I can't think of a single scenario that rebasing can't convert to a straight-line, fast-forwardable graph. It may take more or less work, depending on how the commits lie, but it should always be possible. If you can give specific scenarios that you think wouldn't be rebasable, maybe I or someone else can work out how you would do it.