4

I think the only rule about rebase and push is that

After commits are pushed to a public repo, don't rebase and push

But is it true that if we only use git push or git push origin <branch-name> and never use the --force or -f flag, then it can never happen?

nonopolarity
  • 146,324
  • 131
  • 460
  • 740

4 Answers4

6

If your public repo is a bare repo (meaning you can rebase anything directly on the public repo itself), and if you set the git config receive.denyNonFastForwards and receive.denyDeletes to true, then you should be ok.

If set to true, git-receive-pack will deny a ref update which is not a fast-forward. Use this to prevent such an update via a push, even if that push is forced.

If set to true, git-receive-pack will deny a ref update that deletes the ref. Use this to prevent such a ref deletion via a push.

See also "Is there a way to configure git repository to reject 'git push --force'?".

Note that those settings aren't available directly for a GitHub repo, for instance.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
1

It is true (I think) that the remote repo will never end up in a "bad" state if you don't use --force, so you can't do it accidentally.

But if you rebase commits that are already on the remote, your local repo might end up in a state where you can't push to the remote repo without going through some gymnastics that defeat the point of the rebase anyway.

Danica
  • 28,423
  • 6
  • 90
  • 122
1

Yes. You cannot rebase then push a remote tracking branch without using --force.

Steve McKinney
  • 3,183
  • 1
  • 23
  • 26
1

Without the "-f" flag, it can never happen.
But what would you do with your branch without the ability to push it?

Rebase is mostly to keep your branch history nice and serial
It is safe when you are the only one that merge into that code or if you are doing it locally only.
Otherwise, make sure you are on the same page with all other contributer before rebasing

Izack
  • 823
  • 7
  • 13