3. Git and GitLab

---

Preamble

The source code is hosted at the Max–Planck–Institut für Eisenforschung at the GitLab server magit1.mpie.de. You need an account to access the repository.

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

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