ofbiz-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Heath <doo...@brainfood.com>
Subject Re: git commit workflow for ofbiz
Date Tue, 12 May 2015 17:28:20 GMT
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,
> 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

View raw message