...

% mkdir openifs
% cd openifs
% git clone httpsssh://softwaregit@software.ecmwf.int:7999/stash/scm/oifs/oifs38r1oifs40r1.git       # oruse: whichevergit model major release is requiredclone https://nagc@software.ecmwf.int/stash/scm/oifs/oifs40r1.git external to ECMWF
Cloning into 'oifs38r1oifs40r1'...
remote: Counting objects: 4680, done.
remote: Compressing objects: 100% (3654/3654), done.
remote: Total 4680 (delta 1206), reused 4175 (delta 871)
Receiving objects: 100% (4680/4680), 21.45 MiB | 20.71 MiB/s, done.
Resolving deltas: 100% (1206/1206), done.
Checking connectivity... done
% cd oifs38r1oifs40r1
% git checkout release/v04develop                         # or whichever release version is required (the most recent is recommended)
Branch release/v04develop set up to track remote branch release/v04develop from origin.
Switched to a new branch 'release/v04develop'
% git checkout -b my_feature/new_idea                      # create new branch. ALWAYS branch from the releasedevelop branch, never the master branch.
Switched to a new branch 'my_feature/new_idea'

Branching model

OpenIFS has a small number of developers and a small number of releases. In this scenario, a single 'develop' branch with multiple release branches works well. The branching strategy is similar to the "gitflow" model but with modifications for multiple supported releases, which gitflow does not supportallow for.

...

Notes:

• All new code should branch from the main 'develop' branch as 'feature' branches e.g. feature/update-physics.
• Release branches are created from develop. From then on release branches should be fixes only, no new features. Fixes should be merged back to the main develop branch.
• Production releases should be tagged on the release branch (never the master branch, unlike the 'gitflow' model).
• Hotfixes should branch from their respective release only, and if necessary be merged into the develop branch.
• The master branch is largely redundant in this model. Only major releases, v1, v2, and not minor releases should be merged to master since v1.1 might be released after v2 which would cause difficulties merging to master.

User contributed branches

These should be organised under branches named according to the institution, and branched from 'develop'.

For example, branches from SMHI would all live under 'smih.se', such as, develop/smhi.se/long-run-changes'; from Barcelona Supercomputer Centre, 'develop/bsc.es/xios'.

If necessary, these user-contributed branches can have their own 'develop' and 'release' branches before any merge takes place on the OpenIFS mainline develop branch.

It's desirable to follow the gitflow model under the user contributed branches to maintain consistency with the branch model.

Possible problems accessing OpenIFS git repository

git commands return error code 501; cannot clone

...