You are viewing an old version of this page. View the current version.
Version 1 Next »
For short and to-the-point Git tutorials see here:
... to be continued
Git And Stash
The repositories are hosted on DESY Stash.
(master, develop, core, module branches)
clone/pull: all developers
browse/comment: all developers
push: module developers only
|stores module data|
|public releases (stable branch)||clone/pull/browse: public|
|read/write: module developers only|
There are different methods for accessing the Stash repositories summarized here:
|Method||How to access||Operations|
|git ssh||clone, pull, push|
|git http||clone, pull, push|
|web interface||browse, comment, pull request|
There are three ways to authenticate with Stash:
- authenticated access requires a DESY Stash account and allows all three methods above
- unauthenticated access is possible for ssh access only
- anonymous access allows http and web access to public repositories
Here is a summary of allowed operations for the different levels of authentication:
|clone, pull, browse public|
|push to unrestricted branch||/||( via ssh)|
|push to write-restricted branch||/|
Here / means that access can be configured for specific users if needed.
Configuring ssh access
ssh is the recommended way for command-line access, since it uses ssh keys and no passwords are required.
To configure authenticated ssh access, go to your Stash profile and install your public ssh key. When accessing the git repos via ssh using a so-installed ssh key, the Stash server automatically authenticates and associate the access with your Stash account.
For unauthenticated ssh access, your public ssh key can be installed directly in the repo (you have to email it to Frank). The advantage is that this works without requiring a Stash account, but it has some limitations as shown in the table above.
Some networks block port 7999. In this case http is the only fall-back option.
We use a standard Git workflow, where all feature development happens in branches. By default each module has its own branch with possible sub-branches for feature development. The integration happens through the develop branch. Here is a summary of the conventions for branches and their relations
|Branch||Purpose||Originates from||Merges into|
|stable||Public access for stable releases, contains abridged (squashed) version of master|
|hotfix-xxx||Critical fixes to stable releases||master||develop and master|
|develop||Integration of all features that will go into next release||master|
|release-x.y||Preparation for stable release||develop||develop and master|
|core||Development of core library||develop||develop|
|module-xxx||Main development for module 'xxx'||develop||develop|
|module-xxx-feature||Development of 'feature' in module 'xxx'||module-xxx||module-xxx|
- No labels