Development/Tutorials/Git/Feature Development Workflow/Which repository should I use

< Development‎ | Tutorials‎ | Git/Feature Development Workflow
Revision as of 20:40, 24 March 2012 by AnneW (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search
noframe
 
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 have different target audiences: this page is meant to help you choosing which repository is right for you.

Contents

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


This page was last modified on 24 March 2012, at 20:40. This page has been accessed 869 times. Content is available under Creative Commons License SA 3.0 as well as the GNU Free Documentation License 1.2.
KDE® and the K Desktop Environment® logo are registered trademarks of KDE e.V.Legal