our commits again are usually the ticket number and a small optional meaningful description i.e.
DEV-1234 mark cross customer call as external
which is automatically gets converted as a jira link on gitlab (we use a jira integration)
(I work in telco btw)
Also same for our branch names. They are ticket numbers DEV-1234 and when a branch is merged on develop /master etc, there is an automated comment on the ticket.
which is handy, because If I see something and I don't understand why it was done like that (poor comments, etc) I can go into the ticket read the description and make sense.
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.
our commits are more like
DEV-4564
IN-930
AP-234
then gitlab recognise them as links to jira tickets ;)
Actually that is really cool!
But you write that in the title and write a description or how the procedure goes? (Interesting topic since I work with gitlab and jira)
our commits again are usually the ticket number and a small optional meaningful description i.e.
DEV-1234 mark cross customer call as external
which is automatically gets converted as a jira link on gitlab (we use a jira integration)
(I work in telco btw)
Also same for our branch names. They are ticket numbers DEV-1234 and when a branch is merged on develop /master etc, there is an automated comment on the ticket.
which is handy, because If I see something and I don't understand why it was done like that (poor comments, etc) I can go into the ticket read the description and make sense.
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!