Skip to end of banner
Go to start of banner

Setup GitHub

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 15 Current »

In order to develop code for the inspectIT a contributor needs to apply the following development process:

GitHub Setup

A prerequisite to work on inspectIT is that a contributor needs to have a working GitHub account. Please use the https://github.com/join page to create an account if you don't have one.

Once the account has been created, you should create a SSH key that you will use on the GitHub. Detailed information on creating the key can be found at https://help.github.com/articles/generating-ssh-keys/.

Fork inspectIT project on the GitHub

First thing a contributor need to do is fork the official inspectIT repository on the GitHub. Each contributor of inspectIT has his own forked repository that serves for pushing the code changes a contributor developed. The official inspectIT repository is located at https://github.com/inspectIT/inspectIT. In the top right corner you will see the ability to fork the repository. Note that you must have a user on GitHub and be logged-in to perform this action.

Make a local clone of the forked repository

After the fork has been created, a contributor should create a local clone of the central repository. This can be done by executing:

git clone git@github.com:inspectIT/inspectIT.git

After this is finished, add your own forked repository as a new remote to your local repository:

git remote add <username> git@github.com:<username>/inspectIT.git

Note that username should be replaced with your correct user-name from GitHub account. You can also copy the SSH clone URL from the forked repository page:

To keep your local copy up-to-date, you're advised to fetch remote changes as often as possible to rebase your personal work on top of it:

git fetch origin
git rebase origin/stable

To understand why we enforce rebase and do not allow any merge commits to appear please visit this blog post.

On the central repository, there are basically two branches: master and stable. The stable one is managed solely by our continuous integration server Jenkins after all checks are done on the master branch. Thus you should only care about the stable branch as this is the one we'll create releases from.

  • No labels