How to commit better with Git
Вставка
- Опубліковано 5 лют 2025
- Commits are the visible blocks of work of a programmer’s craft. Yet it seems that so little effort goes toward crafting a good git commit. In this video, I will talk about why I think it is important to care more about the commits that we push into the world.
In this tutorial, I will talk about how you can write better commit messages and what the git best practices are, and how they relate to the GitHub commit message conventions. We will dissect the anatomy of a good commit message and look into how you can use interactive rebase to reformat and combine the commits you want to push to your git repository after the fact.
🙏 Support me: / kiecodes
🛰 Join our Discord, to interact with other Coders and me: / discord
Check out my newest video: • How to use the OpenAI ...
Questions of the day
■ Do you have rules for your commit messages?
■ What’s the most important point for you when it comes to commits?
Interactive Rebasing:
■ hackernoon.com...
Sources:
■ sandofsky.com/...
■ chris.beams.io...
■ who-t.blogspot....
■ github.com/tor...
■ www.git-scm.co...
---
This video contains advertising content.
---
Attribution:
■ Jenkins Wireframe Icon: www.iconfinder...
#git #softwaredeveloper
Once I got rejected on a job interview because my commit pattern and messages were bad. LOL
A lesson lived is a lesson learned.
*To the community*
I landed a software engineering job this month and studied about "conventional commits". My commits started to have more meaning and context as a result I got praised by my seniors. If you're wondering how to write good commits which adds value to them, please look at "Conventional Commits".
*To Kie*
Thank you so much for this video, learned a lot of new stuffs. Subscribed!
I want to send this to my BOSS!
I seriously need to share this with all my coworkers... I'm the only person who uses git rebasing, squashing etc - this is such important info! Great way of describing, I hope more people follow this!
Thanks mate!
Same here. Only person in the entire team who cares about having an actual usable Git history. Everyone else treats Git like a backup tool. Horrible commit messages, no notion of clean branching or rebasing, doesn't know or care about fixup or squashing _(I LOVE fixup more than squash)_, if commits are lost, oh well, just create new commits and re-commit the same changes (have you heard of reflog?)... To me, it's like watching a horror movie unfold where I'm the one being chased by several ghosts.
yes, my friend's commit msgs are sh1t, the project manager is always telling me about the errors, and I have to fix them
Interactive rebasing - made my day. Thanks for introducing this feature, didn't know about it in the first place. Keep going!
Its a mighty feature and quite fun to work with IMO. Have a great day!
This is a great, compressed talk on the most important things.
you successfully nailed to share with us the feeling you had when you experienced a bad commit history and how annoying it was haha , great video !
Good video! One of the most important things for me is a ticket number at the start of the commit message. This points the commit back to even more context than the commit message contains. What has been done should be in the commit, why it was done should really be in the ticket.
Combining the git log with a ticket management system brings this whole thing up to a new level. Though mostly tickets (other than bug tickets) have a higher birds eye view on the feature that needs to be implemented. In my experience tickets are more written from a users or testers perspective rather than from a programmers. Keeping that in mind having both of these sources of information is incredibly useful.
Thanks for taking the time to comment. Have a great day.
Subscribed -- for being your second video, this is awesome! Quality content, solid script, good edit... Keep it up!
Wow! Thank you for these kind words. Its great to have you here!
Well done Kie. I gave a quick presentation another day inside my company about it. Good commit messages matter, a lot! haha thanks for sharing it :)
Thanks Filipe! Great to see another advocate for git hygiene.
Very nicely explained. Precise and organized content, like a good commit message ;) You explained it under 12 mins what many tutorials don't do in hrs! Thanks.
Thank you. 🙏
The world is so small. From your accent, I knew you're german. But then I opened your website and saw that you're also like me from Hamburg 😅
Very good video. I'd love to work with folks who could appreciate a good commit like that! Subbed!
Moin moin. 🙏
This video is a great resource!
Thank you. 🙏
@@KieCodes You earned it Kie! By the way, mind telling me what the music you used there at the start? I swear I've been hearing it a few times but song recognition apps fail me every time :)
Great video, useful and straight foward. Thanks!
Thank you Rebeca! 🙏
Great video. Great production quality. I'd love to see more content from you.
Thank you. Yes I have some videos in the pipeline. But life is quite busy right now.
Great video. I learned so much thing in this video. Thanks a lot.
That is great to hear! Thank you! 🙏
this is so on point and helps a lot thank you for sharing and the effort 👏👍
Very nicely explained stuff. Now I totally understand when to commit and how to commit. Thank you
You are more than welcome my friend. 🙏 Rock on! 🚀
Hey everyone! It's Monday again. Time for a new video. This time I want to talk about Git Hygiene and how to use Git better! Let me know: Do you have rules for your Git usage?
You should do a video on git branching/merge strategies! This would be so amazing to share with my coworkers
Such a helpful video! And entertaining too. Thanks ♥️
Thank you!
Preach imperative mood. I don't care what YOU did in your work day, I want to know what the commit will do if I apply it. Also imagine trying to find where the fuck a bug started when all commits look like "fix some stuff" "change things" "add new feature"... yeah
I feel called out by this. Also I’m not a developer so I’m fine with that, it’s a work in progress.
Very nice video! I'm shocked you have under 100 subscribers!
Thank you for your kind words. I started this channel only 3 weeks ago. And i am right now at 95. So I hope to reach it next week.
@@KieCodes It looks like you just reach it :)
Igor Nowicki yeah. It was a crazy day yesterday. A lot of nice people found my channel. And some subscribed like you. 🙏
It’s better now!
Awesome video!
Thank you
Amazing, Thanks a lot for the video
Thank you I am glad you found some value! 🙏🙏🙏
Nice one. Learned something. Maybe two videos one explaining the branch and merge strategies and one explaining the rules for a commit message would have been better didacticly though... although I suspect the 10 minute rule played a role.
Been using git for years myself, but not correctly:)
Hey Mike. Thanks a lot for the feedback.
And I think you’re right. Its quite fast paced now. I am still trying to figure out how to pack information in a concise and entertaining but still valuable and informative way.
Excelent, thanks a lot.
You are more than welcome my friend. 🙏 Rock on! 🚀
Great video, I'm going to share it with my partners
Thank you Ian! I hope you all find value in this video and help to make better commits for all involved.
The most important part is to understand that if you use git squash or rebase incorrect then you'll be in much deeper troubles than if you use shitty message.
True. 😂
Some don't agree, but I always recommend 'git pull - - rebase' instead of 'git pull'. Combined with squash it make a good history.
Thats a total valid way! Thank you for you input. 💪
Man hört sofort raus, dass Du deutsch bist 😜 Aber super hilfreich
Danke 😅
A couple of my rules:
1. Don't use the words "and" or "as well" etc. in your message. That means your commit isn't atomic. E.g.: "a new constant has been added as well".
2. Don't paraphrase your code. You kinda say that by saying "explain what and why, but now how". And yet you add "a new constant IMPLEMENTATION_DETAIL with value 9000 has been added". Don't do that. Explain why you are doing that.
3. One trick that I use for my commit subjects is to try to take it up one level of abstraction. That helps to explain why and not how.
4. To make sure that others will understand my commit, I ask myself this question: "how could someone misunderstand what I wrote?", instead of patting myself in the back saying "that's a beautiful commit".
5. Don't squash. Just do not squash. I prefer having to deal with a small change titled "WIP toilet break" than this same change squashed into a huge commit, may it have an amazing description.
6. I don't recommend doing your method 3, because I know that in practice people won't do that. They'll be lazy and just make one giant commit. The only practical way I know of is to do your good commits as you go. If you don't, you won't do it later. Having to git add little bits of paragraphs, or worse, pieces of lines, in different commits, really isn't fun. So make little WIP checkpoints commits if you want to (I sometimes do that, although rarely), but as soon as you have your atomic change, squash NOW with a good message and push.
7. Quote quoted text. That's both in code and in commit messages. "new database field awesomeness": is that the actual name of the field, or is that a joke of some sort? I literally don't know. If it's the name of something, the message should be "" new database field "awesomeness" "".
I'd love to hear what you think about these.
> Don't squash. Just do not squash.
If you know what you're doing, you can do anything. Squash, rebase, merge, move, drop, fixup, exec, reflog... ANYTHING. Git doesn't have rules. We make the rules as we see fit.
@@adtc and "do not squash" is a great rule.
Do you have resources or are you able to explain more what you are talking about with private branches at 3:21? I'm not familiar with the workflow whereby your commits don't show up elsewhere
All good info for a good commit message to be sure, but one pattern in industry to consider is that when merging a pull request to master, it is often common to use a merge strategy of squash and rebase, which means all of your checkpoint commits will get squashed down automatically by GitHub or whatever else you are using, and you'll have the option to modify the commit message from within the browser environment as you perform the merge.
This makes doing an interactive rebase to clean up your commits unnecessary, and means that most of the time, you won't have to worry about writing good commit messages for anyone except yourself.
Very good additional knowledge here. Thank you!
Rule 8: Add relevant ticket numbers or links to references at the bottom of the commit message.
That’s a really nice addition if you work with systems like JIRA. I also have a video on git hooks to automate exactly that. Cheers
Glad to see other people who take git commit message content seriously. I pretty much follow all of your rules, but one that I use is that if my summary has to include the connective "and" or "or" then it's doing too much and I need to break it up.
One of my team-mates gave a presentation on our development approach that includes how we do things with git: ua-cam.com/video/qTVeWbg2tKk/v-deo.html .. it aligns with much of the things in this video.
Hey Dan! Thanks for adding value to this video.
5:57 but doing that, one can only make file-based commits. Cannot split different changes in the same file into separate commits, right?
You can actually commit all the way you like after you did the "git reset". So committing files into separate commits is totally possible.
@@KieCodes I meant committing different sections of a file into different commits. After looking it up, it seems `git add -e` or `git add -i` would do the trick. Otherwise, stepping through patch hunks would work too.
Exactly. It's one of the best features of git. Have fun!
Amazing! Thanks a lot ❤
You are more than welcome.