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!🥳
-
Fork this repository.
-
Clone the forked repository.
git clone https://github.com/<your_username>/BSoC-Website.git
-
Navigate to the project directory.
cd BSoC-Website
-
Create a New Branch
git checkout -b <new-branch-name>
-
Download Required Packages by running.
npm i
Note: It will take a couple of minutes(literally), be patient, ignore the warnings
-
Start the Server by Running.
npm run serve
-
Make changes in source code.
-
Stage your changes and commit
git add <filename>
-
Commit your changes
git commit -m "<type>(optional_scope): <your_commit_message>"
See Conventional Commit Messages for convention
-
Push your local commits to the remote repo.
-
git push
-
Create a PR to develop repository.
-
Navigate to the repository's directory:
cd <repository-directory>
-
Ensure you are on the branch you want to use as the base branch:
git checkout <base-branch>
-
Create a new branch for your pull request:
git branch <new-branch-name>
-
To Switch to New created branch
git checkout -b <new-branch-name>
-
Stage and commit your changes:
git add . git commit -m "Your commit message here"
-
Replace "Your commit message here" with a descriptive message that summarizes the changes you made, Make sure to follow the convention.
-
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.
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).
- perf: for performance optimisations.
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.
git commit -m "feat(frontend): Add navbar...."