Merge pull request #47 from fedden/develop

Update master

.gitignore

@@ -1,5 +1,127 @@
 tags
 tags/
+*.pkl
+*.gz
+
+### WEB STUFF
+
+# Logs
+logs
+*.log
+npm-debug.log*
+yarn-debug.log*
+yarn-error.log*
+lerna-debug.log*
+
+# Diagnostic reports (https://nodejs.org/api/report.html)
+report.[0-9]*.[0-9]*.[0-9]*.[0-9]*.json
+
+# Runtime data
+pids
+*.pid
+*.seed
+*.pid.lock
+
+# Directory for instrumented libs generated by jscoverage/JSCover
+lib-cov
+
+# Coverage directory used by tools like istanbul
+coverage
+*.lcov
+
+# nyc test coverage
+.nyc_output
+
+# Grunt intermediate storage (https://gruntjs.com/creating-plugins#storing-task-files)
+.grunt
+
+# Bower dependency directory (https://bower.io/)
+bower_components
+
+# node-waf configuration
+.lock-wscript
+
+# Compiled binary addons (https://nodejs.org/api/addons.html)
+build/Release
+
+# Dependency directories
+node_modules/
+jspm_packages/
+
+# Snowpack dependency directory (https://snowpack.dev/)
+web_modules/
+
+# TypeScript cache
+*.tsbuildinfo
+
+# Optional npm cache directory
+.npm
+
+# Optional eslint cache
+.eslintcache
+
+# Microbundle cache
+.rpt2_cache/
+.rts2_cache_cjs/
+.rts2_cache_es/
+.rts2_cache_umd/
+
+# Optional REPL history
+.node_repl_history
+
+# Output of 'npm pack'
+*.tgz
+
+# Yarn Integrity file
+.yarn-integrity
+
+# dotenv environment variables file
+.env
+.env.test
+
+# parcel-bundler cache (https://parceljs.org/)
+.cache
+.parcel-cache
+
+# Next.js build output
+.next
+
+# Nuxt.js build / generate output
+.nuxt
+dist
+
+# Gatsby files
+.cache/
+# Comment in the public line in if your project uses Gatsby and not Next.js
+# https://nextjs.org/blog/next-9-1#public-directory-support
+# public
+
+# vuepress build output
+.vuepress/dist
+
+# Serverless directories
+.serverless/
+
+# FuseBox cache
+.fusebox/
+
+# DynamoDB Local files
+.dynamodb/
+
+# TernJS port file
+.tern-port
+
+# Stores VSCode versions used for testing VSCode extensions
+.vscode-test
+
+# yarn v2
+
+.yarn/cache
+.yarn/unplugged
+.yarn/build-state.yml
+.pnp.*
+
+### PYTHON STUFF
 
 # Swap
 [._]*.s[a-v][a-z]
@@ -153,3 +275,6 @@ dmypy.json
 
 # PyCharm
 .idea/
+
+# Mac stuff
+.DS_Store

CONTRIBUTING.md

@@ -0,0 +1,101 @@
+All contributions and ideas are very welcome.
+
+If you want to work on the codebase, then although you don't have to, it is recommended to follow these prodedures to make collaborating with the codebase as painless as possible. 
+
+### 1. Clone the repo
+
+With ssh (recommended):
+```bash
+git clone [email protected]:fedden/pluribus-poker-AI.git
+```
+
+With https:
+```bash
+git clone https://github.com/fedden/pluribus-poker-AI.git
+```
+
+### 2. Initialise the repo with git flow
+
+The author use the awesome [git flow](https://github.com/nvie/gitflow), which can make [collaborating with other users a lot easier](https://nvie.com/posts/a-successful-git-branching-model/). Essentially is a collection of high level git scripts that encourage branching.
+
+Should you also want to make use of this, then follow the instructions to get it set up with the repo. You don't have to use it, but this guide will assuse you'll adopt the tools, other wise find and use the relevant git commands to do the same things.
+
+Installing on Debian/Ubuntu
+```bash
+sudo apt install git-flow
+```
+
+If you are using Mac OS X, please checkout the [install instructions](https://github.com/nvie/gitflow/wiki/Mac-OS-X).
+
+Now `cd` to the root of the pluribus repo.
+
+Run:
+```bash
+git flow init
+```
+
+This will now prompt you to set up your branches. Ensure that the "branch should be used for bringing forth production releases" is `master`, and that the "branch should be used for integration of the next release" is `develop`. Hit enter for the rest of the options to provide the defaults. Your terminal should look something like this:
+
+```bash
+$ git flow init
+
+Which branch should be used for bringing forth production releases?
+   - develop
+   - master
+Branch name for production releases: [master] master
+
+Which branch should be used for integration of the "next release"?
+   - develop
+Branch name for "next release" development: [develop] develop
+
+How to name your supporting branch prefixes?
+Feature branches? [feature/]
+Release branches? [release/]
+Hotfix branches? [hotfix/]
+Support branches? [support/]
+Version tag prefix? []
+```
+
+Once you have done this, you are ready to create feature branches to add your new feature.
+
+Feature branches are always created based of of the `develop` branch, which is our "production" branch. Periodically we will merge `develop` into `master` and this will be our stable release, for users only. To create a feature branch, run: 
+```
+git flow feature start my-feature-branch-name-here
+```
+
+You are now in your branch, add and commit to it like normal.
+```bash
+git add .
+git commit -m 'commit message here'
+git push origin feature/my-feature-branch-name-here
+```
+
+### 3. Working on your feature branch
+
+You should be based off of branch `develop` whether or not you make use of `git flow`. Commit your code like normal, and if there has been a day or more between your last commit, you may need to rebase your changes on top of the latest commits (head) of `develop`. 
+
+First fetch the latest changes from all branches (and prune any deleted branches):
+```bash
+git fetch origin -p
+```
+
+Next ensure your local `develop` has all of the changes that the remote `develop` has.
+```bash
+git rebase origin/develop develop
+```
+
+Finally ensure your feature branch has all of the changes in `develop` in it.
+```bash
+git rebase develop feature/my-feature-branch-name-here
+```
+
+When you rebase `develop` into your feature branch, you will need to force-push it to the repo. PLEASE BE EXTRA CAREFUL with this - only use force push on a feature branch that only you have worked on, otherwise you may overwrite other peoples commits, as it will directly modify the repo's git history. 
+```bash
+git push origin feature/my-feature-branch-name-here --force
+```
+
+### 4. Creating a PR
+
+Once you have wrote your cool new feature, you'll need to make a PR. If you can write any tests to support any new features introduced, this would be very welcome. If you have any conflicts with `develop` please ensure you have rebased with `develop` as instructed in step (3).
+
+Please open a pull request via the github UI and request to merge into `develop`. Once there has been a successful review of your PR, and the automated tests pass, then feel free to merge at your leisure.