[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [bpel-dev] Thoughts about how to use Git [Forked from "Upgrade in the BPEL creation wizard"]

Of course, you are correct Mickail, I forgot that Vincent has committer rights. My apologies but my head has been pulled in several different directions lately ;)
I'll post your commects to the BPEL wiki.

________________________
Robert ("Bob") Brodt
Senior Software Engineer
JBoss by Red Hat


On 14/09/2011 22:54, Bob Brodt wrote:
Hi again Vincent,

Your question about GIT process is a good one, and one that I'm not prepared to answer ;) But, it seems that GIT is all about branches (the more the better, apparently) and each bug fix should be done in its own branch. And, SOMEbody is ultimately responsible for merging the branches back into master...and that SOMEbody seems to be the project manager, which <sigh> is me :( So...go ahead and push your branch to git.eclipse.org and I will merge these changes into master.
I think that, as a *committer*, Vincent has the necessary credentials to push his commits directly to the master branch, and to merge branches into the master branch. For bug fixes and so on, it is convenient to have directly a local clone of the master branch and push changes directly onto it.
For more "experimental" stuff (that is not intended to get *immediatly* into the product), a good practice is to create a new branch - at git.eclipse.org when possible - push changes on that branch, and when to stuff gets ready to get into the product, merge this "experimental" branch into the master. During the development, it is convenient to merge the master into the experimental quite often (it is like performing an update on this branch).

IMHO, to sum it up:
* For committers
-> Create a clone of the repo, locally fork the master branch.
-> For bug fix, directly push in the master
-> For new features, create branches on git.eclipse.org, push changes on that branch, and merge experimental branch into master branch when ready. Having a presentation of the feature on the mailing-list before merging could be a good practice.
* Contributors, Non committer
-> Create a local clone of the git repo, locally fork the master branch
-> For bugfix & features
-----> either make changes on the local branch and ask pull request. A committer would be responsible of pulling the branch
-----> either publish a branch with the bugfix on a remote repo (such as GitHub). A committer would be responsible of merging the contributor branch into the master@xxxxxxxxxxxxxxx

If you are OK with it, it is probably worth putting this in the wiki, for both contributors and committers.


[Somebody please remind me again why GIT is better than svn...?  :'( ]
Some ideas:
- Contributors can work in a more "autonomous" way.
- It keeps a better history of different contributors (just see the authors of the last commits, merge and pull preserves real author)
- Facilitating forking helps projects to "explore" different path

But I think everybody agrees that it is a bit complicated to get into Git when you are used to SVN. It just requires time to get familiar with it.

Regards


--

Mickael Istria
R&D Engineer, Eclipse Plug-in RCP Developer

PetalsLink - Open Source SOA

My blog - My Tweets


_______________________________________________
bpel-dev mailing list
bpel-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/bpel-dev