0

I've read that it's never recommended to re-base a branch which is made publicly available. But let's say I have master which everyone is working on and my_feature where only I am working on it (but is also pushed to a remote repo). Say I want to merge my_feature into master, so I checkout my_feature first, do git rebase master, then switch to master and do git merge my_feature.

Is this safe to do since many people have made plenty of commits and are heavily collaborating on the master branch (but almost nobody on the new_feature branch)?

kfb
  • 6,252
  • 6
  • 40
  • 51
daremkd
  • 8,244
  • 6
  • 40
  • 66

2 Answers2

1

Yes it's safe because you are only changing history for your local branch by rebasing it on top of master. When you push master back the remote, the history for this publicly shared branch hasn't changed.

Abizern
  • 146,289
  • 39
  • 203
  • 257
1

Short answer: Yes it is safe. Long answer: Rebasing itself is only dangerously if you do it wrong.

Wrong: You rebase a branch (origin/master) which was cloned by some people --> bad. In this case you are destroying the common history of 'some' people.

Right: You rebase something onto master, thats correct. But you must not forget to fetch the origin/master branch from the origin first, and update your master branch to it. When your local master and origin/master branch are the same, you can rebase your changes onto the master.

git rebase master my_feature

Then push the changes so that master and origin/master are the same again.

See: Git pull.rebase this is a possibly dangerous operation

Community
  • 1
  • 1
Manuel
  • 3,828
  • 6
  • 33
  • 48