6

There is this rule to not to rebase commits that were pushed to remote repository. As long as I understand general reasons for that, it's not clear for me, does it apply also to such scenario:

Lets say that I work on some feature, which development will take several days. So, I create branch MyFeature, checkout to it, and commit some stuff. Since work takes several days, I don't want to keep it in my local machine, so for the backup’s sake, I push this branch to remote.

After finishing work, I want to merge it somehow to the master.

My questions:

  1. On the assumption that no one else will never checkout and pull MyFeature branch, and base his work on commits from this branch (why someone would like to pull some random branch?), is it ok to rebase such remote branch? (using –force switch)
  2. If it is still not advisable for some reason (I would like to learn that reason, though) what is the alternative? Simple merge? But if so, afterwards, I still would like remove MyFeature branch from, both local and remote repositories. So how it would be different from (1)? I still change history by removing it completely.
  3. Is above mentioned scenario rare or untypical? I mean, while searching answer for this, reading tutorials and SO questions about git-rebase, there is always stressed this peril of rebasing remote branches, but there are never considered other use cases like that. IMHO it's pretty common to work on some feature longer that day, and I think no cautious developer shouldn't keep changes only on his computer...
Improve this question

4 Answers 4

Reset to default
4

On the assumption that no one else will never checkout and pull MyFeature branch, and base his work on commits from this branch, is it ok to rebase such remote branch? (using –force switch)

Not only is it OK to rebase and force push your remote feature branch on master, it is the only way to stay ahead of master by bringing in changes while maintaining linearity. The moment you rebase your local feature branch on another branch (such as master), you have to force push to the remote since you have effectively rewritten history. There is no risk of doing any harm since you will be the only one working on this branch. I take the approach that nothing Git created is inherently evil, and every Git feature has its time and place. This is one instance where doing a force push is acceptable.

In fact, a remote personal feature branch is the only instance where it OK to use rebase on a branch which has already been pushed to the remote. As mentioned, you won't be causing problems for anyone else since only you have checked out this branch.

That being said, doing a rebase of a public branch which is being shared by many users is dangerous, because it will likely cause conflicts for everyone when they do their next pull (except of course for the user who did the rebase).

Improve this answer
2

Very subjective. "Is it OK?" To whom? To you? To your employer? Ask them.

As for technical feasibility:

  1. Yes, no problem.

  2. You could merge and delete the branch. I prefer this method (see? subjective) and I even use git merge --no-ff so that even if the merge is a fast-forward, the merge commit is created. Deleting a branch does not modify history; you just remove the branch pointer, not the commits.

    Another alternative is git merge --squash which squashes the branch to merge into a single commit that gets applied to the branch you want to merge into. I'm not a fan of that but some people like that.

  3. No, it's neither rare nor untypical.

Improve this answer
1
  • (At the moment) this is the only answer that covers the second half of point 2. => +1 :-)
    – siegi
    Commented Apr 16, 2015 at 18:32
2

In my opinion it's not a problem to rebase a feature branch with only one developer. I work the exact same way as you do where I rebase my own feature branches. The git history becomes so much easier to view if all the feature branches is rebased before merged in. But this is personal preference of course.

It's shared branches that cause trouble when rebasing. See an explanation on why here: https://superuser.com/a/667200

Improve this answer
1

On the assumption that no one else will never checkout and pull MyFeature branch, and base his work on commits from this branch (why someone would like to pull some random branch?), is it ok to rebase such remote branch?

Of course, and you don't need --force for the rebase step.
You only need it to force push your branch

 git checkout MyFeature
 git fetch
 git rebase origin/master
 git push --force

As long as you are updating your own branch on the upstream repo, that should not be an issue.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.