...
Section | ||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
...
For users without an account, please go to https://apps.ecmwf.int/registration/ and fill in the form to register for an account. Note that it will take some time for the new account to be registered on all the websites. Please wait for about an hour and then try to login to the main website https://www.ecmwf.int/ to refer the account works.
...
Make sure you can successfully log in to the main ECMWF website before following the procedure below.
Authentication
The procedure to get a password to download the OpenIFS git repository is:
...
We recommend that users login to Bitbucket via the web interface and upload their ssh public keys into the user profile to allow passwordless access to the git repositories.
Cloning and branching
To clone the repository at the remote site follow these steps. This will prompt for your username and the password created as described in the previous section:
Code Block | ||
---|---|---|
| ||
% mkdir openifs
% cd openifs
% git clone ssh://git@git.ecmwf.int:7999/oifs/oifs40r1.git # use: git clone https://nagc@git.ecmwf.int/stash/scm/oifs/oifs40r1.git external to ECMWF
Cloning into 'oifs40r1'...
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 oifs40r1
% git checkout develop # or whichever release version is required (the most recent is recommended)
Branch develop set up to track remote branch develop from origin.
Switched to a new branch 'develop'
% git checkout -b feature/new_idea # create new branch. ALWAYS branch from the develop branch, never the master branch.
Switched to a new branch 'feature/new_idea' |
...
Gliffy Diagram | ||||
---|---|---|---|---|
|
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 tracks only major releases, v1, v2, and not minor etc. Minor releases should NOT be merged to master since, for example, v1.1 might be released after v2 which would cause difficulties merging to master.
...
Portions of this page written by ECMWF user support: Daniel Santoalla.
Excerpt Include | ||||||
---|---|---|---|---|---|---|
|