New link for repository

The official git repository has been moved from https://git.cern.ch/reps/geant.git to https://gitlab.cern.ch/GeantV/geant.git

Migration

After you made sure that your work is checked in locally, to move to the new repository you can:

The nice way:

git checkout master
git pull
git remote rename origin old-origin
git remote add origin https://gitlab.cern.ch/GeantV/geant.git
git remote rm old-origin
git fetch
git branch --set-upstream-to=origin/master master
git pull

The “simple” way (but you will lose all the work that you have not yet pushed in!!!)

rm -rf [Directory with GeantV code] 
git clone https://gitlab.cern.ch/GeantV/geant.git
cd geant 
git checkout master

Development policy for GeantV

The policy of development has been redefined as follow:

a) the main development branch is master.

b) all developers in geant-dev have the right to check into master

c) when a developer wants to introduce a small fix, he/she can directly check-in / push as before in master

d) in case of a feature development, the developer should create a branch from master and work on it.

When the work is finished, or regularly, in case of a longer development, the work should be merged back not directly but via a merge request https://gitlab.cern.ch/GeantV/geant/merge_requests that will be vetted (for the moment) by Philippe Canal and Federico Carminati.

In any case, at least once per week, developers should merge master into their feature branch, to make sure that they do not diverge.

Once the merge request is accepted, the corresponding feature branch is deleted.

Merging policy

Merging of master into the feature branch should be done via 

git fetch
git rebase master 

possible conflicts should be solved via the standard git resolution procedure. In case the number of conflicts is unreasonably high, the following can be done.

git fetch
git merge master

here also there can be conflicts, but usually much less.

"Small fixes"

The appreciation of what is a small fix and a feature is left to the developer. However attempts in bypassing the system will result in checkins to be reverted and developer to be asked to resubmit the changes via a merge request.

Feature branches

Feature branches should live as long as needed for the feature to be fully developed and tested, but not beyond, to avoid divergence. Regular merge of master into feature branches is essential to ensure that the merge of the feature into master could proceed smoothly.

Release policy

We will make periodic releases from the master branch. The frequency of these releases is not yet decided and it will depend on the status of the code.

Tagging policy

We will make periodic tags on the master branch to signal important stages of the development.

Gitlab notifications

Gitlab has a personal setting for the communications you receive. Once you login to your git account, you can access it via the following link: https://gitlab.cern.ch/profile/notifications

The GeantV project requires people in geant-dev to set their notification level to "Watch".

Advised links to look before starting to work

Check more about code review procedure via merge request here