The OPS4J
project is lending us a hand for the infrastructure. But Qi4j have decided to move to use Git instead of Subversion, as its collaboration model seems more suitable for us than the shared trunk model of Subversion.Git is also flexible enough to provide a perception of a Subversion-like model, by allowing us to publish a "Public Access Repository", which is a central authoritative source for users and developers. Initially, it will work very similar to the Subversion style of development, but over time we will probably gradually shift to more flexible development.
Public Access Repository
To check out the "Public Access Repository",which is called creating a "clone" in Git terms, you need to issue the following command;
git clone git://dscm.ops4j.org/<repository>.git
where <repository> is one of the following;- qi4j-core
- qi4j-libraries
- qi4j-extensions
- qi4j-tests
- qi4j-tutorials
- qi4j-samples
- qi4j-tools
- qi4j-ide
- qi4j-sandbox
Web Access
GitWeb is installed and allows people to browse the commit history and content via a regular web browser. The URL for GitWeb is currently;
http://dscm.ops4j.org/git/gitweb.cgi
Committer Access
Qi4j has a 3 level committer access system. The groups are "Core", "Platform" and "Community" and the roles are very clear.Core Developers
These are the guardians and stewards of the core technology and ultimate rulers of what is going on. The hope is that a small group of benevolent dictators will manage to make Qi4j the best platform out there, and not listen in on the voices of features and changes that derails the vision and principles of Qi4j.Platform Developers
These form the work force of Qi4j. They will work on the Extensions, Libraries and IDE, which eventually will make Qi4j the most efficient way of programming in Java.Community Developers
People who are interested in helping out with Qi4j will be granted commit rights to Sandbox, Tests, Tutorials and Samples. This will gauge their abilities and commitment to the project, with an aim to make them Platform Developers.How to Join?
To become a Community Developer, just subscribe to the qi4j-dev@lists.ops4j.org mailing list and request it. With that request, send along your public SSH key, containing your email address as the comment. For instance, you can generate such key;
ssh-keygen -t dsa -C myname@mydomain.com
How to get Access to the writable central repositories?
Once you have commit access to a repository, you will access it differently. This is the clone command needed;
git clone git@dscm.ops4j.org:<repository>.git
Again, the <repository> refers to one of the repositories listed above.You can also change the remote origin of the previously checked out Public Access Repository to the Writable Repository by;
git remote rm origingit remote add origin git@dscm.ops4j.org:<repository>.gitgit push origin master
in case you have evolved the Public Access Repository with your own stuff.The central repository should not contain any branches. If branches are found, they might be removed. And we encourage people to work on branches locally, and exchange work directly between individuals and so forth. If strong desire to have additional repositories for collaboration is forwarded to qi4j-dev@lists.ops4j.org mailing list, it will be considered.
This model also allows people to be working on qi4j-core, and only need to share the work directly with one of the Core Developers, and if he/she approves it, it will enter the codebase.
How do I do my first commit?
We strongly encourage people to read up on Git basics at for instance kernel.org. But some basic commands are discussed here.
shows you what has not been committed.
all files(!) must be added. Directories are not considered and generally ignored. You can add with wildcards, even if some files have already been added.
git commit -a -m "<some message>"
This commits the current branch to the local repository. The -a means commit all files, and not only the ones that are explicitly mentioned on this command. The message should be informative as it will follow the patch 'forever'.
Pushes the local commits back to the 'origin', i.e. the place the clone came from, or to the location that you have moved the 'origin' to be instead (see above).
Pulls/downloads the changes of the 'master' branch from the 'origin' of your local clone. In subversion terms, this roughly corresponds to a 'svn update'.
Shows which branch we are working on.
git branch my_fancy_branch
Creates a new branch with the given name, unless one already exist. Note that the 'current branch' doesn't change to the new one as a result of this command. Instead, you need to;
git checkout my_fancy_branch
which checks out a branch. In reality this means that any local changes in the current branch are also 'moved along' to the new branch. And if those changes are then committed in the 'my_fancy_branch' and one switch back the changes are not there, now sitting in the 'my_fancy_branch' only. This is very handy if one forgets to create and move to a branch before modifying the 'master' branch.
git checkout -b my_fancy_branch
The above is the equal of creating a branch and checking it out, in one maneuver.