COMMIT NAMING
Naming commits is an essential practice in version control using Git, as it helps you and your collaborators understand the purpose and context of each commit. Here are some best practices for naming commits:
Be Descriptive: The commit message should clearly describe what the commit does or what problem it solves. It's an opportunity to provide context and explain the changes.
Use the Imperative Mood: Write commit messages in the imperative mood. For example, "Add a feature" or "Fix a bug" rather than "Added a feature" or "Fixing a bug." This style is a convention in many open-source projects and is more concise and direct.
Keep It Short: While being descriptive, strive to keep commit messages relatively short. Ideally, they should fit within a single line or wrap at around 72 characters. If you need more detail, provide it in the commit body.
Use a Prefix: Some projects or teams use prefixes in their commit messages to indicate the type or category of the change. For example:
feat:for new featuresfix:for bug fixesdocs:for documentation changesstyle:for code style/formatting changesrefactor:for code refactoringtest:for adding or modifying testschore:for maintenance tasks or non-code changes
Reference Issues: If your project uses an issue tracking system (e.g., GitHub issues or JIRA), it's helpful to reference the relevant issue in your commit message. You can do this by including the issue number, e.g., "Fix issue #123" or "Closes #456."
Wrap Body Text: If your commit message requires a more detailed explanation, include a separate commit body below the short summary. Use a blank line between the summary and the body. In the body, provide additional context, reasoning, or details about the changes made.
Here's an example of a well-structured commit message:
feat: Add user authentication
This commit adds user authentication to the application. Users can now create accounts, log in, and access personalized content.
Closes #34
By following these best practices, you'll make your Git commit history more understandable and maintainable, which is crucial for effective collaboration and tracking the history of your project.
Creating A Pull Request
Never create pull requests on the main branch.
Creating a pull request directly into the main branch (usually called master or main) is generally discouraged for several important reasons:
Risk of Breaking the Main Branch: The main branch is typically the stable, production-ready branch of your project. Making changes directly to it without proper testing can introduce bugs or other issues that disrupt the functioning of your software. Pull requests allow you to test and review changes before merging them into the main branch.
Lack of Code Review: Pull requests facilitate code reviews, which are essential for maintaining code quality, consistency, and security. By creating a pull request, your changes can be reviewed by team members or contributors, and any potential issues can be identified and addressed before merging.
Version Control and History: Pull requests help maintain a clean version control history. By working on feature branches and creating pull requests, you ensure that the commit history remains organized and that changes are well-documented. This makes it easier to understand the history of your project.
Collaboration and Coordination: Pull requests encourage collaboration and coordination among team members. They provide a structured way to discuss and refine changes, share knowledge, and ensure that everyone is on the same page regarding the modifications being made to the codebase.
Continuous Integration (CI) and Testing: Many projects have CI systems in place that run automated tests on pull requests. This ensures that the changes introduced by a pull request do not break existing functionality. Creating a pull request allows you to benefit from these automated checks.
Preservation of the Main Branch: Keeping the main branch stable is crucial for continuous deployment and production readiness. By not creating pull requests directly into the main branch, you prevent untested or incomplete code from being introduced.
Reverting Changes: If a direct change to the main branch causes problems, it can be challenging to quickly revert those changes. Pull requests make it easier to identify and roll back problematic changes by simply closing the pull request.
SHOULD WE WAIT FOR THE ISSUE ASSIGNMENT
In most cases, there's no need to wait for it. It depends on the repository's guidelines.
WHEN NOT TO WAIT FOR ASSIGNMENT
If repository rules allow immediate action, you can proceed.
WHEN TO WAIT FOR ASSIGNMENT
You should wait for the assignment if the project's guidelines require it.
example: NOVU REPO. RULES
When to ask for an assignment:
No one has requested an issue assignment.
The assigned person has been inactive for an extended period.
When to Self-assign Issue
TYPES OF ISSUE
BUG IN PROJECT
- A bug is an obvious issue, such as a non-functional button, that requires fixing. If the issue doesn't already exist, you can create one and send a pull request to resolve it.
CREATION OF FEATURE
- When a non-maintainer creates a feature request, it's important to confirm its necessity with the maintainer. Unnecessary features waste effort from contributors if they're not merged. This can seem like a forced contribution.
REVIEW PAST ISSUE
Before creating a new issue, please ensure that a similar issue hasn't been opened or resolved.
This helps streamline the maintainer's tasks. 🙂
Understand Issue Requirements
Additionally, read the entire discussion.
Conditions:
Ensure you possess the necessary skills to address the issue. If not, and project guidelines necessitate user assignment, your lack of skill can lead to unnecessary reassignments due to inactivity, wasting the time of valuable contributors and maintainers.
Be aware of potential invalid(doesn't meet requirements) contributions that may result in pull requests not being accepted.
Avoid Spamming
Creating empty pull requests.
If you want to practice, consider working in repositories that welcome beginners, such as Eddie Hub, or submit pull requests to a friend's repository.
Avoid Unnecessary Pull Requests
If an issue already has an open PR, refrain from creating a new one unless you are certain you can offer a better solution or the existing one is incorrect.
Test Before Release
Do your changes work?