# Git practices

Understanding how to structure your Git workflow using branches and effectively communicate changes through well-crafted commit messages is crucial for collaboration and code management. Let's explore the essence of effective git branching and commit message practices, alongside the principles of micro commits:

## Git Branching Best Practices <a href="#gitpractices-gitbranchingbestpractices" id="gitpractices-gitbranchingbestpractices"></a>

* **Using hyphens and slashes as separators**: Hyphens and slashes can help structure branch names and improve readability.
* **Using numbers**: Incorporating numbers can provide additional context or ordering information for branches with similar names.
* **Using category words**: Including category words like "feature," "bugfix," "hotfix," or "refactor" in branch names clarifies their purpose at a glance.
  * **Feature branches**: Feature branches are dedicated to developing new features. They are created from the `develop` branch and follow the naming convention: `feature/<JIRA ITEM>-<optional short description>`
  * **Bug fix branches**: Bug fix branches address specific issues and are spawned from the `develop` branch. They adhere to the naming convention: `bugfix/<JIRA ITEM>-<optional short description>`
  * **Hotfix branches**: Hotfix branches are reserved for urgent fixes that require immediate deployment. They use the naming convention: `hotfix/<optional short description>`
  * **Refactor branches**: Refactor branches focus on code restructuring and improvement. They follow the naming convention: `refactor/<JIRA ITEM>-<optional short description>`
* **Name length**: Keep branch names concise while ensuring they convey the necessary information.
* **Using several naming conventions together**: Combining different naming conventions can provide comprehensive context and improve branch management.

## Creating commit Messages <a href="#gitpractices-creatingcommitmessages" id="gitpractices-creatingcommitmessages"></a>

* **Separate subject from body**: Begin your commit message with a succinct one-line summary (the subject) followed by a blank line and then a more detailed explanation if necessary (the body).
* **Use imperative mood**: Write the subject line in imperative mood (e.g., "Fix", "Add", "Update") rather than past tense or present tense. It helps in clearly stating what the commit does.
* **Be concise and specific**: Keep your subject line short (around 50 characters or less) but informative. It should quickly convey the essence of the change.
* **Include relevant issue identifiers**: If your project uses issue tracking systems like JIRA, GitHub issues, or others, include the relevant issue number or identifier in your commit message. This helps in tracing the context and history of changes.
* **Provide context and why**: In the body of the commit message, explain the reasons behind the change and any relevant context. Describe the problem being addressed and why the change is necessary.
* **Format consistently**: Maintain a consistent commit message format throughout your project or team. Consistency makes it easier to scan through commit logs and understand changes.
* **Proofread and revise**: Before finalizing your commit message, review it to ensure clarity and correctness. Avoid typos, ambiguous language, or unnecessary information.
* **Use structural elements**: The commit message can contains the following structural elements, to communicate intent to the consumers of your library:
  * **fix:** a commit of the *type* `fix` patches a bug in your codebase (this correlates with `PATCH` in Semantic Versioning).
  * **feat:** a commit of the *type* `feat` introduces a new feature to the codebase (this correlates with `MINOR` in Semantic Versioning).
  * `build:`, `chore:`, `ci:`, `docs:`, `style:`, `refactor:`, `perf:`, `test:`

<br>


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.leapwise.co/backend-handbook/development-tools-and-environment/git-practices.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.