Rebase if not published does not fit in continous integration mind

[limdor]

I am opening this issue to discuss the recommendation about not rebasing a branch if it has been published. There are several situations that the preferred workflow brings you to do it.

The general advise about rebasing is not to do it once you have pushed the changes to the remote making the changes public, but a clear distinction should be done. Is the branch intended to be public or you should be the only one working on that branch? Or is it published but in a private repository?

Let me write an example:

You have a big project, with a lot of tests for different platforms. To make sure that your master branch is working you have a CI system running on all the branches and on the pull requests. Because of the different platforms, the only way that has the developer to know that the work will not break master is to let the CI run the test. And the only way to do that is pushing the changes to the branch.

To me there are two possible workflows to work but both require rebase after pushing the changes:

• The developer creates a fork of the main repository and creates a branch to implement a new feature. When she wants to test the changes, she can create a pull request to the main repository and the CI runs the tests.
• The developer creates a branch in the main repository with a convention clearly identifying what developer is (developer_id_feature_name) to implement a new feature. When she wants to test the changes, she can create a pull request to the main repository and the CI runs the tests.

In both scenarios the only way for the CI system to see the changes is that the developer pushes the changes.
After the pull request, the developer sees that some test is failing, she forgot some code in one of the commits. What should she do? Rebase creating another branch because it was already published or rebase her branch?

To me when there is a Continous Integration system in place, the rule does not apply anymore, or at least not in the current form. The idea would be:
You can rebase if you have not pushed the changes or if it has been pushed but you are rebasing a private branch. Where private branch means that by convention no one should checkout or create commits on top of it.

Because CI systems are getting more and more important and most of the times will be the ones running the tests, I think that it is worth it to rephrase the recommendation in the book.

[ben]

This is super project-dependent. The big idea is that, if someone else is going to be pushing to a branch, you shouldn't rewrite commits on that branch without a pretty good reason. I do this myself at work – rebase to clean up a bunch of why is this failing on Travis commits – and we should probably make it more a bit clearer in the book.

We probably wrote "pushed to a remote where others will see" as a shorthand for "other people will be making commits based on your commits", but they're not exactly the same. Do you have a clear idea of how to fix it? I'd love to merge a PR from you, so you get onto the contributors list.

[limdor]

I will write some draft