0

Sometimes we fork an upstream project to contribute bug fixes. We check out a new branch, commit changes and send a pull request to upstream. But it may take some time for the pull request to be handled and during this time additional changes may occur in the upstream. In this case, should we merge the new upstream head or rebase our changes on it?

If our repository is private, I think rebase gives a cleaner history. But there is a principle that you shouldn't rebase commits that have been published remotely. When we are using public git servers such as github, does this mean merging is our only choice? Is it recommended that we leave the branch as it is for upstream developers to handle (i.e. non-fast-forwards)?

Cyker
  • 9,946
  • 8
  • 65
  • 93

1 Answers1

0

The principle of not to rebase if something is already published applies for branches that people might be working on top of them (like, say, master.... once you have published something on master, there will be plenty of people fetching, merging it, rebasing on top of it, etc... so moving it around is a little painful)... but most feature branches aren't worked on from the point they are finished (which is where you would create the PR from) so if it's a feature branch and no one is working on top of it, feel free to rebase it.

eftshift0
  • 26,375
  • 3
  • 36
  • 60