2
2
mirror of https://github.com/octoleo/restic.git synced 2024-12-25 04:05:58 +00:00
restic/CONTRIBUTING.md

143 lines
5.5 KiB
Markdown
Raw Normal View History

2015-05-06 21:18:46 +00:00
This document describes the way you can contribute to the restic project.
2015-05-06 07:11:07 +00:00
2015-05-06 21:18:46 +00:00
Ways to Help Out
2015-05-06 07:11:07 +00:00
================
Thank you for your contribution!
2015-05-06 21:18:46 +00:00
There are several ways you can help us out. First of all code contributions and
bug fixes are most welcome. However even "minor" details as fixing spelling
errors, improving documentation or pointing out usability issues are a great
help also.
2015-05-06 07:11:07 +00:00
2015-05-06 21:18:46 +00:00
The restic project uses the GitHub infrastructure (see the
[project page](https://github.com/restic/restic)) for all related discussions
as well as the `#restic` channel on `irc.freenode.net`.
2015-05-06 07:11:07 +00:00
2015-05-06 21:18:46 +00:00
If you want to find an area that currently needs improving have a look at the
open issues listed at the
[issues page](https://github.com/restic/restic/issues). This is also the place
for discussing enhancement to the restic tools.
If you are unsure what to do, please have a look at the issues, especially
those tagged
[minor complexity](https://github.com/restic/restic/labels/minor%20complexity).
2015-06-24 17:20:27 +00:00
Development Environment
=======================
For development, it is recommended to check out the restic repository within a
`GOPATH`, an introductory text is
["How to Write Go Code"](https://golang.org/doc/code.html). It is recommended
to have a working directory, we're using `~/work/restic` in the following. This
directory mainly contains the directory `src`, where the source code is stored.
First, create the necessary directory structure and clone the restic repository
to the correct location:
$ mkdir --parents ~/work/restic/src/github.com/restic
$ cd ~/work/restic/src/github.com/restic
$ git clone https://github.com/restic/restic
$ cd restic
Now we're in the main directory of the restic repository. The last step is to
set the environment variable `$GOPATH` to the correct value:
$ export GOPATH=~/work/restic:~/work/restic/src/github.com/restic/restic/Godeps/_workspace
The following commands can be used to run all the tests:
$ go test ./...
ok github.com/restic/restic 8.174s
[...]
The restic binary can be built from the directory `cmd/restic` this way:
$ cd cmd/restic
$ go build
$ ./restic version
restic compiled manually on go1.4.2
2015-07-18 22:05:04 +00:00
if you want to run your tests on Linux, OpenBSD or FreeBSD, you can use
[vagrant](https://www.vagrantup.com/) with the proveded `Vagrantfile` to
quickly set up VMs and run the tests, e.g.:
$ vagrant up freebsd
[...]
$ vagrant ssh freebsd -c 'cd restic/restic; go test -v ./...'
[...]
2015-05-06 21:18:46 +00:00
Providing Patches
2015-05-06 07:11:07 +00:00
=================
2015-05-06 21:18:46 +00:00
You have fixed an annoying bug or have added a new feature? Very cool! Let's
2015-05-09 15:20:18 +00:00
get it into the project! The workflow we're using is also described on the
2015-05-09 09:11:00 +00:00
[GitHub Flow](https://guides.github.com/introduction/flow/) website, it boils
2015-05-09 15:20:18 +00:00
down to the following steps:
2015-05-09 09:11:00 +00:00
1. First we would kindly ask you to fork our project on GitHub if you haven't
done so already.
2015-06-24 17:20:27 +00:00
2. Clone the repository locally and create a new branch. If you are working on
the code itself, please set up the development environment as described in
the previous section and instead of cloning add your fork on GitHub as a
remote to the clone of the restic repository.
2015-05-09 09:11:00 +00:00
3. Then commit your changes as fine grained as possible, as smaller patches,
that handle one and only one issue are easier to discuss and merge.
4. Push the new branch with your changes to your fork of the repository.
5. Create a pull request by visiting the GitHub website, it will guide you
through the process.
6. You will receive comments on your code and the feature or bug that they
address. Maybe you need to rework some minor things, in this case push new
commits to the branch you created for the pull request, they will be
automatically added to the pull request.
7. Once your code looks good, we'll merge it. Thanks a low for your
contribution!
2015-05-06 07:11:07 +00:00
2015-05-09 09:11:00 +00:00
Please provide the patches for each bug or feature in a separate branch and
open up a pull request for each.
The restic project uses the `gofmt` tool for Go source indentation, so please
2015-05-06 21:18:46 +00:00
run
2015-05-06 07:11:07 +00:00
gofmt -w **/*.go
2015-05-06 21:18:46 +00:00
in the project root directory before committing. Installing the script
`fmt-check` from https://github.com/edsrzf/gofmt-git-hook locally as a
pre-commit hook checks formatting before committing automatically, just copy
this script to `.git/hooks/pre-commit`.
2015-05-06 07:11:07 +00:00
2015-08-12 18:38:43 +00:00
Git Commits
-----------
I would be good if you could follow the same general style regarding Git
commits as the rest of the project, this makes reviewing code, browsing the
history and triaging bugs much easier.
Git commit messages have a very terse summary in the first line of the commit
message, followed by an empty line, followed by a more verbose description or a
List of changed things. For examples, please refer to the excellent [How to
Write a Git Commit Message](http://chris.beams.io/posts/git-commit/).
If you change/add multiple different things that aren't related at all, try to
make several smaller commits. This is much easier to review. Using `git add -p`
allows staging and committing only some changes.
2015-05-06 21:18:46 +00:00
Code Review
2015-05-06 07:11:07 +00:00
===========
2015-05-06 21:18:46 +00:00
The restic project encourages actively reviewing the code, as it will store
2015-05-09 09:11:00 +00:00
your precious data, so it's common practice to receive comments on provided
2015-05-06 21:18:46 +00:00
patches.
2015-05-06 07:11:07 +00:00
2015-05-06 21:18:46 +00:00
If you are reviewing other contributor's code please consider the following
when reviewing:
2015-05-06 07:11:07 +00:00
2015-05-06 21:18:46 +00:00
* Be nice. Please make the review comment as constructive as possible so all
participants will learn something from your review.
2015-05-06 07:11:07 +00:00
2015-05-06 21:18:46 +00:00
As a contributor you might be asked to rewrite portions of your code to make it
fit better into the upstream sources.