Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:59161
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.161.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <4F6F8862.70500@sugarcrm.com>
References: <CAAAa2shEWhNfUzah8zSY379doK0qG7mWnLgs8Did9Wh12n_5rg@mail.gmail.com>
 <4F6F8862.70500@sugarcrm.com>
Date: Mon, 26 Mar 2012 04:02:16 +0500
Message-ID: <CAAAa2sj4qqq_gx=1WWMEiqPj0Pws+b1J_zAK0B68X9zs2=cawA@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Adopt GitFlow process
From: confik@gmail.com (Alexey Shein)

26 =D0=BC=D0=B0=D1=80=D1=82=D0=B0 2012=C2=A0=D0=B3. 2:04 =D0=BF=D0=BE=D0=BB=
=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Stas Malyshev
<smalyshev@sugarcrm.com> =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:
> Hi!
>
>> There was a discussion recently on IRC that our current git working
>> process is not perfect (especially about keeping one branch-only
>> bugfixes) so that's a
>
> One thing with discussions on IRC is that nobody except those present
> there can neither participate nor know what was talked about. And since
> we have timezone differences and other stuff going on in our lives, that
> means, on my estimate, a substantial percentage of the people here
> wouldn't know anything about what was discussed. Thus, it would be
> useful to explain what exactly is the problem we are talking about.
>

Main problem is that our current workflow doesn't allow branch-only
changes. I.e. if you make a bugfix and want to stay it in PHP-5.3 only
you can't merge 5.3 with 5.4 anymore, otherwise your bugfix will go
there.
After some thinking it seems that GitFlow doesn't solve this problem
since it's based on merging :), so let's postpone its presence here
for a while.
What can we do here:
1) use cherry-picking in one repo. This has big downside (as dsp
pointed) that we can't use git annotate, bisect and other commands
assuming that commit is introduced in repository only once.
2) Simplify code that way so we won't need one-branch only changes,
can't say anything concrete here since I'm not familiar with PHP
internals at all.
We still need a better solution here.


>> If you're not yet familiar what is that, please read
>> his wonderful article =C2=A0 http://nvie.com/posts/a-successful-git-bran=
ching-model/
>> another wonderful article about the gitflow tool
>> http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flow/
>
> This is a nice process, however I'm not sure how it could apply to PHP.
> Could you outline what will be done in this case when we have:
> 1. A bugfix for 5.3

Okay, since I'm not too familiar with release process, assume
following (please, correct me if I'm wrong):
* PHP 5.3 can't have features, only bugfixes
* PHP 5.3 can have bugfixes that are merged upstream (PHP-5.4 and
master) and bugfixes that should stay only in PHP-5.3
* PHP-5.4 and master can have bugfixes and features that are merged
upstream (master) and bugfixes/features that should stay only in
current branch
* All branches are have regular releases

Advantage of git flow is that your development process becomes more
straightforward, you can concentrate on development then on merging
bureaucracy.

In gitflow you have 4 branches:
* master - contains only production ready releases, nobody commits here dir=
ectly
* develop - main development branch, all work usually is get merged here
* feature/<name> - feature/bugfix branches for separate bugfixes and
features. Merged into develop.
* hotfix/<name> - same that feature branches but is urgent and is
always merged into master *and* develop. For example, when security
release is issued, this fix should go into release and into main
development branch.
* release/<name> - pre-release stability branches, for bug-fixes only.
Merged into develop and master (making a new release). When you have a
release branch, you can't commit into develop (so hotfixes go here
too, if we have release branch).

That's canonical git-flow. We obviously will need several master and
develop branches, since PHP release branches need own development and
can't be merged in each other. That's not yet implemented and needs to
be done in git-flow.

So you want to make a bugfix in 5.3 that will be merged upstream

Make a bugfix in 5.3
$ git flow feature start bugfix PHP-5.3 # create a bugfix branch based on 5=
.3
<hack> ... <check> ... <test>
$ git add && git commit
$ git flow feature finish -k bugfix 5.3-develop
Bugfix get merged into 5.3-develop - this should be implemented since
gitflow supports only 1 develop branch for now. -k says to keep branch
after finish, since we'll need it to merge upstream

Merge bugfix from 5.3 repo to 5.4
First, rebase branch against 5.4
$ git rebase --onto develop-5.4 bugfix~<num> bugfix
Where <num> is number of commits in your branch. I know it sucks, but
that's how it works :)
Or you can git cherry-pick each commit, (simpler solution anyone?).
Now your bugfix branch is rebased against  5.4-develop and ready to be merg=
ed
$ git flow feature finish -k bugfix 5.4-develop

Repeat the same for master:
$ git rebase --onto develop-master bugfix~<num> bugfix
$ git flow feature finish -k bugfix master-develop

Push changes:
$ git push

> 2. A bugfix for 5.4
> 3. A feature addition for 5.4
Same as above. Since all work is done in branches there's no
difference between bugfixes and features.

> 4. A release of 5.3.x

$ git flow release start 5.3.58
<bump version number now>
<prepare NEWS, UPGRADING and all that stuff>
$ git flow release publish 5.3.58 # publish (push to remote repo)
release-branch. It's not finished yet!
When release is ready you do
$ git flow release finish 5.3.58
Release get merged into 5.3-develop and 5.3-master, creating a tag
5.3.58 in 5.3-master

> 5. A release of 5.4.x
> 6. A release of 5.5 and 5.5.x

Same as 5.3

> Also, what would happen if bugfix/feature is contributed via github pull?

As soon as contributed bugfix/feature uses described process - nothing
really changes. You pull contributed branch locally and act like it
was yours.

>> Personally, I see migration from current setup that way so each
>> release branch (PHP-5.3, PHP-5.4 and master) becomes a separate
>> repository with adopted gitflow model (although it should be thought
>> through more carefully).
>> What do you think about that?
>
> I do not think it makes sense to keep the code in separate repos, given
> that about 90% of the code is the same. It also will make much harder to
> accept outside contribution - I'm not sure how easy would it be to merge
> a patch into three repos from one pull req.

Maybe, it was just an idea to throw into the air.

--=20
Regards,
Shein Alexey