Skip to content

Commit e7a16d2

Browse files
eugenesooeugenesoo
committed
initialise and prepare repository
1 parent 35a661d commit e7a16d2

16 files changed

+5556
-0
lines changed

Diff for: ‎.babelrc

+5
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,5 @@
1+
{
2+
presets: [
3+
'es2015', 'react'
4+
]
5+
}

Diff for: ‎.editorconfig

+21
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,21 @@
1+
# EditorConfig helps developers define and maintain consistent
2+
# coding styles between different editors and IDEs
3+
# editorconfig.org
4+
5+
root = true
6+
7+
8+
[*]
9+
10+
# Change these settings to your own preference
11+
indent_style = space
12+
indent_size = 2
13+
14+
# We recommend you to keep these unchanged
15+
end_of_line = lf
16+
charset = utf-8
17+
trim_trailing_whitespace = true
18+
insert_final_newline = true
19+
20+
[*.md]
21+
trim_trailing_whitespace = false

Diff for: ‎.eslintrc.js

+10
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,10 @@
1+
/**
2+
* These rules enforce the Hack Reactor Style Guide
3+
*
4+
* Visit this repo for more information:
5+
* https://github.com/reactorcore/eslint-config-hackreactor
6+
*/
7+
8+
module.exports = {
9+
extends: './node_modules/eslint-config-hackreactor/index.js'
10+
};

Diff for: ‎.gitattributes

+1
Original file line numberDiff line numberDiff line change
@@ -0,0 +1 @@
1+
* text=auto

Diff for: ‎.gitignore

+30
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,30 @@
1+
### node etc ###
2+
3+
# Logs
4+
logs
5+
*.log
6+
7+
# Runtime data
8+
pids
9+
*.pid
10+
*.seed
11+
12+
# Directory for instrumented libs generated by jscoverage/JSCover
13+
lib-cov
14+
15+
# Coverage directory used by tools like istanbul
16+
coverage
17+
18+
# Grunt intermediate storage (http://gruntjs.com/creating-plugins#storing-task-files)
19+
.grunt
20+
21+
# Compiled Dirs (http://nodejs.org/api/addons.html)
22+
client/dist
23+
24+
# Dependency directorys
25+
# Deployed apps should consider commenting these lines out:
26+
# see https://npmjs.org/doc/faq.html#Should-I-check-my-node_modules-folder-into-git
27+
node_modules/
28+
bower_components/
29+
30+

Diff for: ‎CONTRIBUTING.md

+152
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,152 @@
1+
# Contributing
2+
3+
## General Workflow
4+
5+
1. Fork the repo
6+
1. Cut a namespaced feature branch from master
7+
1. Make commits to your feature branch. Prefix each commit like so:
8+
1. When you've finished with your fix or feature, Rebase upstream changes into your branch. submit a pull request directly to master. Include a description of your changes.
9+
1. Your pull request will be reviewed by another maintainer. The point of code reviews is to help keep the codebase clean and of high quality and, equally as important, to help you grow as a programmer. If your code reviewer requests you make a change you don't understand, ask them why.
10+
1. Fix any issues raised by your code reviwer, and push your fixes as a single new commit.
11+
1. Once the pull request has been reviewed, it will be merged by another member of the team. Do not merge your own commits.
12+
13+
## Detailed Workflow
14+
15+
### Fork the repo
16+
17+
Use github’s interface to make a fork of the repo, then add that repo as an upstream remote:
18+
19+
```
20+
git remote add upstream https://github.com/organization/<NAME_OF_REPO>.git
21+
```
22+
23+
### Cut a namespaced feature branch from master
24+
25+
Your branch should follow this naming convention:
26+
- bug/...
27+
- feat/...
28+
- test/...
29+
- doc/...
30+
- refactor/...
31+
32+
These commands will help you do this:
33+
34+
``` bash
35+
36+
# Creates your branch and brings you there
37+
git checkout -b `your-branch-name`
38+
```
39+
40+
### Make commits to your feature branch.
41+
42+
Prefix each commit like so
43+
- (feat) Add a new feature
44+
- (fix) Fix inconsistent tests [Fixes #0]
45+
- (refactor) ...
46+
- (cleanup) ...
47+
- (test) ...
48+
- (doc) ...
49+
50+
Make changes and commits on your branch, and make sure that you
51+
only make changes that are relevant to this branch. If you find
52+
yourself making unrelated changes, make a new branch for those
53+
changes.
54+
55+
#### Commit Message Guidelines
56+
57+
- Commit messages should be written in the present tense; e.g. "Fix continuous integration script".
58+
- The first line of your commit message should be a brief summary of what the commit changes. Aim for about 70 characters max. Remember: This is a summary, not a detailed description of everything that changed.
59+
- If you want to explain the commit in more depth, following the first line should be a blank line and then a more detailed description of the commit. This can be as detailed as you want, so dig into details here and keep the first line short.
60+
61+
### Rebase upstream changes into your branch
62+
63+
Once you are done making changes, you can begin the process of getting
64+
your code merged into the main repo. Step 1 is to rebase upstream
65+
changes to the master branch into yours by running this command
66+
from your branch:
67+
68+
```bash
69+
git pull --rebase upstream master
70+
```
71+
72+
This will start the rebase process. You must commit all of your changes
73+
before doing this. If there are no conflicts, this should just roll all
74+
of your changes back on top of the changes from upstream, leading to a
75+
nice, clean, linear commit history.
76+
77+
If there are conflicting changes, git will start yelling at you part way
78+
through the rebasing process. Git will pause rebasing to allow you to sort
79+
out the conflicts. You do this the same way you solve merge conflicts,
80+
by checking all of the files git says have been changed in both histories
81+
and picking the versions you want. Be aware that these changes will show
82+
up in your pull request, so try and incorporate upstream changes as much
83+
as possible.
84+
85+
You pick a file by `git add`ing it - you do not make commits during a
86+
rebase.
87+
88+
Once you are done fixing conflicts for a specific commit, run:
89+
90+
```bash
91+
git rebase --continue
92+
```
93+
94+
This will continue the rebasing process. Once you are done fixing all
95+
conflicts you should run the existing tests to make sure you didn’t break
96+
anything, then run your new tests (there are new tests, right?) and
97+
make sure they work also.
98+
99+
If rebasing broke anything, fix it, then repeat the above process until
100+
you get here again and nothing is broken and all the tests pass.
101+
102+
### Make a pull request
103+
104+
Make a clear pull request from your fork and branch to the upstream master
105+
branch, detailing exactly what changes you made and what feature this
106+
should add. The clearer your pull request is the faster you can get
107+
your changes incorporated into this repo.
108+
109+
At least one other person MUST give your changes a code review, and once
110+
they are satisfied they will merge your changes into upstream. Alternatively,
111+
they may have some requested changes. You should make more commits to your
112+
branch to fix these, then follow this process again from rebasing onwards.
113+
114+
Once you get back here, make a comment requesting further review and
115+
someone will look at your code again. If they like it, it will get merged,
116+
else, just repeat again.
117+
118+
Thanks for contributing!
119+
120+
### Guidelines
121+
122+
1. Uphold the current code standard:
123+
- Keep your code [DRY][].
124+
- Apply the [boy scout rule][].
125+
- Follow [STYLE-GUIDE.md](_STYLE-GUIDE.md)
126+
1. Run the [tests][] before submitting a pull request.
127+
1. Tests are very, very important. Submit tests if your pull request contains
128+
new, testable behavior.
129+
130+
## Checklist:
131+
132+
This is just to help you organize your process
133+
134+
- [ ] Did I cut my work branch off of master (don't cut new branches from existing feature brances)?
135+
- [ ] Did I follow the correct naming convention for my branch?
136+
- [ ] Is my branch focused on a single main change?
137+
- [ ] Do all of my changes directly relate to this change?
138+
- [ ] Did I rebase the upstream master branch after I finished all my
139+
work?
140+
- [ ] Did I write a clear pull request message detailing what changes I made?
141+
- [ ] Did I get a code review?
142+
- [ ] Did I make any requested changes from that code review?
143+
144+
If you follow all of these guidelines and make good changes, you should have
145+
no problem getting your changes merged in.
146+
147+
148+
<!-- Links -->
149+
[curriculum workflow diagram]: http://i.imgur.com/p0e4tQK.png
150+
[Git Flow]: http://nvie.com/posts/a-successful-git-branching-model/
151+
[GitHub Flow]: http://scottchacon.com/2011/08/31/github-flow.html
152+
[Squash]: http://gitready.com/advanced/2009/02/10/squashing-commits-with-rebase.html

Diff for: ‎README.md

+52
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,52 @@
1+
# Project Name
2+
3+
> Pithy project description
4+
5+
## Team
6+
7+
- Johnny Li
8+
- Tiffany Pham
9+
- Neha Chaudhary
10+
- Eugene Soo
11+
12+
## Table of Contents
13+
14+
1. [Usage](#Usage)
15+
1. [Requirements](#requirements)
16+
1. [Development](#development)
17+
1. [Installing Dependencies](#installing-dependencies)
18+
1. [Tasks](#tasks)
19+
1. [Roadmap](#roadmap)
20+
1. [Contributing](#contributing)
21+
22+
## Usage
23+
24+
npm run server starts your server.
25+
npm run client starts webpack, which bundles your client files in client/src and watches for changes.
26+
27+
## Requirements
28+
29+
- Node 6.4.x
30+
- Redis 2.6.x
31+
- Postgresql 9.1.x
32+
- etc
33+
- etc
34+
35+
## Development
36+
37+
### Installing Dependencies
38+
39+
From within the root directory:
40+
41+
```sh
42+
npm install
43+
```
44+
45+
### Roadmap
46+
47+
View the project roadmap [here](LINK_TO_DOC)
48+
49+
50+
## Contributing
51+
52+
See [CONTRIBUTING.md](CONTRIBUTING.md) for contribution guidelines.

0 commit comments

Comments
 (0)