Javier Domingo <javier...@gmail.com> writes:
> 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.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html