Git

Version control software enables teams to work in distributed and asynchronous environments, manage changes and versions of code and artifacts, and resolve merge conflicts and related anomalies.

How to Make a Good Commit

• Each commit should change a single thing.

Message

1. Separate subject from body with a blank line.
2. Limit the subject line to 50 characters.
3. Capitalize the subject line.
4. Do not end the subject line with a period.
5. Use the imperative mood in the subject line.
6. Wrap the body at 72 characters.
7. Use the body to explain what and why vs. how.

How to Make a Good Pull Request

Process:

1. Include the purpose of the Pull Request.
2. Provide an overview of why the work is taking place. Give a good background on why the change is happening.
3. Be explicit about what feedback you want, if any: a quick pair of :eyes: on the code, discussion on the technical approach, critique on design, a review of copy.

• Explicitly list how to perform validation.

4. Offering feedback
5. Familiarize yourself with the context of the issue, and reasons why this Pull Request exists.
6. Ask, don’t tell.
7. Explain your reasons why code should be changed.
8. Be aware of negative bias with online [[Communication]]. Can you use positive language as opposed to neutral?

Resources

• Conventional Commits. A specification for adding human and machine readable meaning to commit messages.
• Conventional Comments. Comments that are easy to grok and grep.
• Semantic Pull Requests. Let the robots take care of the semantic versioning.
• Conventional Changelog. Generate changelogs and release notes from a project’s commit messages and metadata
• Gitmoji. An emoji guide for your commit messages.