Git - AFTER technique

Git is a powerful tool that has revolutionized the way developers manage and organize code changes. Whether you’re working on a solo project or collaborating with a team, Git allows you to track and merge changes, resolve conflicts, and undo mistakes with ease. But even with all of its capabilities, there are still ways to optimize your workflow and make the most out of Git.

In this blog post, we’re going to explore a technique called “Git-After Technique” that can help you streamline your development process and keep your codebase clean and organized. This technique focuses on committing changes after they’ve been made, rather than before, and can be especially useful for managing large and complex projects. Whether you’re a advanced Git user or just getting started, you’ll find valuable insights and tips in this guide to help you master the Git-After Technique and take your development skills to the next level.”

Adhering to best practices in Git can be a challenging task, as there are many guidelines to follow. It can be overwhelming for developers to keep track of all of them, especially when trying to implement them all at once. However, it’s important to note that it’s not necessary to follow every single best practice to achieve a successful Git workflow. It’s often more beneficial to focus on the most critical ones and gradually adopt others as the development process progresses.

AFTER technique

A - Atomic Commits

Importance of making Atomic commits that are focused on a single task or feature, and are small and self-contained. This approach ensures that the codebase is always in a stable state and that changes are easy to understand and review.

For example, imagine you’re working on a new feature for a website that involves updating the layout and adding a new button. Instead of committing everything at once, you can break it down into two commits:

The first commit focuses on updating the layout. It includes changes to the HTML, CSS, and JavaScript files that are related to the layout. This commit is small, self-contained and easy to understand.

The second commit focuses on adding the new button. It includes changes to the HTML, CSS, and JavaScript files that are related to the new button. This commit is small, self-contained and easy to understand.

By breaking the changes down into two smaller commits, it’s easy to understand the changes and review them. Also, if something goes wrong, it’s easy to revert back to a previous version.

F - Frequent Commits

It would be best if you commit your changes early and often. Anytime you complete a part of code that complies and run, prefer to commit.

You shouldn’t worry about making “too many” commits. You can commit locally “all the time,” and you need to push when everything is working. Early commit helps to cut the risk of conflicts between two concurrent changes. Additionally, having periodic checkpoints means that you can understand how you broke something.

If you do small commits, your message will be clear and focused. And it will be easy for other developers to understand the code history. Here are a few benefits of frequent commits:

Collaboration: Committing your code often makes it easy for other team members to see your progress and collaborate with you. This can help to ensure that everyone is on the same page and that the codebase is always up-to-date.

Conflict Resolution: By committing often, you can avoid conflicts when merging changes with other team members. This is because conflicts are more likely to occur when multiple changes are made to the same file at the same time. By committing your changes often, you can reduce the chances of conflicts occurring.

Rollback: If a problem arises with the codebase, it’s essential to have a way to rollback to a previous version. With frequent commits, it’s easy to find the last known good version and revert to that. This can save time and help to keep the codebase stable.

Traceability: Frequent commits allow you to track the changes made to the codebase and understand how it evolved over time. It’s easier to understand the context of the change and the reason behind it.

For example, imagine you’re working on a new feature for a website. Instead of working on the feature for a week and committing everything at once, you commit your changes every day. This way, your team can see your progress, you can avoid conflicts and if something goes wrong, it’s easy to rollback to a previous version.

T - Test before you push

We are all human and can make mistake. It’s always good to test your changes before you commit them to your local repository and specially push to the remote repository.

Testing is essentially an extra layer of security before you commit. It allows you to identify mistakes and bugs quicker before they go to your production server.

As a developer, you should spend time doing the right thing in the first place. Instead of relying on the QA team to find every bug, a good developer tests his code.

It’s important to note that testing is an ongoing process and should be done throughout the development cycle, not just before pushing. By testing your code before pushing, you can ensure that the codebase is always in a stable state and that any issues are caught early. This can save time and improve the overall quality of the codebase.

E - Enforce Standards

Enforcing standards is an important aspect of maintaining a consistent codebase. It ensures that the code is readable and easy to understand, making it easier to collaborate with others. Here are a few ways to enforce standards in your Git workflow:

Linting: Linting is the process of checking your code for potential issues. It can catch common errors, such as syntax errors, and help to enforce coding conventions. There are several linting tools available, such as ESLint for JavaScript and Flake8 for Python.

Code Formatting: Code formatting tools automatically format your code to a consistent style. This can be done for indentation, whitespace, and other formatting options. Popular formatting tools include Prettier for JavaScript and Black for Python.

Code Reviews: Code reviews can be a powerful tool for enforcing standards. By reviewing each other’s code, team members can catch potential issues and ensure that the code adheres to conventions. This also promotes knowledge sharing among the team.

Style Guides: Having a style guide that contains the conventions and guidelines for the project, can be helpful for everyone in the team to follow. This can include information on naming conventions, commenting, and other best practices.

Automated checks: You can set up automated checks that run before a code is pushed to the remote repository. These checks can include linting, code formatting, and test automation. This can help to catch issues early in the development process and ensure that the code adheres to conventions.

Git allows us to enforce standards by using hooks. Hooks are scripts that run automatically at certain points in the Git process. By using hooks, you can enforce coding standards such as running a linter or formatter, or to validate that the code passes tests before it is committed. This helps to ensure that the codebase is consistent and maintainable, and that any issues are caught early on.

R - Review

Reviewing your code before pushing is an important step in the development process. This can help to catch any issues or bugs early on, and also to ensure that the code is maintainable and follows established coding standards. When you review your code, you can look for things like:

• Proper indentation and formatting
• Proper naming conventions
• Proper use of control flow statements and data structures
• Proper use of libraries and frameworks
• Proper error handling
• Proper use of comments

By reviewing your code, you can ensure that it is well-written, easy to understand, and maintainable. This can help to improve the overall quality of the codebase and make it easier to work on in the future.

Additionally, if you are working in a team, code reviews can be an efficient way to share knowledge and learn from other team members. It also helps to ensure that everyone is on the same page and that the codebase is consistent.