|Re: [bpel-dev] Thoughts about how to use Git [Forked from "Upgrade in the BPEL creation wizard"]|
On 14/09/2011 22:54, Bob Brodt wrote: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.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.
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.
Some ideas:[Somebody please remind me again why GIT is better than svn...? :'( ]
- 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.
R&D Engineer, Eclipse Plug-in RCP Developer
PetalsLink - Open Source SOA
bpel-dev mailing list