Πώς κάνεις συνήθως commit τον κώδικα;

Χρησιμοποιώ μια τυποποιημένη μορφή δεσμεύσεων, συχνά βασισμένη στα Conventional Commits. Αυτό διασφαλίζει συνέπεια και αυτοματοποίηση ορισμένων διαδικασιών, όπως η δημιουργία του αρχείου αλλαγών.

Τυπική μορφή δεσμεύσεων:

<τύπος>[(περιοχή)]: <περιγραφή>

[<σώμα>]

[<σημείωση>]

• <τύπος>: Υποχρεωτικό. Ορίζει τον τύπο των αλλαγών (π.χ., feat για νέες λειτουργίες, fix για διορθώσεις, docs για αλλαγές στην τεκμηρίωση, style για μορφοποίηση, refactor για αναδιάρθρωση, test για προσθήκη δοκιμών, ci για αλλαγές σε CI/CD).
• (περιοχή): Προαιρετικό. Δείχνει την περιοχή της εφαρμογής που επηρεάζεται από τις αλλαγές (π.χ., (συστατικό: κουμπί), (υπηρεσία: αυθεντικοποίηση)).
• <περιγραφή>: Υποχρεωτικό. Σύντομη και ακριβής περιγραφή των αλλαγών σε προστακτική (π.χ., "πρόσθεσε κουμπί", "διορθώσε σφάλμα επικύρωσης").
• <σώμα>: Προαιρετικό. Πιο αναλυτική εξήγηση των αλλαγών, λόγοι και πλαίσιο. Διαχωρίζεται με κενή γραμμή από την περιγραφή.
• <σημείωση>: Προαιρετικό. Χρησιμοποιείται γενικά για να δηλώσει BREAKING CHANGE με περιγραφή γιατί αυτή η αλλαγή σπάει την συμβατότητα, ή συνδέσμους σε εργασίες (π.χ., Closes #123).

Παραδείγματα:

feat: πρόσθεσε συστατικό παραθύρου διαλόγου

fix(επικύρωση): διόρθωσε σφάλμα επικύρωσης email στη φόρμα εγγραφής

Τώρα το email επικυρώνεται σωστά σύμφωνα με το πρότυπο RFC 5322.

Closes #45

refactor(συστατικό: κουμπί): ενημέρωση στυλ και βελτίωση προσβασιμότητας

Αναδιάρθρωση των στυλ του κουμπιού για να συμμορφώνεται με το σύστημα σχεδίασης.
Βελτιωμένη προσβασιμότητα με την προσθήκη χαρακτηριστικών ARIA.

Αυτό βοηθά την ομάδα να κατανοήσει καλύτερα την ιστορία των αλλαγών, να επιταχύνει την ανασκόπηση κώδικα και να απλοποιήσει τις αυτοματοποιημένες διαδικασίες.