From 660a3ca2ed2ae4dbba47e109c8a192199db85592 Mon Sep 17 00:00:00 2001 From: Michael Boelen Date: Wed, 6 Jan 2016 13:26:44 +0100 Subject: [PATCH] Updated Developer Guide (markdown) --- Developer-Guide.md | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/Developer-Guide.md b/Developer-Guide.md index d7f8913..68c2d33 100644 --- a/Developer-Guide.md +++ b/Developer-Guide.md @@ -21,15 +21,16 @@ Supporting documents and scripts are stored here. Like any programming language, there are different ways to keep a project structured. It ranges from variable names, up to spacing. So we provide some guidelines to keep the structure and flexible enough for further expansion. -* Identitation is done with 4 spaces (no tabs) +* Indentation is done with 4 spaces (no tabs) * Variables are capitalized, optional with an underscore to "split" words # Contribute -## Preparing +First step to contributing via GitHub, is by forking the project. This creates a local version for you to experiment. -If you use Git already, simply clone the project to your local system. Otherwise work with a local copy. At the GitHub page you can download the master.zip file, containing the latest master release. +* Fork it ( https://github.com/CISOfy/lynis/fork ) +* Create your feature branch (git checkout -b adding-my-new-feature) ## Making changes @@ -37,10 +38,15 @@ Next step is making your local changes and test them. **Tip:** To simplify testing, you don't have Lynis to perform all tests. Use --tests-category or --tests to specifically decide what tests to run. +After you are done, commit the changes: (git commit -am 'Adding some feature or improvement') + ## Testing To improve the quality of your changes, tests should limit the amount of screen output. Important details should be logged to the log file, using the `logtext` function. ## Send in your changes -Last step is creating a pull request. Provide a clear description on what the pull request is about (and why). If you have multiple changes to different tests, split them into multiple pull requests. This way it is easier to check and implement them in the master branch. \ No newline at end of file +Last step is creating a pull request. Provide a clear description on what the pull request is about (and why). If you have multiple changes to different tests, split them into multiple pull requests. This way it is easier to check and implement them in the master branch. + +* Push to the branch (git push origin adding-my-new-feature) +* Create a new Pull Request \ No newline at end of file