வழக்கமான கமிட்கள் 1.0.0

Summary

சுருக்கம்

வழக்கமான கமிட்கள் விவரக்குறிப்பு என்பது கமிட் செய்திகளுக்கு மேல் ஒரு இலகுரக மரபு ஆகும். இது வெளிப்படையான கமிட் வரலாற்றை உருவாக்குவதற்கான எளிதான விதிகளின் தொகுப்பை வழங்குகிறது; இது மேலே தானியங்கி கருவிகளை எழுதுவதை எளிதாக்குகிறது.

இந்த மாநாடு கமிட் செய்திகளில் செய்யப்பட்ட அம்சங்கள், திருத்தங்கள் மற்றும் முறிவு மாற்றங்களை விவரிப்பதன் மூலம் SemVer உடன் ஒத்துப்போகிறது.

கமிட் செய்தி பின்வருமாறு கட்டமைக்கப்பட வேண்டும்:

<type>[உங்கள் விருப்பத்தேர்வு நோக்கம்]:<description>

[உங்கள் விருப்ப உள்ளடக்கம்]

[உங்கள் விருப்ப தலைப்பு(கள்)]

உங்கள் நூலகத்தின் நுகர்வோருக்கு நோக்கத்தைத் தெரிவிக்க, கமிட்டில் பின்வரும் கட்டமைப்பு கூறுகள் உள்ளன:

1. fix: சரிசெய்தல்: type fix இன் கமிட் உங்கள் குறியீட்டுத் தளத்தில் ஒரு பிழையைத் தடுக்கிறது (இது சொற்பொருள் பதிப்பில் PATCH உடன் தொடர்புடையது).
2. feat: type feat இன் கமிட் குறியீட்டுத் தளத்தில் ஒரு புதிய அம்சத்தை அறிமுகப்படுத்துகிறது (இது சொற்பொருள் பதிப்பில் MINOR உடன் தொடர்புடையது).
3. BREAKING CHANGE: BREAKING CHANGE: என்ற அடிக்குறிப்பைக் கொண்ட ஒரு கமிட், அல்லது வகை/நோக்கத்திற்குப் பிறகு ! ஐச் சேர்த்து, ஒரு பிரேக்கிங் API மாற்றத்தை அறிமுகப்படுத்துகிறது (சொற்பொருள் பதிப்பில் MAJOR உடன் தொடர்புடையது). BREAKING CHANGE என்பது எந்த type இன் கமிட்களின் ஒரு பகுதியாக இருக்கலாம்.
4. fix: மற்றும் feat: தவிர மற்ற types அனுமதிக்கப்படுகின்றன, எடுத்துக்காட்டாக @commitlint/config-conventional (Angular convention அடிப்படையில்) build:, chore:, ci:, docs:, style:, refactor:, perf:, test: மற்றும் பிறவற்றைப் பரிந்துரைக்கிறது.
5. BREAKING CHANGE: <description> தவிர மற்ற footers வழங்கப்படலாம் மற்றும் git trailer format இது போன்ற ஒரு மாநாட்டைப் பின்பற்றலாம்.

கூடுதல் வகைகள் வழக்கமான கமிட்கள் விவரக்குறிப்பால் கட்டாயப்படுத்தப்படவில்லை, மேலும் சொற்பொருள் பதிப்பில் எந்த மறைமுக விளைவையும் ஏற்படுத்தாது (அவை ஒரு BREAKING CHANGE ஐ உள்ளடக்கியிருந்தால் தவிர). கூடுதல் சூழல் தகவல்களை வழங்க, ஒரு கமிட்டின் வகைக்கு ஒரு நோக்கம் வழங்கப்படலாம் மற்றும் அடைப்புக்குறிக்குள் உள்ளது, எ.கா., feat(parser): add ability to parse arrays.

எடுத்துக்காட்டுகள்

ஒரு விளக்கத்துடன் கூடிய கமிட் செய்யவும் மற்றும் BREAKING CHANGE footer அடிக்குறிப்பையும் பயன்படுத்தவும்

feat: allow provided config object to extend other configs

BREAKING CHANGE: `extends` key in config file is now used for extending other config files

breaking change-க்கு கவனத்தை ஈர்க்க ! உடன் செய்தியை கமிட் செய்யவும்

feat!: send an email to the customer when a product is shipped

scope-உடன் செய்தியை கமிட் செய்யவும் மற்றும் BREAKING CHANGE கவனத்தை ஈர்க்க !

feat(api)!: send an email to the customer when a product is shipped

! மற்றும் BREAKING CHANGE footer இரண்டையும் கொண்டு கமிட் செய்தியை கமிட் செய்யவும்

chore!: drop support for Node 6

BREAKING CHANGE: use JavaScript features not available in Node 6.

Body இல்லாத commit செய்தியை கமிட் செய்யவும்

docs: correct spelling of CHANGELOG

Scope மூலம் செய்தியை கமிட் செய்யவும்

feat(lang): add polish language

பல பத்தி உள்ளடக்கம் மற்றும் பல அடிக்குறிப்புகளுடன் செய்தியை கமிட் செய்யவும்.

fix: prevent racing of requests

Introduce a request id and a reference to latest request. Dismiss
incoming responses other than from latest request.

Remove timeouts which were used to mitigate the racing issue but are
obsolete now.

Reviewed-by: Z
Refs: #123

Specification

ஆவண விவரக்குறிப்பு

இந்த ஆவணத்தில் உள்ள “கட்டாயம்” (“MUST”), அல்லது “கட்டாயம் இல்லை” (“MUST NOT”), “தேவை” (“REQUIRED”), அல்லது “வேண்டும்” (“SHALL”), “கூடாது” “(“SHALL NOT”), அல்லது “வேண்டும்” (“SHOULD”), “கூடாது” (“SHOULD NOT”), “பரிந்துரைக்கப்பட்டது” (“RECOMMENDS”), “இருக்கலாம்” (“MAY”) மற்றும் “விருப்பத்தேர்வு” (“OPTIONAL”) ஆகிய முக்கிய வார்த்தைகள் RFC 2119 இல் விவரிக்கப்பட்டுள்ளபடி விளக்கப்பட வேண்டும்.

1. கமிட்கள், feat, fix-க்கு போன்ற பெயர்ச்சொல்லைக் கொண்ட ஒரு வகையுடன் முன்னொட்டாகச் சேர்க்கப்பட வேண்டும், அதைத் தொடர்ந்து OPTIONAL scope, OPTIONAL !, மற்றும் தேவையான முனையப் பெருங்குடல் மற்றும் இடைவெளி இருக்க வேண்டும்.
2. ஒரு கமிட் உங்கள் பயன்பாடு அல்லது நூலகத்தில் ஒரு புதிய அம்சத்தைச் சேர்க்கும்போது feat வகையைப் பயன்படுத்த வேண்டும்.
3. ஒரு கமிட் உங்கள் பயன்பாட்டிற்கான பிழைத் தீர்வைக் குறிக்கும் போது fix வகையைப் பயன்படுத்த வேண்டும்.
4. ஒரு வகைக்குப் பிறகு ஒரு நோக்கம் வழங்கப்படலாம். ஒரு நோக்கம், அடைப்புக்குறிகளால் சூழப்பட்ட குறியீட்டுத் தளத்தின் பகுதியை விவரிக்கும் பெயர்ச்சொல்லைக் கொண்டிருக்க வேண்டும், எ.கா., fix(parser):
5. ஒரு விளக்கம் உடனடியாக பெருங்குடல் மற்றும் வகை/நோக்க முன்னொட்டுக்குப் பிறகு இடைவெளியைத் தொடர்ந்து வர வேண்டும்.விளக்கம் என்பது குறியீட்டு மாற்றங்களின் சுருக்கமான சுருக்கமாகும், எ.கா., fix: string இல் பல இடைவெளிகள் இருந்தபோது வரிசை பாகுபடுத்தும் சிக்கல்.
6. குறுகிய விளக்கத்திற்குப் பிறகு ஒரு நீண்ட கமிட் உடல் வழங்கப்படலாம், இது குறியீடு மாற்றங்கள் பற்றிய கூடுதல் சூழல் தகவலை வழங்குகிறது. விளக்கத்திற்குப் பிறகு ஒரு புதிய வரி தொடங்க வேண்டும்.
7. ஒரு கமிட் உடல் கட்டற்ற வடிவத்தைக் கொண்டுள்ளது மற்றும் புதிய வரி பிரிக்கப்பட்ட எத்தனை பத்திகளைக் கொண்டிருக்கலாம்.
8. ஒன்று அல்லது அதற்கு மேற்பட்ட அடிக்குறிப்புகளுக்கு உடலுக்குப் பிறகு ஒரு வெற்று வரி வழங்கப்படலாம். ஒவ்வொரு அடிக்குறிப்பிலும் ஒரு சொல் டோக்கன் இருக்க வேண்டும், அதைத் தொடர்ந்து :<space> அல்லது <space># ஒரு பிரிப்பான் இருக்க வேண்டும், அதைத் தொடர்ந்து ஒரு சரம் மதிப்பு இருக்க வேண்டும் (இதுgit trailer convention).
9. ஒரு அடிக்குறிப்பின் டோக்கன் இடைவெளி எழுத்துகளுக்குப் பதிலாக - ஐப் பயன்படுத்த வேண்டும், எ.கா., Acked-by (இது அடிக்குறிப்புப் பகுதியை பல-பத்தி உள்ளடக்கத்திலிருந்து வேறுபடுத்த உதவுகிறது). BREAKING CHANGE க்கு விதிவிலக்கு அளிக்கப்படுகிறது, இது ஒரு டோக்கனாகவும் பயன்படுத்தப்படலாம்.
10. ஒரு அடிக்குறிப்பின் மதிப்பில் இடைவெளிகள் மற்றும் புதிய வரிகள் இருக்கலாம், மேலும் அடுத்த செல்லுபடியாகும் அடிக்குறிப்பு டோக்கன்/ ஒரு பிரிப்பான் ஜோடி கவனிக்கப்படும்போது பாகுபடுத்தல் முடிவடைய வேண்டும்.
11. உடைக்கும் மாற்றங்கள் ஒரு கமிட்டின் வகை/ஸ்கோப் முன்னொட்டில் அல்லது அடிக்குறிப்பில் உள்ளீட்டாகக் குறிக்கப்பட வேண்டும்.
12. அடிக்குறிப்பாகச் சேர்க்கப்பட்டால், உடைக்கும் மாற்றம் பெரிய எழுத்து உரையான BREAKING CHANGE ஐக் கொண்டிருக்க வேண்டும், அதைத் தொடர்ந்து ஒரு பெருங்குடல், இடைவெளி மற்றும் விளக்கம் இருக்க வேண்டும், எ.கா., BREAKING CHANGE: சூழல் மாறிகள் இப்போது config files ஐ விட முன்னுரிமை பெறுகின்றன.
13. வகை/ஸ்கோப் முன்னொட்டில் சேர்க்கப்பட்டால், உடைக்கும் மாற்றங்களை : க்கு உடனடியாக முன் ஒரு ! ஆல் குறிக்க வேண்டும். ! பயன்படுத்தப்பட்டால், BREAKING CHANGE: அடிக்குறிப்புப் ஒரு பிரிவில் இருந்து தவிர்க்கப்படலாம்,மேலும் commit-க்கு விளக்கம் முறிவு மாற்றத்தை விவரிக்கப் பயன்படுத்தப்படும்.
14. feat மற்றும் fix தவிர பிற வகைகள் உங்கள் commit செய்திகளில் பயன்படுத்தப்படலாம், எ.கா., docs: update ref docs.
15. வழக்கமான commitகளை உருவாக்கும் தகவலின் அலகுகளை செயல்படுத்துபவர்கள் பெரிய எழுத்தில் இருக்க வேண்டிய BREAKING CHANGE தவிர, செயல்படுத்துபவர்களால் பேரெழுத்து உணர்திறன் கொண்டதாகக் கருதக்கூடாது.
16. அடிக்குறிப்பில் டோக்கனாகப் பயன்படுத்தப்படும்போது BREAKING-CHANGE BREAKING CHANGE உடன் ஒத்ததாக இருக்க வேண்டும்.

வழக்கமான commitகளை ஏன் பயன்படுத்த வேண்டும்

• தானாகவே CHANGELOGS ஐ உருவாக்குகிறது.

• ஒரு சொற்பொருள் பதிப்பு பம்பை தானாக தீர்மானித்தல் (இறக்கப்பட்ட commit வகைகளின் அடிப்படையில்).

• மாற்றங்களின் தன்மையை குழு உறுப்பினர்கள், பொதுமக்கள் மற்றும் பிற பங்குதாரர்களுக்குத் தெரிவித்தல்.

• உருவாக்க மற்றும் வெளியிடும் செயல்முறைகளைத் தூண்டுதல்.

• உங்கள் திட்டங்களுக்கு மக்கள் பங்களிப்பதை எளிதாக்குவதன் மூலம், அவர்களை ஆராய அனுமதிப்பது மிகவும் கட்டமைக்கப்பட்ட கமிட் வரலாறு.

அடிக்கடி கேட்கப்படும் கேள்விகள்

ஆரம்ப கட்டத்தில் கமிட் செய்திகளை நான் எவ்வாறு கையாள வேண்டும்?

நீங்கள் ஏற்கனவே தயாரிப்பை வெளியிட்டது போல் தொடர பரிந்துரைக்கிறோம். பொதுவாக யாராவது, அது உங்கள் சக மென்பொருள் உருவாக்குநர்களாக இருந்தாலும் கூட, உங்கள் மென்பொருளைப் பயன்படுத்துகிறார்கள். என்ன சரி செய்யப்பட்டது, என்ன உடைகிறது போன்றவற்றை அவர்கள் அறிய விரும்புவார்கள்.

கமிட் தலைப்பில் உள்ள வகைகள் பெரிய எழுத்தா அல்லது சிறிய எழுத்தா?

எந்த உறையையும் பயன்படுத்தலாம், ஆனால் சீராக இருப்பது நல்லது.

கமிட் ஒன்றுக்கு மேற்பட்ட கமிட் வகைகளுக்கு இணங்கினால் நான் என்ன செய்வது?

திரும்பிச் சென்று முடிந்தவரை பல கமிட்களைச் செய்யுங்கள். வழக்கமான கமிட்களின் நன்மையின் ஒரு பகுதி, மேலும் ஒழுங்கமைக்கப்பட்ட கமிட்கள் மற்றும் PRகளை உருவாக்க நம்மைத் தூண்டும் திறன் ஆகும்.

இது விரைவான மேம்பாடு மற்றும் வேகமான மறு செய்கையை ஊக்கப்படுத்தவில்லையா?

இது ஒழுங்கற்ற முறையில் வேகமாக நகர்வதை ஊக்கப்படுத்துகிறது. இது பல்வேறு பங்களிப்பாளர்களைக் கொண்ட பல திட்டங்களில் நீண்ட காலத்திற்கு வேகமாக நகர உங்களுக்கு உதவுகிறது.

வழக்கமான கமிட்கள், டெவலப்பர்கள் வழங்கப்படும் வகைகளில் சிந்திப்பதால், அவர்கள் செய்யும் கமிட்களின் வகையை வரம்பிட வழிவகுக்குமா?

வழக்கமான கமிட்கள், திருத்தங்கள் போன்ற சில வகையான கமிட்களை அதிகமாகச் செய்ய எங்களை ஊக்குவிக்கின்றன. அதைத் தவிர, வழக்கமான கமிட்களின் நெகிழ்வுத்தன்மை உங்கள் குழு அவர்களின் சொந்த வகைகளைக் கொண்டு வந்து காலப்போக்கில் அந்த வகைகளை மாற்ற அனுமதிக்கிறது.

இது SemVer உடன் எவ்வாறு தொடர்புடையது?

fix வகை கமிட்கள் PATCH-க்கு வெளியீடுகளாக மொழிபெயர்க்கப்பட வேண்டும். feat வகை கமிட்கள் MINOR-க்கு வெளியீடுகளாக மொழிபெயர்க்கப்பட வேண்டும். கமிட்களில் BREAKING CHANGE உடன் உள்ள கமிட்கள், வகையைப் பொருட்படுத்தாமல், MAJOR -க்கு வெளியீடுகளாக மொழிபெயர்க்கப்பட வேண்டும்.

எனது நீட்டிப்புகளை வழக்கமான கமிட்ஸ்விவரக்குறிப்புக்கு எவ்வாறு பதிப்பு செய்ய வேண்டும், எ.கா. @jameswomack/conventional-commit-spec?

இந்த விவரக்குறிப்புக்கு உங்கள் சொந்த நீட்டிப்புகளை வெளியிட SemVer ஐப் பயன்படுத்த பரிந்துரைக்கிறோம் (மேலும் இந்த நீட்டிப்புகளை உருவாக்க உங்களை ஊக்குவிக்கிறோம்!)

நான் தற்செயலாக தவறான கமிட் வகையைப் பயன்படுத்தினால் நான் என்ன செய்வது?

நீங்கள் ஸ்பெக்கில் இருக்கும் ஆனால் சரியான வகை அல்லாத ஒரு வகையைப் பயன்படுத்தும்போது, ​​எ.கா. feat க்கு பதிலாக fix

தவறை ஒன்றிணைப்பதற்கு அல்லது வெளியிடுவதற்கு முன், கமிட் வரலாற்றைத் திருத்த git rebase -i ஐப் பயன்படுத்த பரிந்துரைக்கிறோம். ஒரு வெளியீட்டிற்குப் பிறகு, நீங்கள் பயன்படுத்தும் கருவிகள் மற்றும் செயல்முறைகளைப் பொறுத்து சுத்தம் செய்தல் வேறுபட்டதாக இருக்கும்.

நீங்கள் ஸ்பெக்கின் அல்லாத வகையைப் பயன்படுத்தும்போது, ​​எ.கா. feat க்கு பதிலாக feet

மோசமான சூழ்நிலையில், ஒரு கமிட் வழக்கமான கமிட்ஸ் விவரக்குறிப்பை பூர்த்தி செய்யாவிட்டால் அது உலகின் முடிவு அல்ல. இதன் பொருள், விவரக்குறிப்பை அடிப்படையாகக் கொண்ட கருவிகளால் கமிட் தவறவிடப்படும்.

எனது பங்களிப்பாளர்கள் அனைவரும் வழக்கமான விவரக்குறிப்பைப் பயன்படுத்த வேண்டுமா?

இல்லை! நீங்கள் Git-இல் ஸ்குவாஷ் அடிப்படையிலான பணிப்பாய்வைப் பயன்படுத்தினால், லீட் பராமரிப்பாளர்கள் கமிட் செய்திகளை ஒன்றிணைக்கும்போது சுத்தம் செய்யலாம் - சாதாரண கமிட்டர்களுக்கு எந்த பணிச்சுமையும் சேர்க்காது. இதற்கான பொதுவான பணிப்பாய்வு என்னவென்றால், உங்கள் ஜிட் அமைப்பு ஒரு புல் கோரிக்கையிலிருந்து தானாகவே கமிட் செய்து, இணைப்பிற்கான சரியான கிட் கமிட் செய்தியை உள்ளிட லீட் பராமரிப்பாளருக்கு ஒரு படிவத்தை வழங்குவதாகும்.

வழக்கமான கமிட்ஸ் எவ்வாறு ரிவர்ட் கமிட்களைக் கையாளுகிறது?

குறியீட்டை மாற்றுவது சிக்கலானதாக இருக்கலாம்: நீங்கள் பல கமிட்களை மாற்றுகிறீர்களா? நீங்கள் ஒரு அம்சத்தை மாற்றினால், அடுத்த வெளியீடு ஒரு பேட்சாக இருக்க வேண்டுமா?

வழக்கமான கமிட்ஸ் மாற்ற நடத்தையை வரையறுக்க வெளிப்படையான முயற்சியை மேற்கொள்ளவில்லை. அதற்கு பதிலாக, கருவிப்படுத்தல் ஆசிரியர்கள் types மற்றும் footers இன் நெகிழ்வுத்தன்மையைப் பயன்படுத்தி ரிவர்ட்களைக் கையாள்வதற்கான அவர்களின் தர்க்கத்தை உருவாக்க வேண்டும்.

ஒரு பரிந்துரை என்னவென்றால், revert வகையைப் பயன்படுத்துவதும், மாற்றியமைக்கப்படும் commit SHA-களைக் குறிப்பிடும் அடிக்குறிப்பையும் பயன்படுத்துவதும் ஆகும்:

revert: let us never again speak of the noodle incident

Refs: 676104e, a215868