Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Forcing a Git rebase

Tags:

git

Use case: Three git clones of the same repository A, B, B2. Repos A and B are normal, B2 is naked (made with --bare). All under my control, i.e. there is only one user.

On site B, I do work (several git commits), then git push B2.

  • On site A, git pull B2.
  • On site A, git rebase -i xx..HEAD to squash some commits and clean history (a great command).
  • Q: How to communicate the result to site B?

I can do:

  • git push --force B2

But this is not quite right. The site B working directory will have a strange history after a git pull B2.

I need some way to not use --force. I'd like to throw away xx..HEAD on B2, then push normally from A. Perhaps:

On B2 (the naked repo)

  • git reset --hard xx

Not sure that is enough. I can do it by re-cloning from site A (delete B2, git init --bare, push from A), but that seems like overkill. The How to push/pull Git rebase post seems relevant, but I'm hoping for some answer besides "don't do this".

Bottom line, how do I truly and completely throw away commits on B2 so the rebased history from A will be accepted as new commits?

like image 225
FDS Avatar asked Jul 29 '11 16:07

FDS


People also ask

Do you have to force push a rebase?

To push the changes to the branch after a rebase, you need to force push your commits using the -f or --force flag in the git push command on Git. This is because something has changed in the remote branch and the commit history is different for both the remote and your local branch.

Why you should not use rebase?

Rebasing can be dangerous! Rewriting history of shared branches is prone to team work breakage. This can be mitigated by doing the rebase/squash on a copy of the feature branch, but rebase carries the implication that competence and carefulness must be employed.

Can I rebase after pushing?

If you had already pushed changes before using THAT option, those changes wouldn't be rebased because they're already in the remote. The only exception may be if you have multiple remotes, and have pushed changes to one remote, then do a pull/rebase from another - that could cause serious problems.

When should you avoid rebase?

If you use pull requests as part of your code review process, you need to avoid using git rebase after creating the pull request. As soon as you make the pull request, other developers will be looking at your commits, which means that it's a public branch.


2 Answers

 git reset --hard 

throws away commits just in the sense in which you want them to be thrown away.

like image 59
nes1983 Avatar answered Oct 01 '22 00:10

nes1983


I need some way to not use --force. I'd like to throw away xx..HEAD on B2, then push normally from A.

Um, throwing away xx..HEAD on B2, then pushing normally from A is pretty much the exact definition of --force. Just use --force again when pulling to B and you'll be okay, as long as you rebase any branches in B back to commit xx or earlier before pulling.

like image 32
Karl Bielefeldt Avatar answered Sep 30 '22 22:09

Karl Bielefeldt