Skip to content

Latest commit

 

History

History
86 lines (57 loc) · 4.16 KB

CONTRIBUTING.md

File metadata and controls

86 lines (57 loc) · 4.16 KB
Raw

Contributing Guidelines

As a team member working on this project, we care about clean and efficient management of our codebase. Please follow these important guidelines while contributing code to this repo.

Submitting a Pull Request

Good pull requests, whether patches, improvements or new features are a fantastic help and keep our project happy, healthy and wise. They should remain focused in scope and avoid containing unrelated commits.

Here is a summary of the steps to follow:

  1. All working branches must be created from the develop branch and all pull requests must be made into this branch. Refer the branch naming guidelines.
$ git checkout -b <working-branch-name>
  1. Make sure to pull all latest changes regularly to keep your working branch in sync and updated.
$ git pull origin develop
  1. Follow the commit message guidelines while making your commits.
  2. Open a Pull Request with a clear title and description. The title should give an overview of the feature, change or fix while the description must give elaborated details of the same.
  3. Make sure to mark atleast 3 team members as a reviewer on your pull request.
  4. For ambitious tasks, open a Draft Pull Request as soon as possible in order to get continuous feedback and help from the team. Mark it 'Ready For Review' once you've completed all code changes.

Naming Branches

  1. Use kebab-case while naming your branches. All words must be in lowercase and separated by hyphens. For example, profile-page or navbar-component.
  2. Always make sure that another team member is not working on a similarly named branch before you create a working branch.

Commit Messages

1. Clear & Concise Commits

  • Each commit should correspond to a specific functional change.
  • Ideally a commit should not create an inconsistent state (such as test errors, linting errors, partial fix, etc.)
  • A complex feature should be broken down into multiple commits as long as each one keeps a consistent state and consists of a self-contained change.
  • Avoid using git add . while committing changes, rather add only the relevant files or folders to your commit.
  • Maintain a practice of committing regularly as you cross milestones of your task.
  • Make sure you do not add any build files, node modules or secure config files to your commit.

2. Commit message format

A good commit message starts with one of the following verbs:

  • Add feature x
  • Remove feature y
  • Update feature z
  • Refactor function x
  • Fix crazy bug
  • Revert previous change

Or any other verb that clearly indicates the type of change being made.

Always use the verbs in Imperative Present tense. Don’t use Past or Present Continuous tenses for commits.

  • Add feature xyz ✔️
  • Added feature xyz ❌
  • Adds feature xyz ❌
  • Adding feature xyz ❌

3. Commit Author

Make sure your name and email ID are configured correctly in your git config so that your commits are authored correctly.

To check if the user name and email is set correctly

$ git config user.name
$ git config user.email

To set a user name or email

$ git config --global user.name "Your Name"
$ git config --global user.email "[email protected]"

4. Tagging Issues

If your commit is related to an existing issue listed on the repo, you can tag it using the issue number. If your commit completely fixes or resolves an existing issue listed on the repo, you can auto-close it with a reference. For example, Fix #100. You can also use the keywords "Close" or "Resolve".

You may also link issues manually once you've opened a pull request.