Is git rebase recommended while multiple developers working on same branch?

Question

In https://git-scm.com/book/en/v2/Git-Branching-Rebasing#_rebase_peril

It is recommended that rebasing should not be done when the repository is public.

And a recent post in git merge vs rebasing

recommends that rebase should not be done on branch shared between developers.

I understand that, because a developer might first merge the code and then he decides to rebase the code, other developers might end up in creating multiple duplicates commits as explained in Perils of Rebasing.

What if all developers come on a common agreement that everyone is going to always rebase the code instead of merging? Does the recommendation still apply?

P.S

All these answers confuse me. I think I will reframe the question again.

Let's assume that there is two developer working on two different computers. There is a central repository. The two developers cloned and started working.

Developer 1:

• Created a branch from local/master. Let's say local/iss123.
• Pushed it to remote

Developer 2:

• Pulled the changes from remote
• checksout to local/iss123
• Made some commits in local/iss123
• Pushed the changes to remote/iss123

Developer 1:

• Has some local commits
• He wants to rebase the branch with origin/iss123
• git rebase origin/iss123
• Then he pushes his commits to origin/iss123

Developer 2:

• Has some local commits
• He will rebase the branch with origin/iss123
• git rebase origin/iss123

and so on. Always developer 1 & 2 will rebase their branch with origin/branch then pushes their changes to origin/branch

After the functionality is stable, finally

Developer 1:

• checkouts to local/master
• pulls the latest code from origin/master
• checks whether there are any commits in local/master from other developers
• will checkout to local/iss123
• will rebase local/iss123 with local/master if there are any new commits.
• Then pushes the branch local/iss123 to remote/iss123 if there is a rebase done.
• Then checksout to local/master
• merges local/iss123 into local/master
• Then pushes local/master to origin/master

Developer 2:

• Will now pull the latest changes from origin/master and origin/iss123 to local/master and local/iss123 respectively

Later the cycle continues again.

Is this correct? Is this the right way when two developers are working on the same branch and always want to rebase instead of merging?

Answer 1

Let's assume that nobody does an interactive rebase, changing history, but merely just does a git fetch and then a git rebase origin/branch. In that case you would be able to do a push, if nobody else has pushed their recent rebase, otherwise you'll get conflicts and have to rebase yet again. The important thing is that everyone is diligent about rebasing and never does a push -f, since that will cause problems for everyone downstream.

The question, tho, is why you would want to do this. If the goal is just to avoid merge commits, you would be better off with a workflow such as this:

1. Branch off common branch
2. Do you work
3. Rebase your personal branch against the common branch (in case someone else committed something
4. push your branch against the common branch
5. if push fails because of conflict, go to step 3
6. Start over at one for next work item

This way everyone always commits their work as linear commits on top of the common branch.

Note: Leaving my original reply, but adding some more information based on the updated question.

Basically, my recommendation would be that both developers working on local/iss123 keep merging each other's changes as they go back and forth via git pull. Once iss123 is stable, one of the developers will rebase it onto master, i.e.

git checkout iss123
git checkout -b rebase_iss123
git rebase -i master
// select first as edit (so you can change its commit message)
// and select the rest as fixup
git checkout master
git merge rebase_iss123

This will take all of iss123 and compress it into a single commit at the tail of master.

Now developers can branch new issue work of that master.