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
|