As a beginner programmer, you can be surprised to see that people care so much about what goes into the git repository. Or worst, you can be wholly unaware & do your thing full of: * fix the bug
* another attempt
* another attempt * another attempt * ! 2 2 finally while being judged on it from behind. I check repo history whenever there is a job applicant, and they share a GitHub profile or some example work. My main question is - do they already know to keep the repository neat, or it's something we will have to work on when they join the team. Why so much Fuss? There is a big difference between the Git repository of a mature project and a repository created by an inexperienced developer. In a mature project, you can: Write a changelog or release notes based on the git history alone Revert some changes if necessary, with only the conflicts that couldn't be avoided Get the idea of what was merged by just seeing the git log Those uses case appear days or weeks after you merged the changes. If the commit history is a mess, you won't get much out of it anyway. As a beginner programmer working on a small project, you won't see much value on your own. Most likely, you will need someone more experienced to point it out to you. Focus your Commit on one Thing Alone A good commit does one thing alone. It's tempting to mix different changes, for example: Update coding style Implement a change Implement an unrelated change that happens to be in the same file Doing this makes two things more complicated than necessary: Writing short & accurate commit message Reverting only one of those changes Write Meaningful Commit Messages Think about the reader of your commit message. Even if you work alone, in a few months: You can forget everything about the change You can have a new colleague join the team Write a short commit message that quickly summarizes what's in the commit. If you did an excellent job following the previous advice, this should be pretty easy. Reference Ticket or Issue Reference tickets from the commit message if you have an issue tracking system set up for the project (for example, Jira). In this way, whoever wants to understand your changes better will have something to follow. If your project has no such system yet, you can consider setting up some. Both GitHub & GitLab have some available. Keep your Commit Messages Consistent When you scan or search through the git log, any inconsistency gets annoying pretty quickly. If some commits are capitalized differently than the rest - they get your attention for the wrong reason. If sometimes the verbs are in the past tense - your search should include both versions. If you want to make a changelog or release info - the inconsistencies will need to be edited before sending it out, and it's just simpler to do it on the commit time. How to do all of that? You want to commit locally as often as you see fit. Luckily, you don't have to write a perfect commit message in the first go. Write the commit messages for your work in progress so you can understand on the spot, and later edit them to get the final version. It's best to learn , as it's the most flexible method for editing your commits. It can be very difficult at first but knowing it is a good investment in the long term. git rebase As a more straightforward tool, when you have only one commit & want to rephrase the message, you could do it with . git commit --amend Learning resource All this is a step up from the basic pull-commit-push workflow you learn first. Resources I recommend for learning more: good explanation - both text & visuals 7 rules for good commit message Summary I hope I convinced you to put some effort into creating meaningful commits. Now, good luck learning how to do it! First Published here

Different

Keep

How to Decide Whether to Leave or Stay at Your Current Workplace During the Great Resignation

Newsletter

Too Long; Didn't Read

Make resilience your competitive advantage

The Right Way to Use Git

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

3 Steps to Adding End-to-end Tests to Your Project

10 GitHub Repositories to Follow

3 Easy Steps to Change Main Git Branch on Heroku

28 Stories To Learn About Markdown

194 Stories To Learn About Git

3 Steps to Adding End-to-end Tests to Your Project

10 GitHub Repositories to Follow

3 Easy Steps to Change Main Git Branch on Heroku

28 Stories To Learn About Markdown

194 Stories To Learn About Git

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps