gitflow
gitflow copied to clipboard
nvie
git feature rebase should pull from origin/develop prior to rebasing
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:
cmd_rebase() {
DEFINE_boolean interactive false 'do an interactive rebase' i
parse_args "$@"
expand_nameprefix_arg_or_current
warn "Will try to rebase '$NAME'..."
require_clean_working_tree
require_branch "$BRANCH"
git checkout -q "$BRANCH"
local OPTS=
if flag interactive; then
OPTS="$OPTS -i"
fi
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.
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.
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>
git rebase develop
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 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.
Also, there seems to be a related issue in https://github.com/nvie/gitflow/issues/416 (fetching develop before merging).
Does https://github.com/nvie/gitflow/issues/416#issuecomment-123838927 answer the question?
It seems there are config options for "fetching before local operations".
yeap, just fetch develop before rebasing.
fetch origin develop:develop
git flow feature rebase
git flow feature finish -r foo Finish feature foo by rebase
