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

ajsharp opened this Issue Jan 21, 2011 · 13 comments


None yet

8 participants

ajsharp commented Jan 21, 2011

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 commented Jan 21, 2011

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

ajsharp commented Jan 21, 2011

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 "$@"
    warn "Will try to rebase '$NAME'..."
    require_branch "$BRANCH"

    git checkout -q "$BRANCH"
    local OPTS=
    if flag interactive; then
        OPTS="$OPTS -i"
    git rebase $OPTS "$DEVELOP_BRANCH"
nvie commented Jan 31, 2011

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 commented Jan 31, 2011

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 ( 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 commented Jan 31, 2011

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 commented Jan 31, 2011

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

@drock drock pushed a commit to drock/gitflow that referenced this issue Oct 10, 2011
Derek Gallo Added -P flag to optionally pull latest develop branch before rebasin…
…g a feature. Attempts to close #93
@drock drock pushed a commit to drock/gitflow that referenced this issue Oct 19, 2011
Derek Gallo Moved tree and branch verification to top of function before attempti…
…ng to pull latest develop. issue #93
jadb commented Mar 20, 2012

@nvie any plans for merging this pull request?

I think this is a very elegant solution and sounds a lot like

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.

srt32 commented Jul 21, 2015

👍 to updating develop prior to rebasing.

srt32 commented Jul 21, 2015

Also, there seems to be a related issue in #416 (fetching develop before merging).

srt32 commented Jul 22, 2015

Does #416 (comment) 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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment