You've just gotten on this project and you're as excited as bells, yes? You'll want to chill a bit and do a bit of understanding guidelines on how you'll make commit messages. I've found commit messages to be very helpful as regards large projects or projects with more than one contributor. Also always add a new Question to the list of questions instead of updating the exiting one unless there's a typo.
- Step 1 - Fork this repository.
- Step 2 - Clone the repository to your local machine.
- Step 3 - Resolve the bugs, mentions provided in the Issues section of the repository. Also add a description of what changes you have done.
- Step 4 - Add the changes to your repository.
- Step 5 - Create a PULL Request. And that's all.
- You can add a new nodejs interview question.
- There are various topics like - Node Process Model , Node Crypto Module, Stubs in Node etc. You can contribute in them
- You can contribute some Learning Resources in the Readme.md File.
- You can modify previous solutions if you feel like your solution has better Time or Space complexity.
- If you find a typo in the code you can resolve them.
The point of the commit message has to do with a prefix. Commit messages should be in the format:
[Commit type]: Message(Try to stay within 50 chars)
Where:
-
Commit type: refers to one of a predefined subset of what a commit could mean. The subsets are:
- Feature: Involves adding a new feature to the product or an implementation of a specified feature.
- Chore: For changes that do not add new functionality but simply denotes a task performed. Does not have to do with bug fixes. Changes includes: initializing a new project, addition of files, partial changes that do not cause bugs, updates, etc.
- Bug: For changes fixing a bug, typo or anything that leads to correctness of the system being worked on
- Buggy: Should be avoided as much as possible but could be needed. It is used when changes have been partially implemented and execution of the current state of the project would lead to evil bugs and sinister errors. An example refers to unclosed tags and a hurried commit since you might not get access to your PC for a while. Projects with this commit type as the latest one should perhaps not be pulled or cloned except such implementation is to be continued by you.
-
Message: refers to a message describing the changes made. It is important that each commit should only reflect one feature or implementation change. You should not cram two functionalities into one commit except they depend closely on one another. For example, implementation of auth and adding views for a user profile are closely related but do not inter-depend on one another and should be separated into different commits. This is just to ensure a dev could work with states that are narrowed down to specific implementations and features.
- Must I do this: Yes
- Why: Read up
- What happens if I don't do it: Your pull request wont be merged to master branch.
- Is this the best implementation there is: Nah, I don't think so. It is subject to review and subsequent update. For now, do this.
- Has it worked so far: YEAH, I think so
- What else: Nothing
Raise an issue
Cool still raise the issue.