2

I have read that I should never rebase public branches. I'm unsure whether this also means that I shouldn't do git pull --rebase (of a feature branch where I collaborate with a colleague, and thus the branch is public). Can somebody please confirm that doing a git pull --rebase is fine in that case, and that the idea that a public branch should not be rebased is referring to not doing a rebase of the feature/origin onto a master?

To clarify again, I want confirmation that it's ok to do a pull --rebase, basically updating my local copy of the branch with the origin of it, rebasing my commits onto it.

Nickpick
  • 6,163
  • 16
  • 65
  • 116
  • Like `git pull --rebase origin master` ? – ckruczek Feb 24 '17 at 10:46
  • It's okay to do for topic branches, but not okay to branches like *master*. – 0andriy Feb 24 '17 at 10:47
  • I'm basically working on a feature branch – Nickpick Feb 24 '17 at 10:47
  • `git pull` = `git fetch` followed by a second Git command. The second command is normally `merge` but `--rebase` directs Git to run `git rebase` second. The branch that is rebased is *your* branch, specifically your *current* branch, with the `` argument being the tip of whatever branch you fetched (normally your current branch's *upstream* setting, but it can get complicated depending on your arguments to `git pull`). This also invokes the *fork point* machinery, which is, well, complicated... – torek Feb 24 '17 at 10:57

1 Answers1

3

Yes, that's fine

Because doing that only rewrites your local commits ontop of the public history.

Rebasing itself isn't "the problem" with public branches, it's any workflow whereby you have to force-push to a public branch that's a concern.

See also:

Community
  • 1
  • 1
AD7six
  • 63,116
  • 12
  • 91
  • 123