Hi Leo, I am afraid the answer is too generic. We'd better look into details to see what's the exactly problem.
So I am trying to sort it out. The first question we want to ask is: A. What's current develop process? I don't know where is it documented, but as I know, it works like this(please correct me if I am wrong) 1. Development happen on MASTER first. - Can merge feature branch. 2. Feature freeze, cut staging release branch. No major feature can be checked in. - Say we would release 4.4, then RM create branch 4.4. - All the major feature would be worked on MASTER. - All the fix for 4.4 need to be applied on 4.4, and MASTER. 3. Code freeze. Branch out staging tree, try to enforce quality. - RM branch 4.4-forward from 4.4 branch. - 4.4 branch freezed, only allow to be checked in by RM. - Any 4.4 bug fix need to be applied on 4.4-forward, and after all the test and check, developer would ask RM to cherry-pick it to 4.4 branch. RM would be the gate keeper for 4.4 branch. - In the meanwhile, MASTER would still serve as unstable tree for next release. 4. Release. Release branch would be release. - Release based on branch 4.4, then dropped branch 4.4 - 4.4-forward branch would be rename to 4.4, and continue to serving as release base for 4.4.1 release. 5. For release of 4.4.1 and after. Repeat step 3 and 4(probably not strictly in fact). For release of 4.5. Repeat steps 1-4. The issue with current development process? 1. Cherry-pick is needed for RM to choose stable fix commit after code freeze to enforce quality. 2. Bug fix to current release branch need to be checked in both release branch and MASTER. 3. I believe there would be more. Please comment. B. What's the purposed process. The idea of gitflow is from http://nvie.com/posts/a-successful-git-branching-model/ To my understanding, compare to our current process, it suggested: 1. Develop branched out from MASTER branch, which would be what's majority of work happens on. - Develop branch can merge feature branch. - MASTER would always be stable. 2. Feature freeze: Create Release branch: When ready to release, branch out Release branch from Develop branch. - Release bug fixes only happen on Release branch. - Develop branch need to constantly merge Release branch for latest bug fixes. - In the meanwhile, Develop branch can still merge feature branch. 3. Code freeze: No such concept in the flow. Need to know how to guide the check in. 4. Release. Release branch merge into MASTER. Tagged and release. 5. The original post didn't mention minor release. I suppose it may work like this: 1. Branch out MASTER to 4.4 release 2. Any bug fixes happened on 4.4 need to be merge to MASTER. 3. But, how to fix a 4.4 bug in 4.5's minor release? Seems what's needed is MASTER merged 4.5 which merged 4.4 which merged 4.3. And how can we fix it in develop branch(which meant for test)? I can't see how you can avoid cherry-pick or extra commit if you want to have a maintenance release. Before realizing the maintenance release issue, I was quite like this approach, which means no more duplicate work need to be done. But sadly the most usage for cherry-pick is due to we need to fix multiple versions. Current I can't see how utilize gitflow or git merge would solve the issue. Is there a better way to handle this? And, I think gitflow model doesn't have "code freeze" period which we can have a gatekeeper to keep the quality. So, if we want to compare to gitflow model, we would simply skip "code freeze" stage in our current process. I don't think it make much sense. I think all gitflow has is eliminate one time check in for fixing current release branch(we need to check in both release branch and master branch) compare to our current process, but: 1. How would it handle maintenance release? 2. How would code freeze work? 3. How about the workload for merge between release and develop branch? It would be quite frequently. As a developer, I hate multiple branches check in as much as anyone else, probably even more. But I am not sure gitflow can help us here. Btw, that no-cherry-picking( http://www.draconianoverlord.com/2013/09/07/no-cherry-picking.html) article has a mistake in it. The result it's showing in fact shows that git cherry -v DID recongize the cherry-pickup result by showing "-" in front of the commit. I guess git is smart enough to know that. Here is the manual of git-cherry. SYNOPSIS git cherry [-v] [<upstream> [<head> [<limit>]]] DESCRIPTION Determine whether there are commits in <head>..<upstream> that are equivalent to those in the range <limit>..<head>. The equivalence test is based on the diff, after removing whitespace and line numbers. git-cherry therefore detects when commits have been "copied" by means of git-cherry-pick(1), git-am(1) or git-rebase(1). Outputs the SHA1 of every commit in <limit>..<head>, prefixed with - for commits that have an equivalent in <upstream>, and + for commits that do not. --Sheng On Tue, Jul 29, 2014 at 12:52 AM, Leo Simons <lsim...@schubergphilis.com> wrote: > On Jul 29, 2014, at 5:45 AM, Sheng Yang <sh...@yasker.org> wrote: > > I am trying to catch up, by reading the thread and checking what's > gitflow > > etc, but could someone already familiar with the topic give an overview > of > > the issue? > > > > For example, we can start by asking these questions: > > 1. What's the issue with current development process? > > Right now it is quite hard to get to a stable release, or to produce high > quality contributions, and this happens in part because of the git workflow > in use. > > Cherry-picking is an approach where git can provide 0 assistance with > branch and merge management. Read > http://www.draconianoverlord.com/2013/09/07/no-cherry-picking.html > for an introduction to that subject, for example. > > > 2. What's the purposed new approach to the process? > > To use a branch/merge workflow rather than a cherry-pick workflow, > preserving commit ids across branches. > > To adopt a specific well-documented workflow called git-flow that has tool > support. Read > http://nvie.com/posts/a-successful-git-branching-model/ > for an introduction to git-flow. > > To then tune this workflow to cloudstack. In particular, so far, I’ve noted > * not deleting release branches once releases are finished > * consider using support/ branches for point releases rather than hotfix/ > branches > > Note that this new workflow implies a variety of things, including: > * sharing responsibility for merges among many committers (as opposed to a > release manager responsible for cherry picking) > * distributing the ‘merge pain’ throughout the development process as > features finish up (rather than ‘big bang’ during release time) > > > 3. What's the pro/con of the new process? And what's the pro/con of the > old > > one? > > This is very difficult to summarize fairly. > > IMHO the only advantage of the old process is that it is what everyone > knows already. It’s main downsides are that it is not using git’s excellent > branch management features, does not allow comparing or merging between > branches, requires contributions to be re-written for multiple branches, > and encourages developers to ignore merge conflicts until release time. > > IMHO any workflow that does not rely on cherry-picking has only advantages > compared to the current process. > > Git-flow has many people that like it and many people that don’t. But, the > people that don’t like it usually use another branch/merge model, not > cherry-picking. It’s main advantages among available branch/merge workflwos > are being well-defined, oft-used and tool-supported. > > > That would make the question much more clear. > > Hope this helps, > > > cheers, > > > Leo > >
