Skip to content

Latest commit

 

History

History
185 lines (113 loc) · 9.22 KB

CONTRIBUTING.md

File metadata and controls

185 lines (113 loc) · 9.22 KB
Raw

Contributing

Hi there! We're thrilled that you'd like to contribute to this project. Your help is essential for keeping it great.

Please note that this project is released with a Contributor Code of Conduct. By participating in this project you agree to abide by its terms.

Issues and PRs

If you have suggestions for how this project could be improved, or want to report a bug, open an issue! We'd love all and any contributions. If you have questions, too, we'd love to hear them.

We'd also love PRs. If you're thinking of a large PR, we advise opening up an issue first to talk about it, though! Look at the links below if you're not sure how to open a PR.

Submitting a pull request

  1. Fork and clone the repository.
  2. Configure and install the dependencies.
  3. Make sure the tests pass on your machine.
  4. Create a new branch: git checkout -b my-branch-name.
  5. Make your change, add tests, and make sure the tests still pass.
  6. Push to your fork and submit a pull request.
  7. Pat your self on the back and wait for your pull request to be reviewed and merged.

Here are a few things you can do that will increase the likelihood of your pull request being accepted:

  • Follow the style which is using standard.
  • Write and update tests.
  • Keep your changes as focused as possible. If there are multiple changes you would like to make that are not dependent upon each other, consider submitting them as separate pull requests.
  • Write a good commit message.

Work in Progress pull requests are also welcome to get feedback early on, or if there is something blocked you.

GIT AND GITHUB

Before continuing we want to clarify the difference between Git and Github. Git is a version control system (VCS) which is a tool to manage the history of our Source Code. GitHub is a hosting service for Git projects.

We assume you have created an account on Github and installed Git on your System.

Now tell Git your name and E-mail (used on Github) address.

 git config --global user.name "YOUR NAME"
 git config --global user.email "YOUR EMAIL ADDRESS"

This is an important step to mark your commits to your name and email.

FORK A PROJECT -

You can use github explore - https://github.com/explore to find a project that interests you and match your skills. Once you find your cool project to workon, you can make a copy of project to your account. This process is called forking a project to your Github account. On Upper right side of project page on Github, you can see -

Click on fork to create a copy of project to your account. This creates a separate copy for you to workon.

FINDING A FEATURE OR BUG TO WORKON -

Open Source projects always have something to workon and improves with each new release. You can see the issues section to find something you can solve or report a bug. The project managers always welcome new contributors and can guide you to solve the problem. You can find issues in the right section of project page.

CLONE THE FORKED PROJECT -

You have forked the project you want to contribute to your github account. To get this project on your development machine we use clone command of git.

$ git clone https://github.com/<your-account-username>/<your-forked-project>.git
Now you have the project on your local machine.

ADD A REMOTE (UPSTREAM) TO ORIGINAL PROJECT REPOSITORY

Remote means the remote location of project on Github. By cloning, we have a remote called origin which points to your forked repository. Now we will add a remote to the original repository from where we had forked.

cd <your-forked-project-folder>
git remote add upstream https://github.com/<author-account-username>/<project>.git

You will see the benefits of adding remote later.

SYNCHRONIZING YOUR FORK -

Open Source projects have a number of contributors who can push code anytime. So it is necessary to make your forked copy equal with the original repository. The remote added above called Upstream helps in this.

git checkout master
git fetch upstream
git merge upstream/master
git push origin master

The last command pushes the latest code to your forked repository on Github. The origin is the remote pointing to your forked repository on github.

CREATE A NEW BRANCH FOR A FEATURE OR BUGFIX -

Normally, all repositories have a master branch which is considered to remain stable and all new features should be made in a separate branch and after completion merged into master branch. So we should create a new branch for our feature or bugfix and start working on the issue.

$ git checkout -b <feature-branch> This will create a new branch out of master branch. Now start working on the problem and commit your changes.

git add --all
git commit -m "<commit message>"

The first command adds all the files or you can add specific files by removing -a and adding the file names. The second command gives a message to your changes so you can know in future what changes this commit makes. If you are solving an issue on original repository, you should add the issue number like #35 to your commit message. This will show the reference to commits in the issue.

Commit Message Guidelines using Commitlint

We follow a standardized commit message format using Commitlint to ensure consistency and clarity in our commit history. Each commit message should adhere to the following guidelines:

  1. Type: The commit type must be one of the following:

    • feat: A new feature or enhancement.
    • fix: A bug fix.
    • docs: Documentation changes.
    • style: Code style changes (e.g., formatting, semicolons).
    • refactor: Code refactorings with no feature changes or bug fixes.
    • test: Adding or improving tests.
    • chore: General maintenance tasks, build changes, etc.

  2. Scope (Optional): The scope provides context for the commit, indicating the specific part of the project being affected. Use a short description in lowercase (e.g., auth, navbar, README).

  3. Description: A brief and meaningful description of the changes made. Start with a capital letter and use the imperative mood (e.g., "Add new feature" instead of "Added new feature").

  4. Issue reference (Optional): Include the issue number associated with the commit (e.g., #123).

Examples:

Valid Commit Messages:

  • feat: Add user authentication feature
  • fix(auth): Resolve login page redirect issue
  • docs: Update installation instructions
  • style: Format code according to project guidelines
  • refactor(navbar): Improve responsiveness
  • test: Add unit tests for API endpoints
  • chore: Update dependencies to latest versions
  • fix: Handle edge case in data processing (#456)

Invalid Commit Messages:

  • Added new stuff
  • Fixed a bug
  • Updated code
  • auth feature update
  • chore: fixed some stuff

Commit Example with Commitlint:

git commit -m "feat(auth): Implement user signup process (#789)"

Remember to run commitlint before pushing your changes to ensure your commit messages meet the guidelines.

By following these guidelines, we can maintain a clean commit history that is easy to understand and helps us effectively track changes. If you have any questions or need further assistance, feel free to ask! Happy contributing!

REBASE YOUR FEATURE BRANCH WITH UPSTREAM-

It can happen that your feature takes time to complete and other contributors are constantly pushing code. After completing the feature your feature branch should be rebase on latest changes to upstream master branch.

git checkout <feature-branch>
git pull --rebase upstream master

Now you get the latest commits from other contributors and check that your commits are compatible with the new commits. If there are any conflicts solve them.

SQUASHING YOUR COMMITS-

You have completed the feature, but you have made a number of commits which make less sense. You should squash your commits to make good commits.

$ git rebase -i HEAD~5 This will open an editor which will allow you to squash the commits.

PUSH CODE AND CREATE A PULL REQUEST -

Till this point you have a new branch with the feature or bugfix you want in the project you had forked. Now push your new branch to your remote fork on github.

$ git push origin <feature-branch>

Now you are ready to help the project by opening a pull request means you now tell the project managers to add the feature or bugfix to original repository. You can open a pull request by clicking on green icon -

Remember your upstream base branch should be master and source should be your feature branch. Click on create pull request and add a name to your pull request. You can also describe your feature.

Awesome! You have made your first contribution. If you have any doubts please let me know in the comments.

BE OPEN

Resources