I'm not sure but something might not be working correctly in sourcetree (windows app in my case).
We always use the built in GitFlow UI feature, which is great. But here is the issue.
Here is the result:
Capture d’écran 2014-10-20 à 16.59.10.png
59cb57a is the source revision
a357127 and 715136d are both commits made to the feature branch before finishing.
06fdab5 is the resulting "merge commit" which, if i'm not mistaken, shouldn't be here if i checked the rebase option.
My 2 dev commits should just be on top of 59cb57a and 715136d should now be the head of develop. Am I right?
Alright I found the answer (not the fix) : :
Apparently this is a "normal" behaviour of gitflow explained here : https://github.com/nvie/gitflow/issues/100#issuecomment-769968
Sourcetree correctly call gitflow using the -r command. This basically means :
"Try to rebase (merge with fast-forward) this (feature) branch on top of develop. Only if possible and if there is only one commit on it."
This means that in my specific use case shown above it fails because there are 2 commits on my feature branch. If they were 1 then the rebase works. I'm not really a fan of this as I believe gitflow should FF even when more than 1 commits or at least expose this choice to the user (sourcetree could then expose this up to the GUI).
Hope it helps anyone coming here.
Apparently these questions are on the same topic - https://answers.atlassian.com/questions/78589/git-rebase-instead-of-merge-option-in-the-merge-dialog-does-not-seem-to-work-correctly - https://answers.atlassian.com/questions/211371/rebase-git-flow-with-fast-forward
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.