On 15/09/2011 18:00, Bob Brodt wrote:
Hi Mickail,
Hi Bob,
I think this is fine, but since the page was not linked from
anywhere in the wiki, it was impossible to find it for anyone. Then
I made some improvements to the wiki (inspired by SWTBot and GMF),
to have it more easy to read and to have the info about how to use
Git more accessible (in the "Contributing" area).
________________________
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
_______________________________________________
bpel-dev mailing list
bpel-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/bpel-dev
_______________________________________________
bpel-dev mailing list
bpel-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/bpel-dev
|