yeah I agree on slicing that big commit to small ones.
I've used this technique on freelance projects where I would be doing loads of updates and additions in the least amount of time possible so I tend to forget to commit on each edit.
so I end up pushing them in one big commit and I rarely git reverted back a commit 🤷♀️but there was a case scenario where I pushed a huge commit and reverted it ended up rewriting alot of code all over again
and there were times where a big commit saved my life: doing a navbar for a client and she didn't like it and wanted the old navbar back so just reverted one commit rather than typing git log and search for the initial commit for the navbar and git revert back to it
so depends on the case scenario but I agree with you on slicing big commits to small ones
but the ticket trick is worth knowing about!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
yeah I agree on slicing that big commit to small ones.
I've used this technique on freelance projects where I would be doing loads of updates and additions in the least amount of time possible so I tend to forget to commit on each edit.
so I end up pushing them in one big commit and I rarely git reverted back a commit 🤷♀️but there was a case scenario where I pushed a huge commit and reverted it ended up rewriting alot of code all over again
and there were times where a big commit saved my life: doing a navbar for a client and she didn't like it and wanted the old navbar back so just reverted one commit rather than typing git log and search for the initial commit for the navbar and git revert back to it
so depends on the case scenario but I agree with you on slicing big commits to small ones
but the ticket trick is worth knowing about!