1 | # CONTRIBUTING
|
2 |
|
3 | The MIT Linked Data group and the `solid` project welcomes new contributors. This document will guide you
|
4 | through the process.
|
5 |
|
6 | ### Step 1: FORK
|
7 |
|
8 | Fork the project [on GitHub](https://github.com/solid/node-solid-server) and check out
|
9 | your copy.
|
10 |
|
11 | ```sh
|
12 | $ git clone git@github.com:your_username/node-solid-server.git
|
13 | $ cd node-solid-server
|
14 | $ git remote add upstream git://github.com/solid/node-solid-server.git
|
15 | $ npm install
|
16 | ```
|
17 |
|
18 |
|
19 | ### Step 2: BRANCH
|
20 |
|
21 | Create a feature branch and start hacking:
|
22 |
|
23 | ```sh
|
24 | $ git checkout -b my-feature-branch -t origin/master
|
25 | ```
|
26 |
|
27 |
|
28 | ### Step 3: COMMIT
|
29 |
|
30 | Make sure git knows your name and email address:
|
31 |
|
32 | ```sh
|
33 | $ git config --global user.name "J. Random User"
|
34 | $ git config --global user.email "j.random.user@example.com"
|
35 | ```
|
36 |
|
37 | Writing good commit logs is important. A commit log should describe what
|
38 | changed and why. Follow these guidelines when writing one:
|
39 |
|
40 | 1. The first line should be 50 characters or less and contain a short
|
41 | description of the change prefixed with the name of the changed
|
42 | subsystem (e.g. "net: add localAddress and localPort to Socket").
|
43 | 2. Keep the second line blank.
|
44 | 3. Wrap all other lines at 72 columns.
|
45 |
|
46 | A good commit log looks like this:
|
47 |
|
48 | ```
|
49 | subsystem: explaining the commit in one line
|
50 |
|
51 | Body of commit message is a few lines of text, explaining things
|
52 | in more detail, possibly giving some background about the issue
|
53 | being fixed, etc etc.
|
54 |
|
55 | The body of the commit message can be several paragraphs, and
|
56 | please do proper word-wrap and keep columns shorter than about
|
57 | 72 characters or so. That way `git log` will show things
|
58 | nicely even when it is indented.
|
59 | ```
|
60 |
|
61 | The header line should be meaningful; it is what other people see when they
|
62 | run `git shortlog` or `git log --oneline`.
|
63 |
|
64 | Check the output of `git log --oneline files_that_you_changed` to find out
|
65 | what subsystem (or subsystems) your changes touch.
|
66 |
|
67 |
|
68 | ### Step 4: REBASE
|
69 |
|
70 | Use `git rebase` (not `git merge`) to sync your work from time to time.
|
71 |
|
72 | ```sh
|
73 | $ git fetch upstream
|
74 | $ git rebase upstream/master
|
75 | ```
|
76 |
|
77 |
|
78 | ### Step 5: TEST
|
79 |
|
80 | Bug fixes and features should come with tests. Add your tests in the
|
81 | `test/` directory. Look at other tests to see how they should be
|
82 | structured (license boilerplate, common includes, etc.).
|
83 |
|
84 | ```sh
|
85 | $ npm test
|
86 | ```
|
87 |
|
88 | Makeall tests pass. Please, do not submit patches that fail either check.
|
89 |
|
90 |
|
91 | ### Step 6: PUSH
|
92 |
|
93 | ```sh
|
94 | $ git push origin my-feature-branch
|
95 | ```
|
96 |
|
97 | Go to https://github.com/username/node-solid-server and select your feature branch. Click
|
98 | the 'Pull Request' button and fill out the form.
|
99 |
|
100 | Pull requests are usually reviewed within a few days. If there are comments
|
101 | to address, apply your changes in a separate commit and push that to your
|
102 | feature branch. Post a comment in the pull request afterwards; GitHub does
|
103 | not send out notifications when you add commits.
|
104 |
|
105 | ### Step 7: PUBLISH
|
106 |
|
107 | If you have permission access, we reccomend using:
|
108 |
|
109 | ```bash
|
110 | $ npm version patch && npm publish && git push --follow-tags
|
111 | ```
|
112 |
|
113 | ## Using HUB
|
114 |
|
115 | [hub](https://hub.github.com/) is a tool released by Github to help developers to use their website from command line.
|
116 |
|
117 | The described guidelines can be resumed as following:
|
118 |
|
119 | ```bash
|
120 | $ git clone https://github.com/solid/node-solid-server
|
121 | $ cd node-solid-server
|
122 |
|
123 | # to fork the repository
|
124 | $ hub fork
|
125 |
|
126 | # to fork the repository
|
127 | $ git checkout -b feature-branch
|
128 |
|
129 | # after committing your changes, push to your repo
|
130 | $ git push your_username feature-branch
|
131 |
|
132 | # start a PR
|
133 | $ hub pull-request
|
134 | ```
|
135 |
|
136 | This document is forked from [joyent/node](https://github.com/joyent/node/blob/master/CONTRIBUTING.md)
|
137 |
|
138 |
|
139 | [issue tracker]: https://github.com/solid/node-solid-server/issues
|