Git is a Distributed Version Control System (DVCS).
The main difference with VCS is its distributed form, which means that
there is not a single repository centralizing all the code history.
All the code history is in each repository, which means that you have all the history in your local repository as well as in the others.
Git works like the following figure:
For more information how to use Git, please visit the Git Reference web site.
Silverpeas is a free and libre project that values meritocracy.
In code we believe!
As we switched to the Git distributed source control system, we heavily blured the distinction between official project developers and external contributors. This makes it easier for you to:
For information, Silverpeas is made up of the following projects, each of them with their own Git repository:
Once the fork completed, clone it:
git clone URL_OF_THE_FORK
Your fork is then referenced by your git configuration with the name origin
In order to keep your fork up-to-date, you will have to pull modifications from the Silverpeas repository. Thus, you
have to add a remote repository to your git configuration linking your local repository to the Silverpeas one. The
recommended name (used afterwards in he documentation) is
To add a remote repository to your local, execute the following command:
git remote add silverpeas URL_OF_SILVERPEAS_REPOSITORY
git remote add silverpeas firstname.lastname@example.org:Silverpeas/Silverpeas-Core.git
To synchronize your local repository with Silverpeas, we recommend to execute the following command:
git pull --rebase silverpeas master
Or to be less confusing by unexpected merge conflicts, you can divide the synchronization in two steps:
git fetch silverpeas master git rebase FETCH_HEAD
The rebase operation while synchronizing your local repository with Silverpeas is to ensure your changes will be on top of the fetched modifications and hence they won't be mixed with external commits. By doing this, when we'll merge your changes, the history of Silverpeas changes will be clean and understandable.
We use the maven build tool to manage the build life-cycle of our projects. With Maven, a project is described by a POM (Project Object Model) that is defined in the pom.xml file at the root of the project. Maven provides at least the following features:
Before building your copy of a Silverpeas project, you have to define some settings to Maven like indicating our own Maven repository. For doing, please edit a file settings.xml in the .m2 directory at your home folder and add the following lines:
<?xml version="1.0" encoding="UTF-8"?> <settings xmlns="http://maven.apache.org/SETTINGS/1.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 http://maven.apache.org/xsd/settings-1.0.0.xsd"> <mirrors> <mirror> <id>silverpeas</id> <mirrorOf>*</mirrorOf> <url>http://www.silverpeas.org/nexus/content/groups/silverpeas/</url> </mirror> </mirrors> </settings>
Once done, you are ready to build the project:
mvn clean install
or without running the tests:
mvn clean install -Dmaven.test.skip=true
In order to build the Silverpeas application, you have to build first Silverpeas-Core and then Silverpeas-components. If you have modified Silverpeas-Parent, you have to compile first this project before anything.
In the case you have added a new application, you can reference it into the POM of the Assembly-Silverpeas project.
Beside the unit and integration tests, you can test functionally your code in Silverpeas by installing it with your changes.
The project Silverpeas-installer-package is the source code to generate the Silverpeas installation archives for both Windows and Unix-like systems. You can also build it by executing the following command:
mvn clean package
and the archives will be generated into the target directory of the project. Then just extract it, set correctly the environment variables SILVERPEAS_HOME and JBOSS_HOME and follows the instructions in the Silverpeas installation page.
Once done, you are ready to run Silverpeas either in debugging mode or in a normal mode to test it:
to run Silverpeas in normal mode in a Unix system,
to run Silverpeas in debugging mode in a Unix system.
Now that you have your own repository, let's create a branch to develop some code in it. The branch name should reflect the development feature or bug you are working on. It exists two main ways to handle the local and remote branchs with Gits.
The first approach is to create the branch in local, then pushes it to the fork and sets the local branch to track the remote one:
git branch BRANCH_NAME git push origin BRANCH_NAME git branch --set-upstream BRANCH_NAME origin/BRANCH_NAME
The second approach is to create the branch in your fork, then creates from it a local branch that will also track it:
git push origin master:refs/heads/BRANCH_NAME git branch --track BRANCH_NAME origin/BRANCH_NAME
or to create remotely a branch from another one:
git push origin EXISTING_BRANCH:refs/heads/BRANCH_NAME git branch --track BRANCH_NAME origin/BRANCH_NAME
Now you can switch your working directory to the branch you have created (id est checkout the branch):
git checkout BRANCH_NAME
When all your modifications are commited, it is time to push them to your remote branch.
Now that your development is ended, you may want to integrate it into Silverpeas.
To do this we take advantage of Github's "Pull Request" feature.
On receiving your pull request, the Silverpeas core team will look into it and may give you some remarks.
When your code is accepted it will be merged into Silverpeas master branch and you will be informed of this.
Don't forget to synchronize both your repository and your fork with Silverpeas's in order to be up to date. We'll be pleased that you do it before any pull requests.
git checkout master git pull silverpeas master git push
Your development branches for the integrated code are now obsolete, so you may want to delete them.
git push origin :BRANCH_NAME git branch -D BRANCH_NAME