Looking to improve your skillset as a software engineer is always a good indicator you are passionate about developing software. One common question new developers tend to ask is whether they should commit to master branch their work. I hope this article provides you with meaningful insights into this practice.
Master branch often reflects the code used in production. Hence, it is not a good practice to commit your work to the master branch. It is recommended to branch out or create a copy of the master branch in a different branch where you will commit your work.
Note: Don’t confuse the master branch with the branch called “master”. For the sake of simplicity, the branch named “master” in most of the projects is defined as the master branch. However, based on the project and/or company you are working for, the master branch could be named differently such as “main” or “dev”.
Although committing to a master branch is a bad practice, it doesn’t mean you can’t. However, I’ll explain in depth why this practice is seen with bad eyes in the industry.
Why is it a Bad Practice?
Throughout my experience developing software and working on a variety of projects (solo projects, small company projects, and large enterprise projects), I’ve seen the following issues that happen by committing to a master branch:
Many Developers Working on a Project
When I say “many” developers, I mean more than one developer. If you are working with other developers, you will quickly find yourself in a hell merge. In other words, there will be multiple changes applied to the branch simultaneously which could or not create conflicts with your local changes.
Although you can always merge conflicts, the chances of not correctly merging conflicts correctly will increase, which could lead to the loss of good code. Also, merging conflicts often require communication between the developers who have applied changes to the master branch, which slows down development speed. Every time you commit to master branch will increase the probability of talking to your coworkers to prevent poorly resolving conflicts.
Lost Track of Specific Feature Work
For those who have been developing software for some time, you will know how slim the chances are in getting correct the first version of the code of a feature. Also, the amount of time developing the code will change based on the complexity of the feature. Therefore, making progress on a feature and committing changes is an advisable practice. It is better to have incomplete code rather than no code. This allows keeping track of all the changes made to develop a feature. It also allows other developers to continue or finish your work in case you are away for a few days, whether it is for vacations, sick days, or emergencies.
Automated Deployments Triggered in Master Branch
Depending on what company you are working for, this could apply to you or not. However, companies developing large enterprise projects often have automated deployments in place when new code is in the master branch. Hence, committing and pushing incomplete code will impact the version deployed. The good news is large enterprise companies will have several deployment stages prior to production, such as development, testing, staging, and finally production. Therefore, automated deployments will go only to the immediate lowest environment such as development or staging environment.
When is it Ok to Commit to Master Branch?
If you are working on your first few projects or have projects you like to work on during your free time and you are the only contributor, it is ok.
I Committed to Master Branch, Am I in Trouble?
The short answer is no. You are not in trouble.
There are high chances you are using Git for version control. The good news is Git lets you undo commit or go back to a previous commit. Better yet, if you committed your changes to the master branch, but you haven’t pushed those changes to your hosting repository, such as Github, you can either reset your changes or branch out and push the new branch to your repository. The good part is Git provides plenty of options to make changes in case of accidents.
Can I Prevent Committing Accidentally to a Master Branch?
There are ways to prevent from committing to a master branch. One of them is by configuring pre-commit hooks in case you want to prevent local commits. Another option used in projects with several developers using a Github repository is to set up branch protection rules.
Top comments (0)