Re: Branching workflow

3 messages, 2 authors, 2016-06-15 · open the first message on its own page

Re: Branching workflow

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:59:22

Javier Domingo [off-list ref] writes:

               
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.

Re: Branching workflow

From: Javier Domingo <hidden>
Date: 2016-06-15 22:59:22

I will start to rebase all feature branches because I have no real
dependency on those, but master needs to have a linear history, as I
build from it regularly, and I need to assure that people can get a
previous version of master.

The problem with that is that I wouldn't be able to have a linear
history on master. I had also thought about doing a snapshot branch of
the integration branch, so that I could maintain history of
integration, and just update it with integration snapshots, but I am
trying to get another more git-ish way to achieve all these
requirements of all branches (they are really driving me crazy).

Thanks a lot for the idea. I will mantain clean feature branches from now on,

Javier Domingo Cansino

Re: Branching workflow

From: Javier Domingo Cansino <hidden>
Date: 2016-06-15 23:02:34

Hello!,

I have been using this workflow you suggested, and I happen to find it
really good fitting in many projects I am.

I would like to seek for a little more advice. I keep rebasing all my
work each time master branch is updated, and I would like to know if
this is usually done or not.

The workflow is not using emails, but each developer has his clone
where he works, and occasionally sends work to the gerrit tool we use,
upgrading the patch with each master update.

I know this is a crazy workflow, and I would like to know when you
usually consider to update the sent patch with a rebase.

Cheers,

-- 
Javier Domingo Cansino
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help