Currently git flow feature rebase just updates the current feature branch with your local copy of develop. I think this command should checkout update the local develop branch with origin/develop. Is there any planned support for this (a patch seems like it would be somewhat trivial), or is this a philosophical difference?
No need to checkout and update develop. A simple 'git fech' updates 'origin/develop'
Good point. So git flow feature rebase could do something like the following
git fetch origin/develop
git rebase origin/develop
Currently it does git rebase develop, if I'm reading the code correctly:
git rebase develop
DEFINE_boolean interactive false 'do an interactive rebase' i
warn "Will try to rebase '$NAME'..."
git checkout -q "$BRANCH"
if flag interactive; then
git rebase $OPTS "$DEVELOP_BRANCH"
Actually, rebasing upstream is something you should be very careful about. While there are valid cases where this is useful, there are as many situations where this would lead to potentially very confusing situations.
Imagine the situation where Bob and Alice pulled feature/X from origin. Then, Bob rebases both his local copy and the origin, using your proposed solution. So far, so good. But when Alice doesn't know of the rebase and updates her local copy, things get hairy. If she pulls naïvely, there will be a giant ugly merge commit. If she fetches, she'll have to deal with figuring out the rebase herself. The only "clean" solution for her will be to first fetch, then git reset --hard origin/feature/X her local feature branch.
git reset --hard origin/feature/X
But that will make her lose all her local changes on the branch.
The main reason why automatically rebasing the upstream repos is not done automatically by gitflow, is to avoid this mess. You're generally a good Git citizen if you simply don't rebase after you've pushed out changes. gitflow is no exception to that rule.
Thanks for the helpful and informative response.
I agree published branches should never be rebased to their remotes. I should have been more clear, but I was talking about the somewhat common case where one person is working on a local unpublished feature branch, rebasing along the way, and eventually merging into the mainline branch upon completion. The rebasing along the way part is where I think there's a bit of confusion on what git flow does for you.
git flow feature rebase only rebases to your local copy of the mainline development branch, which I think is a safe default, due to the rebasing a published branch issue you described above. Still, for your everyday, throwaway, unpublished feature branches, I often want a little more automation in a tool like gitflow.
git flow feature rebase
I used to use a modified version of hack & ship (http://reinh.com/blog/2008/08/27/hack-and-and-ship.html) where hack would do the following in sequence (where develop is the name of the mainline development branch):
git checkout develop
git pull origin develop
git checkout feature/<whatever>
I'm always hesitant to add overly complex conditional logic to a tool, but it might be nice to have the option to add a config option to the local git-flow config in .git/config, that enabled a workflow like the "hack" workflow described above when you run git flow feature rebase.
The conditional logic might be, "if the current feature branch is not tracking a remote (i.e. not published), when running git flow feature rebase, update the mainline development branch (i.e. develop) from origin and rebase the unpublished feature branch to that updated version of develop".
Am I making sense here? Thanks in advance.
Oh, so you mean that the command should first pull in new commits from origin into develop before actually rebasing against it locally. Good point! I'll keep this one open.
I've slightly changed the ticket title to better reflect the issue.
Added -P flag to optionally pull latest develop branch before rebasin…
…g a feature. Attempts to close #93
Moved tree and branch verification to top of function before attempti…
…ng to pull latest develop. issue #93
@nvie any plans for merging this pull request?
I think this is a very elegant solution and sounds a lot like http://randyfay.com/content/rebase-workflow-git
Any new work on this issue? I just ran into this today where I forgot to git fetch first. Something like this could really confuse a newbie.