This really comes down to a definition of "safe" and "public"

Safe

It is said that it is "unsafe" to push to a branch after rebasing. In practice it means that, if the following scenario occurs:

• Developer A pushes a branch.
• Developer B pulls the branch.
• Developer A rebases the branch.
• Developer A pushed the branch again (in practice this would need to be a force push).
• Developer B pulls the branch again.

Developer B will have to do work, to fix their local history, either:

• Just update their local branch - if they don't have any commits.
• Repeat the rebase with their local history to place their new commit at the end of the new rebased history.

Public

Because you create work for other people when the previous scenario occurs, it is generally frowned upon to rebase history that other people have access to. For example a major open source project, probably wouldn't rebase their history.

However if you are:

• Working closely with another Dev.
• On a shared branch that only the two of you use.
• And you agree on / co-ordinate a rebase.

Then there really isn't a downside.

In Practice

If you do "screw up" and create a historical mess locally. It's usually fairly easy to fix.

• Create a new branch with the code you want on it.
• Get a fresh copy of master from the remote repository.
• Make sure your local master points to the same commit as the remote master.
• Rebase your local changes onto the end of the master.

This will force you to resolve all the merge/rebase conflicts yourself - so others don't have to.

You can now push this clean history either to the master branch or create a new branch for others to use.

--

A simple rule of thumb is: Don't "force push" to the remote repository. In that your can use rebase as much as you like locally (you can only hurt yourself) since git will always prevent you from damaging the public history, if you only every push without "forcing" it.

This really comes down to a definition of "safe" and "public"

Safe

It is said that it is "unsafe" to push to a branch after rebasing. In practice it means that, if the following scenario occurs:

• Developer A pushes a branch.
• Developer B pulls the branch.
• Developer A rebases the branch.
• Developer A pushed the branch again (in practice this would need to be a force push).
• Developer B pulls the branch again.

Developer B will have to do work, to fix their local history, either:

• Just update their local branch - if they don't have any commits.
• Repeat the rebase with their local history to place their new commit at the end of the new rebased history.

Public

Because you create work for other people when the previous scenario occurs, it is generally frowned upon to rebase history that other people have access to. For example a major open source project, probably wouldn't rebase their history.

However if you are:

• Working closely with another Dev.
• On a shared branch that only the two of you use.
• And you agree on / co-ordinate a rebase.

Then there really isn't a downside.

In Practice

If you do "screw up" and create a historical mess locally. It's usually fairly easy to fix.

• Create a new branch with the code you want on it.
• Get a fresh copy of master from the remote repository.
• Make sure your local master points to the same commit as the remote master.
• Rebase your local changes onto the end of the master.

This will force you to resolve all the merge/rebase conflicts yourself - so others don't have to.

You can now push this clean history either to the master branch or create a new branch for others to use.

--

A simple rule of thumb is: Don't "force push" to the remote repository. In that your can use rebase as much as you like locally (you can only hurt yourself) since git will always prevent you from damaging the public history, if you only every push without "forcing" it.

A push with --force is effectively an overwrite, if you push without --force it is always an append (to the history) - which is why it is considered safe.

This really comes down to a definition of "safe" and "public"

Safe

It is said that it is "unsafe" to push to a branch after rebasing. In practice it means that, if the following scenario occurs:

• Developer A pushes a branch.
• Developer B pulls the branch.
• Developer A rebases the branch.
• Developer A pushed the branch again (in practice this would need to be a force push).
• Developer B pulls the branch again.

Developer B will have to do work, to fix their local history, either:

• Just update their local branch - if they don't have any commits.
• Repeat the rebase with their local history to place their new commit at the end of the new rebased history.

Public

Because you create work for other people when the previous scenario occurs, it is generally frowned upon to rebase history that other people have access to. For example a major open source project, probably wouldn't rebase their history.

However if you are:

• Working closely with another Dev.
• On a shared branch that only the two of you use.
• And you agree on / co-ordinate a rebase.

Then there really isn't a downside.

In Practice

If you do "screw up" and create a historical mess locally. It's usually fairly easy to fix.

• Create a new branch with the code you want on it.
• Get a fresh copy of master from the remote repository.
• Make sure your local master points to the same commit as the remote master.
• Rebase your local changes onto the end of the master.

This will force you to resolve all the merge/rebase conflicts yourself - so other don't have to.

You can now push this clean history either to the master branch or create a new branch for others to use.

This really comes down to a definition of "safe" and "public"

Safe

It is said that it is "unsafe" to push to a branch after rebasing. In practice it means that, if the following scenario occurs:

• Developer A pushes a branch.
• Developer B pulls the branch.
• Developer A rebases the branch.
• Developer A pushed the branch again (in practice this would need to be a force push).
• Developer B pulls the branch again.

Developer B will have to do work, to fix their local history, either:

• Just update their local branch - if they don't have any commits.
• Repeat the rebase with their local history to place their new commit at the end of the new rebased history.

Public

Because you create work for other people when the previous scenario occurs, it is generally frowned upon to rebase history that other people have access to. For example a major open source project, probably wouldn't rebase their history.

However if you are:

• Working closely with another Dev.
• On a shared branch that only the two of you use.
• And you agree on / co-ordinate a rebase.

Then there really isn't a downside.

In Practice

If you do "screw up" and create a historical mess locally. It's usually fairly easy to fix.

• Create a new branch with the code you want on it.
• Get a fresh copy of master from the remote repository.
• Make sure your local master points to the same commit as the remote master.
• Rebase your local changes onto the end of the master.

This will force you to resolve all the merge/rebase conflicts yourself - so others don't have to.

You can now push this clean history either to the master branch or create a new branch for others to use.

--

A simple rule of thumb is: Don't "force push" to the remote repository. In that your can use rebase as much as you like locally (you can only hurt yourself) since git will always prevent you from damaging the public history, if you only every push without "forcing" it.