3. Git and GitLab
Contribute
Set up Git on your computer such that GitLab can recognize you:
> git config user.name "FIRSTNAME LASTNAME"
> git config user.email "A@B.DE"
in the DAMASK repository or
> git config --global user.name "FIRSTNAME LASTNAME"
> git config --global user.email "A@B.DE"
for a system-wide setup.
development
is the branch that is should always work (and
release
/
master
of course as well)
For any changes, create a new branch named after the feature you're working on (or, contribute to an existing branch).
For new features, create tests.
After finishing working on a brach, test the code.
If it is working, request to merge it into development.
Assign the merge request to one of the developers (that is not you!)
For a small bugfix to the latest commit, use
git commit --amend
Workflow model
In contrast to centralized version control systems such as SVN, their distributed counterparts offer a lot of flexibility in selecting a workflow model.
https://www.atlassian.com/git/tutorials/comparing-workflows/forking-workflow presents some possible workflows.
A detailed discussion, including many links, can be found on
http://stackoverflow.com/questions/2621610/what-git-branching-models-work-for-you
- DAMASK work flow
-
Create a new branch for features and improvements
-
Once all changes are done, request to merge them into the development
branch
-
After a successfull test, development
is automatically merged into master
-
Releases are manually created from the master
branch (release
branch)
Tags are used to mark certain revisions.
Releases are marked by tags.
Read this German text or check out
semver.org
DAMASK G MM.mm.ff.pppp
^^^^^^--------------------------- Name
^------------------------- Generation (skip for the moment until we have DAMASK 2)
^^---------------------- Major (not backward compatible, old input files will not work)
^^------------------- Minor (new features)
^^---------------- Bugfix
^^^^----------- Patch
Correctness Checks
For a fast feedback on any changes pushed to the
http://magit1.mpie.de, modified files are checked before a push is accepted.
This is done via a
pre-receive hook.
Python files are checked for invalid code, unused variables etc using
prospector.
Prospector is a tool to analyze Python code and output information about errors, potential problems, convention violations, and complexity and combines the functionality of other Python analysis tools.
The configuration file
DAMASK.yaml is designed to ensure compatibility with Python 2.x and Python 3.x.
Any change in the src subdirectory triggers a syntax check with Gfortran
-fsyntax-only
for the spectral solver;
Any change in the src subdirectory triggers a syntax check with Ifort
-fsyntax-only
for MSC.Marc.
To skip this check, add '[skip sc]' to the latest commit message, e.g. via
> git commit -a --amend
in the case that all your changes are locally committed already.
Testing
Extended testing is performed on each push using the
GitLab Continuous Integration.
All tests specified in a configuration file in the main repository are run on the test server (nohup, using Damask_user).
The pipelines give a feedback, which tests are working.
To skip the tests, add '[skip ci]' to the latest commit message, e.g. via
> git commit -a --amend
in the case that all your changes are locally committed already.
If the test suite needs to be modified for a certain branch, the
submodules feature of git allows to couple the status of the branch with a fitting commit in the PRIVATE repository.
Initialize (i.e. clone) the PRIVATE repository via
> git submodule update --init
Any change in PRIVATE needs to be commited/pushed as usual.
As submodules are linked as commit IDs (hashes) and not as branches, after initialization you are in 'detached head' mode and need to check out the branch of interest (typically 'master').
Additionally, commit the current commit ID of the PRIVATE repository in the DAMASK repository:
> git commit PRIVATE
By that, the status (i.e. the current commit ID) is stored in the current branch of the DAMASK repository and will be used by the test facility.
https://docs.gitlab.com/ce/ci/git_submodules.html