Learning Good Practices For Git

This guide will provide you with a solid foundation for adopting best practices in using Git, a version control system essential in software development. Good practices in Git are fundamental to maintaining a clean, traceable, and understandable change history, which in turn contributes to more efficient collaboration and the creation of higher-quality software.

I will focus on the Conventional Commits specification, a standard that facilitates writing clear and concise commit messages, following a predefined structure. By adopting this standard, you will improve communication among team members, automate processes such as changelog generation, and facilitate version management.

How to Write Commits Correctly

The format of a Conventional Commit is as follows:

<type>[optional: (scope)]: <description>

[optional: body]

[optional: footer]

Where:

Type: This is an identifier that indicates the type of change being introduced. Common types include:
- feat: Adds or remove a new feature.
- fix: Bug fix.
- chore: Changes to the build process or auxiliary tools.
- docs: Commits that affect documentation only.
- style: Changes that do not affect the meaning of the code, such as whitespace, formatting, missing semicolons, etc.
- refactor: Rewrite / restructure your code, however does not change any API behaviou.
- perf: Code change that improves performance.
- test: Adding missing tests or correcting existing ones.
Scope (optional): This is an identifier that indicates the section of the code that is affected by the commit.
Breaking Changes Indicator (optional): Breaking changes should be indicated by an ! before the : in the subject line e.g. feat(api)!: remove status endpoint
Description: This is a brief description of the changes introduced in the commit. It should be clear and concise.
Body (optional): This is a more detailed description of the changes introduced in the commit. It is written after the description and after leaving a blank line.
Footer (optional): This is used to reference issue numbers that are closed with the commit.

Here are some examples:

A new feature: Add new endpoint for login. Include tests and documentation.
```
feat(user-auth): add login functionality
```
A bug fix: This commit fixes the server crash that was happening because of an undefined variable.
```
fix(server): fix server crash on startup
```
A documentation change: This commit adds more details to the installation instructions in the README file.
```
docs(readme): update installation instructions
```

How to Name Your Branches Effectively

Like commit messages, branch names play a crucial role in organizing and understanding your development history. A good practice is to follow a naming convention that reflects the purpose of the branch. 7

<type>/<branch-name>

Where:

Type: As in commits, the type indicates the primary purpose of the branch. The same types as in Conventional Commits are usually used.
Branch name: A concise and descriptive description of the changes being implemented in the branch. Use hyphens (-) to separate words and avoid using uppercase letters.

Examples

New search functionality: feature/search-bar
Fixing a bug in the registration form: fix/registration-form-validation
Refactoring authentication code: refactor/authentication-code
Updating API documentation: docs/api-documentation