Re: Branching PHP6

From: Date: Sat, 05 Apr 2014 07:30:08 +0000
Subject: Re: Branching PHP6
References: 1 2 3 4 5 6 7 8  Groups: php.internals 
Request: Send a blank email to internals+get-73602@lists.php.net to get a copy of this message
On Sat, Apr 5, 2014 at 12:19 AM, Alexey Zakhlestin <indeyets@gmail.com>wrote: > > On 05 Apr 2014, at 10:00, Stas Malyshev <smalyshev@sugarcrm.com> wrote: > > > makes it a nightmare to read. Furthermore, there's simply no need to > have > >> an ever-increasing number of dead branches that lead nowhere and never > >> merge back. If somebody wants to find a specific version, that's what > tags > > > > Branches are dirt-cheap in git, so dead branches is not a problem. > I disagree. When you have far more dead branches than active ones, with the gap only widening as time goes forward, it becomes increasingly difficult to quickly locate active branches of development. There's simply no reason to leave dead branches out there when quick access to past versions can be achieved through tags, which we're already doing anyway. > Also, > > the only dead branches are supposed to be release branches and very > > rarely feature branches, all the rest should be done in private branches > > and submitted as pull request. > In ideal Git workflow, release branches should never lie dead like this. Instead, they are merged back into the trunk branches-- no fast forward to preserve history-- and deleted. Tags are used to enable users to quickly go back to key points in history; i.e. version releases. Regarding RM control, the workflow I've suggested would not disrupt that at all. The RM would still have full control over what goes onto the release branch and when, as well as where and when tags are applied. But in this scenario, once the lifecycle of that release is over, the release branch is merged back in one last time and deleted. The history is preserved but it doesn't leave a dead branch. If we had been using this approach to-date, we'd have just a few branches instead of, well, dozens, most of which are defunct and no longer serve any purpose except to clutter. > The usual git workflow which I've seen in the wild is: > > 1. release branch is created > 2. release-specific commits are added > 3. tag (optionally signed) is created > 4. branch is removed > > In case development has to be restarted (for hotfix-patch), new branch is > created from the tag-point. > > The advantage is, that "branches" represent points of active development > and tags represent history. That's essentially correct. What we're doing right now is having more and more branches created to represent points of development that are no longer active. That is, in fact, exactly what tags are for in Git. --Kris

« previous php.internals (#73602) next »