Elektra  0.8.23
GIT

Basic GIT Commands

    git add readme.md   // adds the changes of the file `readme.md` to the staging area
    git add .           // adds all changes of files in the current directory (recursively) to the staging area
    git add --all       // adds all changes of files in the repository to the staging area
    git commit -a       // executes a commit that automatically stages all changed and deleted files before

Basic Configuration

make sure to do: 

    git config --global merge.ff false
    git config merge.ff false

The Commit Message

A commit message should have the following syntax: component: short change description

For a clean and meaningful log the commit message should fulfil the following:

Most commits should have a longer description in the body.

Remote Branches

To list all remote branches use: 

    git branch -a

To checkout a remote branch initially use: 

    git checkout -b <branchname> origin/<branchname>

Once you have done this, it will be a local branch, too. Following remote branches should exist: 

    master

This is the development branch. Please try to not work directly on it, but instead you should use feature branches. So the only commits on master should be non-fastforward merges from features branches. Commits on master should always compile and all test cases should pass successfully. (see config option above) 

    debian

Is the branch to be used to build debian packages. It additionally contains the debian folder. Only debian related commits should be on the debian branch - otherwise it should only contain –no-ff merges from master. (see config option above)

Local Branches

You should always make your own feature branch with: 

    git checkout -b <feature-branch-name>

On this branch it is not so important that every commit compiles or all test cases run.

To merge a branch use (no-fastforward): 

    git merge --no-ff <branchname>

If you already did some commits, but want them in a branch, you can do: 

    git branch foo
    git reset HEAD^^  (for 2 commits back)
    git reset origin/master

    git-ref-log # recover

Build Server

When doing merge requests our buildserver will build jobs of authorized users. If you are not yet authorized, the following question will be asked (by user ): 

    Can one of the admins verify if this patch should be build?

Then one of the admins (sorted by activity):

need to confirm by saying: 

    .*add\W+to\W+whitelist.*

or if just the pull request should be checked: 

    .*build\W+allow.*

Run Jobs

After being added to whitelist you can trigger buildjobs by pushing to the PR. Most tests can be found described in scripts/jenkins/Jenkinsfile.

You can manually trigger rebuilds (in case of outtages) with the following phrases:

Run All Tests

Before we merge a pull request we want to make sure, that all of the build jobs mentioned above still work. For this purpose we provide the phrase:

jenkins build all please

If you add this phrase to a comment in your pull request, then Jenkins will run all jobs, except for

Since running all test jobs needs resources, please use this phrase only if

If you want any changes to the build server infrastructure, please report them.

Generated by   doxygen 1.8.13