Skip to content

Latest commit

 

History

History
159 lines (98 loc) · 4.12 KB

contributing.md

File metadata and controls

159 lines (98 loc) · 4.12 KB

How to Contribute

  1. Fork this repository.

a. Click on Fork.

fork1

b. Click on Create fork.

fork-2

c. Click on Code.

fork-3

d. Copy the URL. Use this URL in the next step.

fork-4

  1. Clone the forked repository, using following command

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

  2. Navigate to the repository's directory:

    cd C:/path_to_directory/examania

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

    git checkout main

  4. Create a new branch for each pull request:

    git branch new-branch-name

  5. Switch to Newly created branch.

    git checkout -b new-branch-name

  6. In new terminal type

    cd backend
npm install
npm run dev

    This will start the backend server.

  7. Open another new terminal and type

    cd frontend
npm install
npm start

    This will start the frontend server.

  8. Make required changes in source code.

  9. Stage your changes:

Check status,you should be able to see modified files in red color.

git status
git add <filename1> <filename2> <filename3>

or if you want to stage all changes

git add .

Check status, now you should be able to see staged files in green color.

git status
  1. Commit your staged changes using:
git commit -m "Your commit message here"

Replace "Your commit message here" with a descriptive message that summarizes the changes you made. Check this Conventional Commit Messages.

  1. Ensure you have correct origin(forked repo) and upstream(original repo):
git remote -v
  1. 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.

  1. Create a Pull Request(PR): On GitHub website navigate to the original repository and locate the "New Pull Request" button.

  2. If you want to make any changes after creating a PR in the same branch, Repeat steps 9 to 13.

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:

git commit -m "<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:-

git commit -m "feat(backend): Add search feature"