Table of Contents
MTrade is a crypto exchange trade analysis web application which enables users with crypto exchange API keys to obtain select data from their account, obtain a mindful analysis and easy to understand data visualisations.
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.
- Clone the repo
git clone https://github.com/kbventures/next-mtrade.git
- Go to cloned folder
cd next-mtrade
- Install NPM packages
npm install
- Add .env file inside server directory
JWT_SECRET="secret" NEXTAUTH_URL="http://localhost:3000/" DATABASE_URL="file:./dev.db"
- Start App
npm run dev
- Go to http://localhost:300/ if you wanna see client
- Terminal
npm run test
- Terminal
npm run build
- Terminal
npm run start
- Settin up unit, intergration& e2e tests
- Postgresql using a object relationnal maper Prisma.
- Next.js advanced concept like Edge runtime
- Typescript
- Internationalization with next-i18-next
- Authentication with next-auth
Example:
- 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/next-mtrade
-
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