The podcast that helps you to improve your development knowledge and career,
through explaining the latest and greatest in development technology and providing you with what you need to succeed as...
I tag commits with the ticket, and a short overview of what was done.
The ticket has more detail, of someone needs it, there maybe multiple commits for that one ticket as well.
I would also argue that last commit was terrible!
It should have been at least 7 separate commits, which were distinct to each completed change.
You can then revert single problematic commits, rather than loosing ALL those changes if the big commit needs to be rolled back.
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.
I tag commits with the ticket, and a short overview of what was done.
The ticket has more detail, of someone needs it, there maybe multiple commits for that one ticket as well.
I would also argue that last commit was terrible!
It should have been at least 7 separate commits, which were distinct to each completed change.
You can then revert single problematic commits, rather than loosing ALL those changes if the big commit needs to be rolled back.
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!