Re: git commit workflow for ofbiz

[Michael Brohl]

Hi everyone,








Makes sense?

Best regards,

Michael



Am 23.01.19 um 07:37 schrieb Jacopo Cappellato:

thank you all for your feedback. It seems that we have consensus to switch over to Git. I'll prepare a Wiki page to start documentation on the processes and the needed steps to make the switch. I'll take over the topics mentioned in this thread (Taher's initial proposed workflow, Jacques notes about build scripts, auto-props etc.). We should then finish the process description, maybe discuss and decide upon and then plan the technical switch.

+1 for Git!

Jacopo

On Sat, Jan 12, 2019 at 1:01 PM Michael Brohl <michael.br...@ecomify.de>
wrote:

Hi all,

I'd like to revive this discussion again.

Personally, I am now working with git for a few years and almost all
customer and company related projects have moved to git over time. In
the beginning, I found git complicated and less straight forward, a bit
like Adrian mentioned in [1]. But once I have understood the main
principles and get used to it, I won't like to switch back to svn ever
since.

In my opinion, using git would make things much easier for
collaboration. Taher thoroughly described them in the inital thread
message.

An important point for me would be that we could prevent premature
commits just to get things to be tested. Features which take some time
to be worked on or tested can be in separate branches which can be
updated with the main branch constantly.

So, from my point of view, we should again have a disussion and/or vote
to see if the overall opinions have changed and if we could move to git.

Thanks,

Michael


[1] http://markmail.org/message/m4z5b5qevqx7n6u7

Am 24.10.15 um 10:23 schrieb Taher Alkhateeb:

Hello Everyone,

I refer to the discussion about moving to git initiated by Hans Bakker

back in April. After a long, long discussion followed by a vote the
community agreed that we should develop a more elaborate and formal
workflow to vote on, as the initial vote was not detailed enough. Based on
that, I have proposed a workflow to see if people are interested in it. But
the topic just slowly died out.

The links to both threads are listed below. I understand that there was

a lot of interest in the community as the thread was really long. I would
like to revive the discussion and see if people are still interested in
implementing / amending the proposed workflow if they find it appealing.

discussion and vote thread :

http://ofbiz.markmail.org/message/ldo77qz34kte4gat?q=move+to+git+from:%22Hans+Bakker%22+list:org.apache.ofbiz.dev&page=1

workflow proposition thread :

http://ofbiz.markmail.org/message/nkthnbsgt37orynu?q=git+commit+workflow

Taher Alkhateeb
----- Original Message -----

From: "Taher Alkhateeb" <slidingfilame...@gmail.com>
To: dev@ofbiz.apache.org
Sent: Wednesday, 24 June, 2015 5:25:31 PM
Subject: Re: git commit workflow for ofbiz


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

smime.p7s
Description: S/MIME Cryptographic Signature