Git workflow

[Omer Katz]

Right now besides tagging we don't really have a workflow and that prevents us from developing two releases in parallel (0.x & 1.0.0).
I suggest to use the git-flow extension.

It will require us to extend the Contributing documentation a bit but I think it's worth it.

What do you guys think?

[jason pellerin]

Good idea. If we're going to build on multiple release tracks, feature branches and tagging won't be enough. I haven't tried gitflow myself, but it seems sensible enough.

--
You received this message because you are subscribed to the Google Groups "nose-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nose-dev+u...@googlegroups.com.
To post to this group, send email to nose...@googlegroups.com.
Visit this group at http://groups.google.com/group/nose-dev.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[John Szakmeister]

On Fri, Jul 19, 2013 at 10:19 AM, jason pellerin <jpel...@gmail.com> wrote:
> Good idea. If we're going to build on multiple release tracks, feature
> branches and tagging won't be enough. I haven't tried gitflow myself, but it
> seems sensible enough.

I'm not sure I understand. If you intend to support old releases,
git-flow is antithetical to that. It wants to see all releases made
from master. How would that work with releasing 1.2.0 and then
turning around to release 1.0.1 and 1.1.1--or something similar?

I think it'd be much better to have release branches, if you need to
backport a fix, and to tag from those release branches. I think when
it comes to making your next great release, just tag from master like
you have been.

If you don't intend to support old releases, then this is all moot and
git-flow will work fine. :-)

-John

[jason pellerin]

I thought git-flow had release branches?

[John Szakmeister]

On Fri, Jul 19, 2013 at 11:34 AM, jason pellerin <jpel...@gmail.com> wrote:
> I thought git-flow had release branches?

It does, but you tag the merge commit on master:
<http://nvie.com/posts/a-successful-git-branching-model/>

-John

[Omer Katz]

Can you explain again what's wrong with git-flow more elaborately?
What should be our workflow then?

[John Szakmeister]

On Sun, Jul 21, 2013 at 2:26 PM, Omer Katz <omer...@gmail.com> wrote:
> Can you explain again what's wrong with git-flow more elaborately?
> What should be our workflow then?

The problem is that git-flow uses master as a deployment branch.
You create your release branch from develop, get it polished and
ready, and then merge it to master, tag it, and release it. The
master branch then becomes the very serial location from which to
deliver your actual release, and that's the crux of the problem.
Let's say you have this:


develop: ---*---*-------*
\ /
release-1.1.0: *---*---*
\
master: -*-------------*----
1.0.0 1.1.0


So, master is at version 1.1.0. Then you discover an issue that's
going to require you to make a couple of patch releases: 1.0.1 and
1.1.1. 1.1.1 would go well, since it's next in line from 1.1.0:


develop: ---*---*-------*-------*--
\ / /
release-1.1.0: *---*---* /
\ /
hotfix: \ *
\ / \
master: -*---------------*---*---
1.0.0 1.1.0 1.1.1


So now the current state is 1.1.1. But what about 1.0.1? You
wouldn't want to actually merge 1.0.1 to trunk and tag it. That
would mean master would be some combination of the content from
1.1.1 and the fix made for 1.0.1.

In other words, this would be bad:


develop: ---*---*-------*-------*--
\ / /
release-1.1.0: *---*---* /
\ /
hotfix: \ *
1.0.0 \ / \ 1.0.1
master: -*---------------*---*-------*
\ 1.1.0 1.1.1 /
hotfix: '-----------------------*


You really want this:


develop: ---*---*-------*-------*--
\ / /
release-1.1.0: *---*---* /
\ /
hotfix: \ *
1.0.0 \ / \
master: -*---------------*---*---
\ 1.1.0 1.1.1
hotfix: *
1.0.1


But that's not the git-flow model.

The other way to approach this is to treat master as your main
development branch and use release branches to do the actual
release. In this model, it would look like this (not lines composed
of dots are cherry-picks, not merges):


master: -*---*---*---*---*---*---*
\ . \ .
\ . \ .
release-1.1.x: \ . '-------*
\ . 1.1.0
\ .
release-1.0.x: '-------*
1.0.0


Then a patch release would look something like this:


fix for backport
|
v
master: -*---*---*---*---*---*---*---*---*....
\ . \ . . .
\ . \ . . .
release-1.1.x: \ . '-------*-------* .
\ . 1.1.0 1.1.1 .
\ . .
release-1.0.x: '-------*---------------------------*
1.0.0 1.0.1


You can still use feature branches for development (and I encourage
it!), and I'd add one caveat there: make sure when the feature
branch is merged that it's not a fast-forward merge (git merge
--no-ff). This makes it easier to revert a feature from the master,
in the event something doesn't work out well. This sort of strategy
allows some of the flexibility of git-flow:

* Use of feature branches.
* Have a release branch to stablize for the release, and leaves
master open for more development.

What you lose is the abliity to have master be something that you're
ready to push into production. I think it's a fine tradeoff though.

The only modification to this I would consider is that the first
major/minor release come off of master instead. You'd prevent new
stuff from landing for a bit, but I don't expect that Nose2 will
need much time to vet stability. FWIW, this model is pretty close
to what happens for Linux kernel development and is pretty close to
what I've had my employees at my workplace do for years now.

One thing about this model is that you *never* want to merge the
release branch back into master. If you do, then you can run into
some interesting problems. I've answered one such problem on
stackoverflow:
<http://stackoverflow.com/questions/15807522/why-is-git-log-cherry-pick-not-removing-equivalent-commits/>

I hope all of this makes sense. I apologize for my crude ASCII art
graphics... email is not a terribly good medium for this kind of
graphical explanation.

-John

[jason pellerin]

I like this model better than git-flow -- probably it just matches my brain better, but it does make more sense to me.

-John

[Omer Katz]

Yeah but the whole point is that git-flow automates this process. Do we have another tool that implements this kind of workflow?

בתאריך 22 ביול 2013 17:57, מאת "jason pellerin" <jpel...@gmail.com>:

You received this message because you are subscribed to a topic in the Google Groups "nose-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/nose-dev/MJGGrzo606Q/unsubscribe.
To unsubscribe from this group and all its topics, send an email to nose-dev+u...@googlegroups.com.

[John Szakmeister]

On Mon, Jul 22, 2013 at 11:39 AM, Omer Katz <omer...@gmail.com> wrote:
> Yeah but the whole point is that git-flow automates this process. Do we have
> another tool that implements this kind of workflow?

So, your turn now... can you explain what git-flow automates? It
looks like nearly as much work as using the actual commands to do it.
To answer your command, no, I'd know of anything to help automate this
process.

On another note, it appears they've recognized the deficiency of not
supporting old releases, so they've added a new concept called
"Support Branches", though it's still marked as being experimental
still.

-John

[Omer Katz]

It just automates the naming conventions which is probably a good thing to enforce.

Let's decide on a workflow we're happy with and stick with it.

בתאריך יום שני, 22 ביולי 2013 20:20:50 UTC+3, מאת John Szakmeister:

[Omer Katz]

So I'd like to open new release branches for 0.5.0 and 1.0.0. Should I stick with the release-{version} convention or should I use the release/{version} which is more compatible with git-flow and what other developers are used to (at least from what I've seen).