In the amazing world of software or web development, version controlling is one must-have in every developer working on a project with other develo...
For further actions, you may consider blocking this person and/or reporting abuse
Nice read, thanks!
Got a question tho. I've been in scenarios whereby I branched out from main and start working on a bug fix for a feature. While on that, I get a request from PM to work on another fix with a higher priority. Sometimes I'm just tempted to add that quick fix to the current fix that I'm working on. In this case would you consider it bad practice?
Thank you for your kind words!
In your scenario, while it might seem convenient to add the higher priority fix to your current branch, it can lead to confusion and make it harder to track changes. A better approach would be to stash your current changes, switch to a new branch for the higher priority fix, and then return to your original task once the urgent fix is complete. But you might got conflicts this way in the two branches. So you should have a strong command on git to resolve conflicts as well.
Otherwise stash the changes, work in the new branch on a new bug and then pull the previous branch in the new one.
I don't know if this would work and be considered a good practice. I just thought of it and needs to be fact checked -
If you don't want to stash your current progress, git clone the repository in a different directory and work higher priority task in that code. Once you are done with the priority task and merged, go back to your own work and complete that fix. That way you may be able to work on both the tasks as required.
The better approach would be git worktree, you don't have to clone a new repo everytime this happens and still maintain multiple branches
Thank you for the information. I got to know something new today. :) I will, for sure, explore git worktree in detail.
Checkout git worktree, that is there for this exact use case.
Yes. Bad practice. I understand your temptation but it mixes two different changes. It’s ok to have small or tiny PRs if they fix the entire issue.
I think its a good idea to keep one fix or feature(or a lower classification) per commit. Helps to keep things and manageable
To handle this, use
git stashto save your current work, then create a new branch for the high priority fix.Nice. Best practice all the way!
My approach would be since you are already working on a bug in the branch you have created it is always better to create a new branch for a higher priority issue/bug and once that is fixed merge the code from earlier low priority bug into this one and fix that. This way you a priority history of big fix and also knowing if any change has had other impacts before merging into main.
Yes, sounds good, I suggested exactly that.
But if we believe that we'll not have conflicts, it would be better to keep those branch separate and push them to main (means by creating PRs and merging obviously).
Great Article
My Git history is basically a diary of my emotional state while coding.
Yes exactly, that should be it
Concise and effective. Thanks for sharing!
I think that git commit’s best practices are related or similar to clean code patterns. Atomicity at least is one of the keys.
Thanks Brother, keep supporting me like this and I'll keep writing good for you.
cool.
Thanks for this comprehensive guide on effective Git commit management. It will greatly help in maintaining a clear and organized project history.
Thanks much for your good words.
Thank you, very insightful
Thanks for your good words, happy coding..
Good experience.
Very Insightful article to read, It is very nice to see someone sharing citing the generic but very important details of git.
I will share this post with the community.
Its pleasure when someone really supports and appreciate your efforts. It means a lot to me brother!!
Really really good! Thx very much!
My Pleasure mate!!!
What if I already made a lot of unrelated changes before I remember to commit?
Thanks for reading out. Then there's one solution possible. If a complete change is only in one file. then you can stag and commit changes file by file.
For example if have changed documentation of the project in README.md and there are other uncommitted changes too, we can stag README.md file first of all and others one by one like
Atomic changes are important for every commit. I get too desperate and I end up making large commits.
yep
Great 👍
Thanks man!!
Good but not perfect.
You should distinguish local work, remote "internal untested unstable" and finally a waterfall-like commits. Locally you can create millions of branches and commits (though it is not practical... Usually a few dozens of commits per Dev day is enough).
When pushing you replicate your code so that it is not lost if your computer goes bad. It could be pushed onto origin or any other host. But you should probably describe what it is (usually branch name is enough to do that). This is when rebase is great.
When merging to a shared workflow (ex. develop branch), you should have it tested and at least compiling (though more likely working and tested). This is where squash shines.
Normally you do not develop a single thing long. There are exceptions though. Again rebase shines and the longer you do this, the more pain it is.
Then releasing is approaching slowly. You should understand what is an annotated tag. Keep it simple or it would cause too complex.
Finally release. You need to decide your approach here: do we merge back to develop? Shall we squash, rebase, merge or do something else? What should be done when someone is merging us as a base? Ffonly?
Deployment. Is it a release or deployment?
I skipped the part with storage as each type has different approach: GitHub has forked repos and pull requests, kernel has merge requests over mail, some have pull request from branch where repo is semi-public but some branches are protected.
I also skipped branching of different releases. What to do if you need to maintain multiple versions? How to release this important security bugfix that is same for 9 versions but older versions needs different code?
You totally skipped multiline commits (first line is a summary, then empty line and an elaborate bellow). 80 or more columns? Special approach to cosmetic non-functional changes? What prefixes to use (conventional commits) and how to write release notes?
This is just a scratch on the surface of this topic.
Thanks for the article and good luck in your journey!
Good Suggestions, but see the tag #beginners on the top?
It is for beginners, not for advanced level devs. So that is information is enough for them.
Thank you for your insightful blog post on Good Commit ✔ VS. Bad Commit ❌: Best Practices for Git. I found it both engaging and informative, and I appreciate the effort you put into it. Looking forward to reading more of your work!
great article !
i recently wrote something about conventional commits
link
I would be honored if you could check it out 🫠
You have written well too. Great job.
This article is a fascinating deep dive into the engineering challenges and solutions behind Uber's LedgerStore. The scale of the problem - managing trillions of indexes for billions of transactions - is mind-boggling.
What about
git commit -m "wip"No brother, commit show never be labeled as work in progress. Commit means that a really really small piece of task is done. That does not make any sense to leave a small piece of task with wip label.
Yes you can do it with Pull Requests That makes sense.
Meanwhile in my universe.
If you ask me what massive frontEnd update means, I don't know anymore.
Good read, learned a lot about making good Commits. I should really learn how to REALLY use git
Got a question tho. I've been in scenarios whereby I branched out from main and start working on a bug fix for a feature. While on that, I get a request from PM to work on another fix with a higher priority. Sometimes I'm just tempted to add that quick fix to the current fix that I'm working on. In this case would you consider it bad practice?
Thank you for your kind words!
In your scenario, while it might seem convenient to add the higher priority fix to your current branch, it can lead to confusion and make it harder to track changes. A better approach would be to stash your current changes, switch to a new branch for the higher priority fix, and then return to your original task once the urgent fix is complete. But you might got conflicts this way in the two branches. So you should have a strong command on git to resolve conflicts as well.
Otherwise stash the changes, work in the new branch on a new bug and then pull the previous branch in the new one.
I like the Conventional Commit Guidelines. The official site provides tools for enforcing git commit messages to adhere to those guidelines such as commitizen.
conventionalcommits.org/en/about/#...
use git-cz or gitmoji to categorize your commit and follow 50/72 rule to normalize commitments
Very nice! Thanks a lot for this 💪
My pleasure. Thanks for appreciating!!!
Awesome. I think the best way is to use conventionalcommits.org/en/v1.0.0/
My stories tend to have many modifications. If I commit every time, I complete one modification, I will have many commits. What is your advice? BTW, good article.
When your stories involve many modifications, it's important to commit often but meaningfully. Each commit should represent a distinct change or fix. Using feature branches can help manage multiple modifications without cluttering the main branch. Before merging, you can squash commits into a single comprehensive commit to keep the history clean. Also, ensure your commit messages are descriptive and concise to make tracking changes easier. This approach will help maintain a clear and organized project history. Thank you for your comment and glad you enjoyed the article!
This information is detailed
Thanks
hahaha, it's me who often use bad commit
You should improve
Amazing post bro!