26 марта 2012 г. 2:04 пользователь Stas Malyshev <smalys...@sugarcrm.com> написал: > 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 >> http://nvie.com/posts/a-successful-git-branching-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 directly * 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 merged $ 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. -- Regards, Shein Alexey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
