0

We have a shared remote branch (called feature_branch in this example for simplicity) based off of master that several people are pushing commits to. During the development we had to merge in from master twice to get some necessary changes. Now the time is nearly here to deliver the contents of feature_branch to master and a question has arisen: is it safe to rebase from master and then push back to master?

In the example we have already branched out from master and done a few commits in the feature_branch (and other people have pushed commits to the master branch):

git checkout master
git pull --rebase
git checkout feature_branch
git pull --rebase
git merge master

Then we do some more work in the feature_branch and other people push other stuff to master. Then the above procedure is repeated once again (so there are two merge commits in feature_branch in total).

Now the decision is taken to stop working in the feature_branch and it's time to deliver to master. All colleagues are informed and since the team is small and everyone is sitting in one room, this is not a problem. To deliver we could do like this:

git checkout master
git pull --rebase
git checkout feature_branch
git pull --rebase
git rebase master
git checkout master
git merge --ff-only feature_branch
git push

Is this safe? I get the feeling that this can cause problems but when I tried this locally (everything except the final git push) it actually looks good (only the feature_branch unique commits are replayed on top of master). But even if it works sometimes, are there circumstances where this is dangerous or ill-adviced or can this be used as preferred Way of Working (assuming that we sometimes MUST have shared feature branches that require master to be merged into it from time to time)?

Just to clarify, in this case we are not that interested to preserve "absolute" history (as rebase will rewrite history for the feature_branch commits) from the feature branch, we just want the commits to be delivered to master.

Jola
  • 21
  • 5

2 Answers2

1

It can be dangerous. The bad case is when you rebase an "evil merge" containing an "evil change" which does not conflict with other commits. This change can be silently lost while rebasing.

jbialobr
  • 1,382
  • 1
  • 13
  • 14
0

Generally the way i have always approached is: 1. check out feature branch 2. rebase feature branch on top of master 3. locally after rebase you should see a clear linear history 4. and then do a force push of that local feature branch commit to the remote feature branch 5. once done, check out master branch 6. merge feature branch into master branch and push commit to master

C Kingsley
  • 228
  • 1
  • 10
  • The problem with that approach is that when you rebase the feature branch on top of master, you rewrite history. That means that everybody else who are working in that shared branch have to scrap their local branches and get this new branch from the remote repo. – Jola Jan 18 '16 at 07:40
  • I understood from your question above that you want to now deliver the feature branch and intend to inform everyone that they need to stop working on the feature branch. So most of their local should be committed and pushed to the feature branch at that point. That should resolve any outstanding issues still left in the everyone else local commit. If this is not possible then everyone will need to rebase their local branch on top of master or feature branch after you have successfully done the rebase. Does that help? – C Kingsley Jan 18 '16 at 09:09
  • Then I see what you mean. But then there is no need to push the feature branch (step 4, forced push). I guess that no-one should work in the feature branch any more at this point. And I think my original question remains: is it always safe to rebase feature branch on top of master after master has been merged into feature branch a few times during development? – Jola Jan 19 '16 at 10:03
  • After a rebase since history has been rewritten it will be very tricky to push to the feature branch without doing a force push. There should be no problem doing a rebase even though the feature branch contains merges from master. – C Kingsley Jan 19 '16 at 10:37
  • I don't need to force push to the repo branch since all I want to do is to get my changes in the feature branch to the master branch. Hence I need to rebase it ontop of master and then merge it to master (by using --ff-only I know for a fact the there will be no merge commits, should I have screwed something up before this point). But I think your last comment has the answer to my question: it should be safe to rebase ontop of master after merging in from master. Thank you! – Jola Jan 20 '16 at 15:06