Development/Tutorials/Git/Feature Development Workflow/Which repository should I use: Difference between revisions
Created page with '{{warning|This page refers to a draft policy which is still to be agreed and implemented. Please take it as a reference for a work in progress project. }} Different repositories...' |
m moved Archive:Development/Tutorials/Git/Feature Development Workflow/Which repository should I use to Development/Tutorials/Git/Feature Development Workflow/Which repository should I use: revert |
(One intermediate revision by the same user not shown) | |
(No difference)
|
Latest revision as of 19:40, 24 March 2012
Different repositories have different target audiences: this page is meant to help you choosing which repository is right for you.
If you are a developer
If you are a developer the solution is simple: always use integration/master, and track origin/master if you need to commit straight to origin (for example, if you need to push a trivial bug fix). In integration, all new work from other developers is being merged, and you can stay on the bleeding edge and focus on creating your own branches and follow development. NEVER track staging locally.
If you are a user
Depending on your needs, you might want to use integration/master or origin/master. origin is rather safe, and provides a secure testing grounds for not yet released features, whereas integration is the bleeding edge, where breakages might happen, and new features are merged for the first time.
The decision should always be made considering your level of expertise, your needs, and your attitude to handling unstable software. Usually, if you do not know what do do, go for origin/master. NEVER track staging locally.
If you are a packager
You should settle on origin/master, and eventually backport features which are planned for not being staged in the short term from integration/master. NEVER track staging locally: a common mistake might lead people to think that staging is regarding packagers, whereas it is only relevant for repository maintainers!
If you are a maintainer
Track integration and origin in the same clone. You should track locally each branch you are working on until it gets deleted - this includes staging. A good workflow for staging is to delete and recreate the branch everytime a lifecycle is started (and hence the branch's history is changed).