...
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.
...
After the fork has been created, a contributor should create a local clone of the new forked central repository. This can be done by executing:
| Code Block |
|---|
git clone git@github.com:usernameinspectIT/inspectIT.git |
After this is finished, add your own forked repository as a new remote to your local repository:
| Code Block |
|---|
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:
In
addition to creating a local clone of the forked repository, we highly advise to add the inspectIT main repository as remote to your local git clone. This way a contributor can follow the advancing of the inspectIT master branch and update the work accordingly. Adding the remote can be done with (note that inspectit_main can be changed if you wish)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:
| Code Block |
|---|
git remotefetch origin addgit inspectit_main git@github.com:inspectIT/inspectIT.gitrebase origin/stable |
To understand why we enforce rebase and do not allow any merge commits to appear please visit this blog post.
| Info |
|---|
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. |
Implement changes & commit
...
Your changes should be contained in one commit only. We will not accept any pull request containing more than one commit. If you development resulted in more commits, please use squashing option of Git to create a single commit.only a few commits (and most of the time we appreciate if it is only one) as intermediate states of your developed features or bug fixes are not needed in the central repository.
The commit message should point be prefixed with a link to the JIRA ticket the work was done for. The message should always be in the format:
...
| Code Block |
|---|
INSPECTIT-xxx, INSPECTIT-yyy: Description of the changes changes |
Check that the build is working
...
When everything is set, you can push the branch containing the changes to your previously forked repository. If you followed all the steps from this page, this remote repository should be named origin in after your local gitusername:
| Code Block |
|---|
git push origin<username> BRANCH_WITH_THE_CHANGES |
Once you pushed the branch, you can make a pull request on the GitHub. Please go to the forked repository page and click on Branches. There you will have a possibility to create a Pull Request for each branch that you have on your forked repository:
...
Once you have selected correct branch, you will be guided to the compare and confirm page. Please make sure that the base fork is inspectIT/inspectIT and base branch is master stable (this should be set by default). Fill in the title of the pull request and description of the changes you performed (optional) and execute the Create pull request action. It is not necessary to add lots of text to the pull request as this information should be available already in the JIRA ticketing.
...
Label the pull request with the label "Comments only in Reviewable". This ensures that internal comments on pull requests are only available on reviewable but not pushed to GitHub.
First pull request
On the first pull request you have to sign the Contribution Agreement. We use CLA Assistent (a GitHub plugin) for that. You will also get a mail reminder that you have to sign the agreement in order for your pull request to be integrated.