Re: Branching workflow

From: Junio C Hamano <gitster@pobox.com>
Date: Dec 3, 2013, 19:12 UTC
Message-ID: <xmqq8uw1oij6.fsf@gitster.dls.corp.google.com>
In-Reply-To: <CALZVapnjN_69y0+PLFA2t8b72WDK+D4BhjDRnRPxU_9iX+_NuA@mail.gmail.com>

Javier Domingo <javierdo1@gmail.com> writes:

Show 16 quoted lines

> Hi,
>
> I have been using a very basic workflow for branching, features each
> in a branch.
>
> My branches would be:
> - develop <= Main upstream branch
> - feature/* fix/*  <= Feature and fix branches
> - master <= Integration of the whole feature and fix branches
>
> So I have now came up with a very difficult task. I just discovered
> that one of those branches, lest call it feature/bad, is evil and is
> making the integration branch (master) fail horribly.
>
> In my workflow, I tend to merge develop (official updates) into my
> feature branches, and them into master.

I think the standard advice is not to contaminate feature branches with unrelated changes, whether from an upstream updates or from other unrelated feature breanches.

You would still want to make sure that your feature branches in work-in-progress state would work with updated upstream from time to time, but that is much better done by having a test integration branch you maintain with:

    : always start from the tip of upstream
    $ git fetch upstream
    $ git checkout -B develop remotes/upstream/master

    : merge everything you want
    $ git merge feature/A
    $ git merge feature/B
    ...
    $ git merge fix/Z

And you will never merge 'develop' into 'master'. Only after you are satisfied with a single feature (or fix), you merge that to 'master', while your other features may still be suspect.