Reputation: 21
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.
Upvotes: 0
Views: 1181
Reputation: 1518
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.
Upvotes: 1
Reputation: 238
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
Upvotes: 0