Hi Jacques, Very good read, thank you for sharing.
The person who wrote complaining about gitflow (I think Adam Ruka) makes a good point. He prefers linear to branched history. I do not mind branched history myself as I know how to navigate it but to each his own. Either way, The workflow can be accomplished the way he suggested by rebasing rather than merging the history and making a few other changes like dropping "develop". It is up to community to decide, and git is flexible enough to accommodate any model. Taher Alkhateeb ----- Original Message ----- From: "Jacques Le Roux" <jacques.le.r...@les7arts.com> To: dev@ofbiz.apache.org Sent: Wednesday, 24 June, 2015 4:19:42 PM Subject: Re: git commit workflow for ofbiz Le 24/06/2015 14:06, Jacques Le Roux a écrit : > If you get a chance to read these articles I highly recommend them > > http://www.alwaysagileconsulting.com/organisation-pattern-trunk-based-development/ > Of course don't miss http://www.alwaysagileconsulting.com/organisation-antipattern-release-feature-branching/ Jacques > > http://endoflineblog.com/gitflow-considered-harmful > http://endoflineblog.com/follow-up-to-gitflow-considered-harmful > > Jacques > > > Le 12/05/2015 19:28, Adam Heath a écrit : >> Nice. This is quite thorough. There is an option missing. SVN committers who >> use git offline. In this case, their changes can be published as >> primary SVN branches, for collaboration.. See OFBIZ-6271 in JIRA, and as an >> SVN branch, for an example. >> >> I've read through most of what follows, and am in agreement, but I'm dealing >> with hardware problems, so I need to let it sink in first. >> >> On 05/12/2015 04:43 AM, Taher Alkhateeb wrote: >>> Hi everyone, >>> >>> This email refers to the thread for voting to move to git (link at bottom) >>> in which the vote decision was to delay and elaborate on the workflow >>> first. I am not well versed in ASF guidelines and appreciate any help and >>> feedback and also please note some of the below is my opinion and not >>> necessarily 100% factual. >>> >>> ## First, identified problems >>> >>> 1. patches can quickly be outdated if not applied quickly >>> 2. big patches are hard to audit and not desired nor preferred and It is >>> hard to break big patches to smaller ones because if any of those patches >>> is outdated or modified then everything needs to be re-patched >>> 3. to collaborate with other people (non-committers) freely on big >>> features, we need a separate branch. On svn this is lengthy and heavily >>> controlled. If we create a git repository then we need to constantly update >>> from svn and merge . Another solution is to clone the ofbiz read-only >>> git repository but then there are some patch issues to convert them to >>> clean svn patches (I faced a few including things like white space) >>> 4. a lot of _local_ offline freedom to branch, merge, commit, share and >>> experiment cannot be easily done without initiating a local git repository >>> which triggers the other problems identified above. >>> 6. There are too many public branches in the repositoy. Some are not active >>> nor complete and quite old >>> >>> ## Second, how does git provide solutions >>> >>> So, adopting git in relation to the above mentioned problems solves them as >>> follows: >>> >>> 1. even if a patch gets outdated, I can easily recreate it by switching to >>> a branch that I created and has the work (e.g. OFBIZ-12345), merging >>> everything from trunk and re-patching >>> 2. to allow for proper feedback by community, a pull request can replace a >>> big patch and that request can hold an X amount of commits each with >>> its own message and diff details. If changes happen to any of the commits, >>> then reconciling that into the code base is minor, you just branch >>> again, do it, and merge. Furthermore, I suggest to follow the guidelines >>> which recommend rebasing before pushing to a shared repository to keep a >>> nice linear history as much as possible as shown here -> >>> https://git-wip-us.apache.org/docs/committer-practices.html >>> 3. large features can be done in a remote repository in github or bitbucket >>> with pull requests when complete and ready for review. >>> 4. the issue is immediately solved with git which is not only local but >>> much, much faster >>> 6. We do not need to pollute the main repository with branches if we decide >>> on a distributed model like git with remote repositories to contribute >>> to the project with pull requests. >>> >>> ## Third, proposed workflow >>> >>> I will make a distinction between small features / bug fixes and large >>> features. >>> >>> ### small features >>> >>> Small features follow the exact same workflow that currently exists in svn. >>> You do your work, diff it, and attach the patch to a JIRA and request >>> a commit from one of the committers. >>> >>> ### large features >>> >>> For large features usually multiple people need to collaborate on a >>> separate branch. Here is where git shines and the distributed model kicks >>> in: >>> 1. A JIRA is created for a large feature >>> 2. The team (not necessarily having a committer) creates a remote >>> repository which itself may have many branches with the master branch >>> having all >>> the work agreed upon and merged (actually, rebased) >>> 3. The collaboration for this branch happens in the JIRA including >>> discussions, comments, and even links to the commits etc ... >>> 4. A request is made to a committer to make a pull request from the >>> repository after reaching a certain milestone with consensus from the >>> community of course >>> 5. Here, for extra safety, the branch model may have a trunk and a develop >>> branches. Everything is pulled to the develop branch and trickles down >>> to the master branch after thorough and proper testing. >>> >>> The above workflow can also adhere to the now famous Vincent Driessen git >>> branching model found here -> >>> http://nvie.com/posts/a-successful-git-branching-model/ >>> >>> I am not sure whether this proposal is enough or correct so I appreciate >>> your guidance and feedback to fix whatever needs fixing. >>> >>> Taher Alkhateeb >>> >>> original voting thread: >>> http://ofbiz.markmail.org/search/?q=move%20to%20git#query:move%20to%20git+page:1+mid:p62ofojcbb3oyoi4+state:results >>> >>> >> >> >
