Table of Contents
This is an example of how you go about setting up our project locally. To get a local copy up and run follow these simple example steps.
- Node.js: Download
- Git: Download
- MongoDB Atlas: MongoDB Account & Secret Key
-
Clone the repo
git clone https://github.com/kbventures/ecommerce.git
-
Go to cloned folder
cd ecommerce
-
Install NPM packages in client and server folder
cd client npm install cd ../server npm install
-
Change client URL
-
Change Server URLS
-
Add .env file inside server directory
MONGO_URI=YOUR_SECRET_KEY
- Start Client
cd client npm run dev
- Start Server
cd .. cd server npm run dev
- Go to http://localhost:8080/ if you wanna see client, or http://localhost:4001/ for server
cd server
npm run test
cd server
npm run build
cd client
npm run build
As a team we learned to work continuously and asynchronouslyl on designing, developing, testing, deploying a full stack application with third party intergration. We expanded our knowledge of React, Express.js, MongoDB, Node.js, Webpack, several deployment solutions, CDIC, development preview branch, mono repos, automated testing, Typescript, documentation, linting, coordinating as a team, code reviews, CSS Modules, CSS design systems, communication, Design, Figma, managing a project(Github project) etc.
[Tell what was hard in the process of building the project. Tell about where have you feel stuck and how did you overcome this.]
Example:
When I tried to connect to the third-party API, I was not sure how to use fetch and what is the difference between async/await, what are Promises and how to use them. After some Googling I found out the MDN documentation about async/await and tried to use it in practice - it worked!
- [] MVP
- [ ]
- [ ]
See the open issues for a full list of proposed features (and known issues).
-
Clone the repository with this command if you don't have it:
git clone https://github.com/kbventures/ecommerce.git
-
Run the following command to make sure you have the latest changes on the main branch
git pull
-
Create a new feature branch with a descriptive name and only make your changes here. For example, to add this README documentation I would call this branch
add-git-workflow
.git checkout -b <your feature branch name>
-
Make as many changes as you need in your feature branch. You can use the following commands per commit message.
git add . git status git commit -m <your commit message>
-
Once your feature is ready and you're ready to merge into the main branch first make sure to push your local branch changes to GitHub's computers.
git push --set-upstream origin <your feature branch name>
-
Go to https://github.com/kbventures/ecommerce/branches and you should see your newly pushed feature branch. Find and click the button "New pull request" to request for your changes to be "pulled" into the main branch.
-
When you click the button, complete the form required for each pull request and click "Create pull request".
-
In the top-right corner click "Reviewers" and add one person on the team as a reviewer for the pull request.
-
Once the Reviewer has looked at your pull request and verified everything is OK, they will merge your pull request into the main branch.
-
From within your feature branch, fetch the latest changes from the main branch
git fetch origin main
-
Rebase so that your feature branch history is stacked on top of the latest main branch history
git rebase origin/main
-
Now resolve the conflicts manually in your code editor one at a time. Git will tell you which files have a conflict. Once you've resolved the conflicts run the following commands:
git add . git rebase --continue
-
Write and save a commit message if all conflicts are resolved.
-
Push your rebased feature branch changes to GitHub's computers.
git push -f origin <your feature branch name>
-
Go back to your pull request on Github your pull request should have no conflicts and you can merge into the main branch!
Also, don't forget the most important rule of rebasing:
NEVER REBASE ON A REMOTE BRANCH >
Why do we care to write a good commit message? A well-crafted Git commit message is the best way to communicate context about a change to other developers working on that project, and indeed, to your future self.
A commit has two parts: a subject (max 50 characters) and a description. Use the following command to separate a subject from the description.
git commit -m "Subject" -m "Description..."
In each commit message:
-
Specify the type of commit in the subject. Example:
Feat: create landing page
.- feat: The new feature you're adding to a particular application
- fix: A bug fix
- style: Feature and updates related to styling
- refactor: Refactoring a specific section of the codebase
- test: Everything related to testing
- docs: Everything related to documentation
- chore: Regular code maintenance.
-
Separate the subject from the body
-
Remove whitespace errors
-
Remove unnecessary punctuation marks
-
Do not end the subject line with a period
-
Capitalize the subject line and each paragraph
-
Use the body to explain what changes you have made and why you made them.
-
Do not assume the reviewer understands what the original problem was, ensure you add it.
-
Do not think your code is self-explanatory
We are grouping by feature as listed in React docs. See Grouping by features or routes
We are using ESLint with Airbnb rules, alongside Prettier to format code and follow modern standarts when writhing Javascript In addition, we can minimize runtime errors.
We are using husky to use create git hooks to run linting pre-commit and automated tests pre-push that will stop the respective git command if the checks fail.
Distributed under the MIT License. See LICENSE for more information.
Ken Beaudin - @kb9700