Development/Tutorials/Git/Feature Development Workflow

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.

Some KDE Components have adopted an integration-staging-origin policy for pushing features into KDE's repositories. This document is designed to get developers started with this workflow and understand the steps involved.

Repositories and projects complying with this policy

The following repositories/projects follow these guidelines. Any project not mentioned here is unaffected by what described

• kde-workspace
• kde-runtime
• kdelibs (plasma only)

Rationale

This approach is meant to implement proper quality evaluation into the main repositories, still allowing developers to work on anything they want, and providing a sane merging strategy which does not require any specific knowledge from the developer's side.

This is achieved by using two separate repositories. One is origin, the official project repository, where just maintainers are allowed to push, apart from special cases. The other is integration, where work in progress happens, and everyone can create branches and work on that.

There are two separate figures: developers and maintainers. Developers are people who want to work on features on a specific repositories, maintainers are the gatekeepers for those repositories. Please note the purpose of the maintainer is purely organizational: no special power over technical decision is given to maintainers.

A developer would provide his code into a remote branch in integration: as soon as this code is ready and reviewed, the maintainer would take care of merging into integration/master first, prepare for staging in integration/staging, and finally merge into master when needed.

Setting up the development environment

In the following steps, we will assume your system is set up as shown in the git.kde.org user manual, especially regarding automatic URL rewriting for KDE repositories enabled.

In the following tutorial, we'll refer to kdelibs as the main target, but this applies to any other repository using this policy.

Cloning the repository and adding integration

To clone the repository, issue

git clone kde:kdelibs

This will create a kdelibs directory containing the whole repository. You now need to add a separate remote for handling integration. A remote is a repository URL, and your local clone can contain multiple repositories to track different branches. To add kdelibs' integration repository, issue inside kdelibs' clone:

git remote add integration kde:clones/kdelibs/dafre/kdelibs-integration

Now, fetch from integration to retrieve the changes:

git fetch integration

Note

When working with multiple remotes, you can issue git fetch --all to update all the remotes tracked by your local copy