Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

git feature rebase should pull from origin/develop prior to rebasing #93

Open
ajsharp opened this Issue · 9 comments

6 participants

@ajsharp

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?

@snaewe

No need to checkout and update develop. A simple 'git fech' updates 'origin/develop'

@ajsharp

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"
}
@nvie
Owner

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.

@ajsharp

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.

@nvie
Owner

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.

@nvie
Owner

I've slightly changed the ticket title to better reflect the issue.

@drock drock referenced this issue from a commit in drock/gitflow
Derek Gallo Added -P flag to optionally pull latest develop branch before rebasin…
…g a feature. Attempts to close #93
25a6d91
@drock drock referenced this issue from a commit in drock/gitflow
Derek Gallo Moved tree and branch verification to top of function before attempti…
…ng to pull latest develop. issue #93
7d01387
@jadb

@nvie any plans for merging this pull request?

@ifeltsweet

I think this is a very elegant solution and sounds a lot like http://randyfay.com/content/rebase-workflow-git

@justin808

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.