Skip to content

Latest commit

 

History

History
218 lines (140 loc) · 5.37 KB

Contributing.md

File metadata and controls

218 lines (140 loc) · 5.37 KB
Raw

Contribution Guide 💻

We recommend you to do local setup in a Linux environment. We will soon update the readme for Windows setup.

If you're reading this, you're probably creating a Pull Request or planning to do so and that's great!🥳

How to Contribute

  1. Fork this repository.

  2. Clone the forked repository.

    git clone https://github.com/<your_username>/busify.git

  3. Navigate to the project directory.

    cd busify

  4. Run the docker container with the command (make sure you have docker installed before running this).

    To Install Docker in Linux

    Guide

    Install

    To Install Docker in Windows

    Guide

    Install

    After installing docker, run the following command to start database containers.

    docker compose --env-file backend/.env up

💡Make Sure Your Docker is running/ON during the whole SetUp

  1. In new terminal type

    cd backend
npm install
npm run migrate:dev
npm run seed
npm run start:dev

    This will start the backend server.

  2. Open another new terminal and type

    cd frontend
npm install
npm run dev

    This will start the frontend server.

  3. Make changes in source code.

  4. Stage your changes and commit

 git add <filename>
  1. Commit your changes
git commit -m "<type>(optional_scope): <your_commit_message>"

  1. Push your local commits to the remote repo.

  2. git push

  3. Create a PR to develop repository.

ERROR ❎ AND SOLUTION ✅ FOR COMMON PROBLEMS DURING SETUP FOR LOGIN ISSUES 💻

  1. Please remember to include an .env file in both the frontend and backend directories. You can reference any two of the environment variables present in Discord for your configuration.

  2. Ensure Docker is running throughout the setup process. Make sure both the Redis stack and Progress components are up and running.

  3. Right-click on homepage, inspect, navigate to console, access application > cookies, delete JWT files to troubleshoot login issues.

  4. Please use ESLint for code quality checks and Prettier for consistent code formatting before submitting pull requests. This ensures a clean and readable codebase. Thank you!

ERROR ❎ AND SOLUTION ✅ FOR COMMON PROBLEMS DURING SETUP FOR BLOCKED PORT ERROR 💻

  1. To resolve port 3333 issues, use netstat to find the PID associated with it, then taskkill to terminate the process using that PID.

For Windows

netstat -ano | findstr :3333
taskkill /PID <PID> /F

For Linux

sudo lsof -i | grep 3333
kill <PID>
  1. Stop local PostgreSQL and Redis to free up ports 5432 and 6379 for Docker, or configure Docker to use different ports.

For PostfreSQL

On Windows

  net stop postgresql

On Linux

  sudo service postgresql stop

For Redis

On Windows

  net stop Redis

On Linux

  sudo service redis-server stop

For Creating a New PUll Request 💡💻

  1. Navigate to the repository's directory:

    cd <repository-directory>

  2. Ensure you are on the branch you want to use as the base branch:

 git checkout <base-branch>

  1. Create a new branch for your pull request:

    git branch <new-branch-name>

  2. To Switch to New created branch

    git checkout -b <new-branch-name>

  3. Stage and commit your changes:

    git add .
git commit -m "<type>(optional_scope): <your_commit_message>"

  4. Replace "Your commit message here" with a descriptive message that summarizes the changes you made.

  5. Push the new branch to the remote repository:

    git push origin <new-branch-name>

    This command pushes the new branch to the remote repository, making it available for others to see and review.

  • On GitHub navigate to the repository and locate the "New Pull Request" button.

Conventional Commit Messages

In our project, we follow the convention of using conventional commit messages for all commits. Conventional commit messages provide a standardized format for commit messages, making it easier to understand and track changes in our codebase.

A conventional commit message consists of a concise and structured format:

<type>(optional_scope): <your_commit_message>

The message includes a type and a description, separated by a colon. Here's a breakdown of each component:

Type: The type indicates the nature of the commit and should be selected from a predefined set of types that are relevant to the changes made. Some common types include:

  • feat: for a new feature implementation.
  • fix: for a bug fix.
  • docs: for documentation changes.
  • chore: for maintenance or general housekeeping tasks.
  • test: for adding or modifying tests.
  • refactor: for code refactoring without changing functionality.
  • style: for code style changes (e.g., formatting, indentation).

Description: The description provides a brief summary of the changes made in the commit. It should be concise but descriptive enough to understand the purpose of the commit.

Examples:-

feat(backend): Add search feature....