Version Control software is an integral factor to every software developer’s workflow and practices. Ultimately, Git is the most used version controlling system in the world; having been first created in 2005, it is still an actively maintained open-source project on the web today. As a developer, there are five extreme programming values (XP) that must always be taken into consideration when starting on a project:
- Communication
- Simplicity
- Feedback
- Courage
- Respect
Communication is fundamental to ensuring a project’s success, especially in today’s work environment where developers aren’t always in an office sitting next to each other. This is where commit messages come into play; they are important means of communication between everyone working on a project, and even more so for future developers who join. They give developers a complete overview of the project and let them know the purpose for code changes – ultimately saving them time trying to figure out the reason by staring at a screen of code.
The types of commits
It will eventually get to a point in a project where you’re going to have to look back at some of the changes that were made in the past; whether you’re trying to find when or how a bug was first introduced, or who was responsible for a certain snippet of code – all of this should be readily and easily available to you in your Git repository.
More often than not though when looking at the revision history of a project, all you’re going to see is commit messages like: “Snagging”, “Bugfix”, “Updated X file”, or even messages that take 5 minutes to read. All of these commit messages provide no information as to why and what was changed and so your only choice is to manually look through the diffs and check through the files one by one – wasting a lot of time, which could be detrimental in certain high-pressure situations.
A bad commit message is essentially just several empty words that don’t actually provide any value to the repository, or the project. Spending a little more time and crafting a relevant, descriptive message is a habit that you should start adopting. A good commit message should provide you with useful information about what has changed, and the reason behind it. Depending on your own practises and workflow will depend on how these messages are laid out, but a clear and concise summary message at the top, followed by a more in-depth message (if needed) below works well for a lot of teams.
Alongside the actual commit message, the contents of a commit can also quickly become overwhelming if not managed in a decent way. Compiling multiple changes or bug fixes into one big commit makes it lose the majority of the value and is ultimately worse than just having a bad commit message – it essentially makes your commit like a junk drawer in your home or office, a drawer that contains everything from thumbtacks to loose change – and a drawer that takes forever to find what you’re actually looking for.
A good commit contains only relevant files specific to one change. This, accompanied with a good commit message will make looking back at archived projects a lot easier and quicker for everyone. Although it can be hard to get into this mindset; with proper planning and discipline, every commit you make from now on will be informative and able to be digested by those reading it.
Branches
Branching within Version Control is another important feature that should be taken advantage of. It gives developers the ability to separate stable, working code from in-progress or broken code. When working solely on a small project, branching isn’t all that useful to begin with however, when you have an initial working model, that is where making new branches for any additional work or features becomes needed as a way to safeguard your project from any bugs or issues.
If you’re using GitHub as your version controlling software then they have a relatively simple branching strategy. The ‘main’ branch is what contains tested, and production-ready code. Any other branches (feature branches) that have been created should contain any bug fixes or new features that are being worked on. These will be merged back into the ‘main’ branch when tested and reviewed.
Taking advantage of the branching system has mostly a positive outcome regardless of the project; however, it is dependant on the size and amount of people that will be working on it to whether or not branching is actually necessary, as it can quickly become complicated if you get into the habit of making more and more branches for every little addition.
Conclusion
Git is a great tool used by the large majority of developers and businesses, and so ensuring good and relevant commits are being made each time is very important. With a little bit of effort and patience, turning a commit message like “Fixed an issue” into something descriptive and actually useful will eventually become second nature. Take some time and decide how to actually structure your commits going forward; as what works for one developer might not be the right solution for everyone.
Going forward just remember that commit messages need to be as descriptive and host as little files as possible. Once you’ve discovered a way of structuring commit messages that works for the entire team, remember to stick to it; and this in turn will make it easier to read and understand when looking back at past projects.
MORE LIKE THIS
VIEW ALL
