We engineers at HARMAN write code all the time. The question is how to translate this code to make an impact and deliver complex insight-led automotive solutions. Are we taking the right approach to handle the vast amounts of code?
If someone writes even the best implementation code ever but does not push it into the mainline branch, no one can use it. It is like poetry written for the desk drawer. It may be beautiful, but no one can enjoy it. The same goes for code.
The commit terminology was used since the 70s. In Git, we talk about push and in Gitlab, it is a merge request; these are different words to say the same - take my code and publish it.
Advantages of daily commits:
- Developing a daily commit practice reduces the amount of technical debt
- Allowing other engineers to access and enhance your code
- As Git is a source control tool, we want to let it do what it does best – control our source. Instead of having tens of different archeological files we can use this tool to track our history
- Backup on the server
- When working on an integration branch, you can later squash all the history into one final commit record along with an informative, accurate commit message
- If you have not commit anything and in the event of your unforeseen absence, other people can still try to integrate with your precious code
- Automatic tools, unit tests and other scanners can run on the nightly cycle to test the code for you. Even if you did not write your own tests, the tools could check for other problems that may have been caused
- If you wrote some infrastructure or a utility other engineers can start using it and testing it for you
- Small commits mean smaller code reviews. This allows for a more focused, higher quality review
- Small commits can come along with small-scale unit tests which are easier to write than on bigger commits
Drawbacks of daily commits:
- When you commit and push daily, you might push not fully thought-through features. It may contain unpolished pieces of code, comments, TODOs and different types of thoughts
- Daily commits might create some waste. If during early integration, a need for a change was found, you will have to work again to apply it
- Overhead on commit procedures
- Developers might feel that they are writing less code. This is more a problem from the human psychology domain
In one of the bigger projects I was working on, there was an idiom saying, “we will meet in the integration.” Yes, each one of us was working happily on a different part of the project. We had very good design documents. They were even reviewed. We defined all the required interfaces. But every time someone tried to coordinate with someone else we got the same answer: “Don’t wait for me, let’s meet in the integration.” Well, as you can guess, we all met in the integration phase. We connected so many pieces. On paper, it looked great, but we saw that there were many small changes from the original designs. It took us long weeks to figure out what interfaces need to be updated and to fix them one by one. This is another reason for frequent commits. It allows in performing the integration earlier, in smaller chunks and getting the feedback faster.
If you are tempted now to use this article as an excuse to commit at the end of every day, the messiest code you have written, remember the rule of “don’t be stupid on purpose.”
Committing to a local branch is all for beginners. Making your code accessible to all in an integration branch is for experts. Real pros push to main!
Well, if it was not clear until now, the recommendation is to complete small pieces of the code that do what we expect it to and not harm others parts, and also push them to the integration or mainline branch every day.
Some additional reading:
I would like to know your thoughts, please leave me a line here or on LinkedIn/Twitter
