...
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.
...
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 | ||||||
---|---|---|---|---|---|---|
|