From 32ecc832348fe5de7f682f49fe875cceb0b764d2 Mon Sep 17 00:00:00 2001 From: "daniel.werdermann" Date: Tue, 29 Sep 2015 17:12:19 +0200 Subject: [PATCH] add information for contributers --- DEVELOP.md | 68 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 68 insertions(+) create mode 100644 DEVELOP.md diff --git a/DEVELOP.md b/DEVELOP.md new file mode 100644 index 0000000..99d9fca --- /dev/null +++ b/DEVELOP.md @@ -0,0 +1,68 @@ +Contributing +------------ + +normal + + 1. [Fork](http://help.github.com/forking/) puppet-TEMPLATE + 2. Create a topic branch against the develop branch `git checkout develop; git checkout -b my_branch` + 3. Push to your branch `git push origin my_branch` + 4. Create a [Pull Request](http://help.github.com/pull-requests/) from your branch against the develop branch + +[git-flow](https://github.com/nvie/gitflow) + + 1. [Fork](http://help.github.com/forking/) puppet-TEMPLATE + 2. Create a feature `git flow feature start my-feature` + 3. Publish your featue `git flow feature publish my-feature` + 4. Create a [Pull Request](http://help.github.com/pull-requests/) from your branch against the develop branch + +Testing +------- + +Tests are written with [rspec-puppet](http://rspec-puppet.com/). CI is covered by [Travis CI](http://about.travis-ci.org/) and the current status is visible [here](http://travis-ci.org/echocat/puppet-TEMPLATE). + +To run all tests: + + rake spec + +Branching +--------- + +This repository is organized and maintained with the help of [gitflow](https://github.com/nvie/gitflow). Developers are encouraged to use it when working with this repository. + +We use the following naming convention for branches: + +* develop (during development) +* master (will be or has been released) +* feature/ (feature branches) +* release/ (release branches) +* hotfix/ (hotfix branches) +* (empty version prefix) + +During development, you should work in feature branches instead of committing to master directly. Tell gitflow that you want to start working on a feature and it will do the work for you (like creating a branch prefixed with feature/): + + git flow feature start + +The work in a feature branch should be kept close to the original problem. Tell gitflow that a feature is finished and it will merge it into master and push it to the upstream repository: + + git flow feature finish + +Even before a feature is finished, you might want to make your branch available to other developers. You can do that by publishing it, which will push it to the upstream repository: + + git flow feature publish + +To track a feature that is located in the upstream repository and not yet present locally, invoke the following command: + + git flow feature track + +Changes that should go into production should come from the up-to-date master branch. Enter the "release to production" phase by running: + + git flow release start + +In this phase, only meta information should be touched, like bumping the version and update the history. Finish the release phase with: + + git flow release finish + +Versioning +---------- + +This project is versioned with the help of the [Semantic Versioning Specification](http://semver.org/) using 0.0.1 as the initial version. Please make sure you have read the guidelines before increasing a version number either for a release or a hotfix.