Reputation: 2449
I have a webapp where a new feature has been merged down to the develop branch and is ready to be merged to master and deployed from there. It's a rather complicated feature and I need to be able cleanly revert if anything behaves unexpectedly.
I'm planning this:
git checkout master
git merge --squash develop
git commit -m 'Merged...etc'
All easy enough and straightforward. And if I do need to rollback, I'm hoping to be able to merely do this:
git checkout master
git revert HEAD
However if this is necessary, I will need to fix the issue in develop and re-merge at a later date. And I read this in git help revert:
Reverting a merge commit declares that you will never want the tree changes brought in by the merge. As a result, later merges will only bring in tree changes introduced by commits that are not ancestors of the previously reverted merge
Which suggests I might not be able to re-merge the same code at a later date. Or does the use of --squash mean that this is not considered to be a merge commit (as the commit is a separate transaction) and I can re-merge in the future.
So I'm looking for some clarification on whether this is viewed as a merge commit by git, or not.
Upvotes: 1
Views: 1396
Reputation: 9197
Linus Torvalds can explain it better than I.
TL;DR: To merge changes in after a reverted merge, you need to revert the revert (or maybe something different).
That said, in your case, you wont create a merge commit. A merge commit has 2 (or more) parents. git merge --squash && git commit
will create a commit with one parent.
Upvotes: 2