incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Omar Gonzalez <omarg.develo...@gmail.com>
Subject Re: What would it take to move to Git?
Date Sun, 12 Aug 2012 07:49:07 GMT
On Sun, Aug 12, 2012 at 12:24 AM, Justin Mclean <justin@classsoftware.com>wrote:

> Hi,
>
> > Why is using a local branch important?
> When using git most branches are local and not shared between developers
> unless it's needed (in my experience anyway). Although it easy to share
> between people working on a large feature - have a look at the IDE dev on
> github and yuo'll see that in action.
>
> > Is this because of a branching strategy or is there something about Git
> that
> > makes this easier?
> Mostly github (easier to branch and merge) but you still need need the
> right branching stategy and as it's easier to branch in git we are likely
> to  have more need to a branch structure/rule than if we used SVN.
>

Not necessarily because of the way merging is handled. The branching
strategy is more about facilitating parallel development as opposed to
trying to avoid merge conflicts, which is usually the motivator in SVN, not
Git.


>
> I've had a deeper look at the gitflow branching structure and before we
> vote on using we might want to think about:
> - What branches are local/what are in the origin repo. Only 2 long lived
> branches in the gitflow model (ie develop and master) are stored centrally.
>

That's correct, as well as tags of Release branches before they're merged
back into trunk and dev, in case we need to perform a hotfix on a released
version.


> - Are we going to have issues with cherry picking fixes from develop into
> master causing unstable releases? May want to consider what Linus has to
> say on the issue on the issue https://lkml.org/lkml/2008/5/21/351 +
> https://lkml.org/lkml/2010/11/12/291. (I do like the idea of stable and
> next branches mentioned in the second email).
>

Well, you wouldn't be cherry picking from develop into master. The only way
code gets into Master is from a Release branch. Release branches are made
directly from Dev. Dev only contains code that has been added to the source
either via a Hotfix branch or a Feature branch. When you're done with a
Feature branch and its time to merge the code into Dev usually an
'Integration' branch is made locally in order to merge the Feature branch
back into the an integration branch that is freshly made from Dev. This is
where you make sure the Feature branch code doesn't break the stability of
Dev, if it does the issues should be fixed in the temporary Integration
branch and then merged back into Dev, at which point you can kill both the
local Feature and Integration branches.


> - Think carefully about the no fast forward option and it's effects. Look
> at comments as it may be being incorrectly being used. Do we want it on by
> default as suggested?
>

I get confused w/ this one, will get back to you on this one. :)

- Do we want release branches to be short lived? Main issue this this is (I
> think) is that's hard to patch issues in previous releases and means any
> serious bug fix allways going the latest release forcing user of the SDK to
> allway be on the latest version. I'm really not sure on this one. However
> note than in Linux development has a stable branch for each release and not
> a master as such ( see development model at
> http://en.wikipedia.org/wiki/Linux_kernel).


> Thanks,
> Justin


This is incorrect. Release branches are short lived, yes. However, before a
release branch is killed off you MUST tag it. The whole purpose of the tag
is to mark the point in time at which the Release branch was done being
worked on and sent to Master. When you merge a release branch to Master its
the equivalent of producing a release, that is why you must tag it
"v.1.0.1". Then you kill the Release branch. If two weeks later a bug that
must be fixed is needed, but new features are already being developed in
Dev, then you create a Hotfix branch from the "v.1.0.1" tag and go to town
fixing the emergency bug. Once that bug is ready to be deployed you can use
it as a release branch to update version numbers, and do all the other
things required for a release, tag it "v.1.0.2", merge it to Master, merge
it to Dev, and destroy the Hotfix branch.

So in short, you can make fixes to any version at any time.


-omar

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message