Greenfield

This is a repo for MKS-39 students' Greenfield project.

Please see our CONTRIBUTIONS.md if you would like to contribute.

STACK: ————-------------------------------- React -- Node -- Express -- MongoDB

For front-end design : React-Bookstrap

TEAM DEVELOPMENT ROLES

• Mongo Master: Ricardo
• Express Expert: Tim
• Front End / React: Kyhan
• React Reverend: Tony
• Full Stack Savant: Ashley

#gitGeneral Workflow

1. Clone down the master directly (do not fork):

-> git clone masterURL yourdirectory

2. Create a new feature branch from master, If it's a new feature, name the branch "feat#". If it's a bug fix, name the branch "bug#". # should be the associated issue number on the GitHub repo.

-> git checkout -b feat3 OR -> git checkout -b bug11

3. Make changes and commit to your feature branch.

-> git add -p

4. Commit changes (see commit message guidelines below)

-> git commit -m 'message'

5. Sync up with latest master before pushing to remote feature branch:

-> git pull --rebase origin master

6. Fix any merge conflicts if necessary.

7. Push changes to remote feature branch:

-> git push origin feat3

8. Generate pull request:

-> base: master -> compare: feat3

9. Fix any issues highlighted by reviewer if necessary.

10. When everything checks out, reviewer merges pull request to master.

11. When a pull request is merged and closed, delete feat3 branch.

Detailed Workflow

Cut a namespaced feature branch from master

Your branch should follow this naming convention:

• bug#
• feat#
• test#
• doc#
• refactor#

Where # associates directly with the issue number in the GitHub repo

These commands will help you do this:

Creates your branch and brings you there

git checkout -b your-branch-name

Make commits to your feature branch.

Prefix each commit like so

• (feat) Added a new feature
• (fix) Fixed inconsistent tests [Fixes #0]
• (refactor) ...
• (cleanup) ...
• (test) ...
• (doc) ...

Make changes and commits on your branch, and make sure that you only make changes that are relevant to this branch. If you find yourself making unrelated changes, make a new branch for those changes.

Commit Message Guidelines

• Commit messages should be written in the present tense; e.g. "Fix continuous integration script".
• 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.
• 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.

Rebase upstream changes into your branch

Once you are done making changes, you can begin the process of getting your code merged into the main repo. Step 1 is to rebase upstream changes to the master branch into yours by running this command from your branch:

git pull --rebase origin master

This will continue the rebasing process. Once you are done fixing all conflicts you should run the existing tests to make sure you didn’t break anything, then run your new tests (there are new tests, right?) and make sure they work also.

If rebasing broke anything, fix it, then repeat the above process until you get here again and nothing is broken and all the tests pass.

Make a pull request

Make a clear pull request from your fork and branch to the upstream master branch, detailing exactly what changes you made and what feature this should add. The clearer your pull request is the faster you can get your changes incorporated into this repo.

At least one other person MUST give your changes a code review, and once they are satisfied they will merge your changes into upstream. Alternatively, they may have some requested changes. You should make more commits to your branch to fix these, then follow this process again from rebasing onwards.

Note: A pull request will be immediately rejected if there are any conflicts!

Once you get back here, make a comment requesting further review and someone will look at your code again. If they like it, it will get merged, else, just repeat again.

Thanks for contributing!

Guidelines

1. Uphold the current code standard:
   • Keep your code DRY.
   • Apply the boy scout rule.
   • Follow STYLE-GUIDE.md
2. Run the tests before submitting a pull request.
3. Tests are very, very important. Submit tests if your pull request contains new, testable behavior.
4. Your pull request is comprised of a single (squashed) commit.

Checklist:

This is just to help you organize your process

• Did I cut my work branch off of master (don't cut new branches from existing feature brances)?
• Did I follow the correct naming convention for my branch?
• Is my branch focused on a single main change?
• Do all of my changes directly relate to this change?
• Did I rebase the upstream master branch after I finished all my work?
• Did I write a clear pull request message detailing what changes I made?
• Did I get a code review?
• Did I make any requested changes from that code review?

If you follow all of these guidelines and make good changes, you should have no problem getting your changes merged in.