New link for repository
The official git repository has been moved from
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 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.
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 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.
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.
We will make periodic tags on the master branch to signal important stages of the development.
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:
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