From 3043fa0cd978405144e606da6e24aa73de70b897 Mon Sep 17 00:00:00 2001 From: Chonlasith Jucksriporn Date: Mon, 10 Aug 2020 16:56:34 +0700 Subject: [PATCH] feat(lang): add Thai translation --- config.yaml | 17 +++ content/v1.0.0/index.th.md | 234 +++++++++++++++++++++++++++++++++++++ 2 files changed, 251 insertions(+) create mode 100644 content/v1.0.0/index.th.md diff --git a/config.yaml b/config.yaml index b962115..d72a48f 100755 --- a/config.yaml +++ b/config.yaml @@ -272,3 +272,20 @@ languages: current: v1.0.0 list: - v1.0.0 + + th: + weight: 2 + languageName: "ไทย" + title: Conventional Commits + description: ข้อกำหนดในการทำให้มนุษย์และเครื่องจักรเข้าใจความหมายของข้อความ commit + actions: + - label: ข้อสรุปอย่างเร็ว + url: '#ข้อสรุป' + - label: ข้อกำหนดฉบับเต็ม + url: '#ข้อกำหนด' + - label: มีส่วนร่วม + url: 'https://github.com/conventional-commits/conventionalcommits.org' + versions: + current: v1.0.0 + list: + - v1.0.0 diff --git a/content/v1.0.0/index.th.md b/content/v1.0.0/index.th.md new file mode 100644 index 0000000..3a8724a --- /dev/null +++ b/content/v1.0.0/index.th.md @@ -0,0 +1,234 @@ +--- +draft: false +aliases: ["/th/"] +--- + +# Conventional Commits 1.0.0 + +## ข้อสรุป + +ข้อกำหนดของ Conventional Commits คือข้อตกลงอย่างง่ายที่สร้างขึ้นสำหรับข้อความที่ commit +ข้อกำหนดนี้จะรวมข้อกำหนดในการสร้างข้อความในการ commit อย่างชัดเจน +ซึ่งจะช่วยให้สามารถเขียนชุดเครื่องมืออัตโนมัติต่อยอดได้ง่ายขึ้น +ข้อตกลงนี้จะใช้รูปแบบเดียวกับ [SemVer](http://semver.org) +โดยมีการอธิบายถึงฟีเจอร์ การแก้ไขต่าง ๆ และการเปลี่ยนแปลงที่ขัดต่อเวอร์ชั่นก่อนหน้าลงไปในข้อความที่ commit + +ข่้อความที่ commit ควรจะมีโครงสร้างตามนี้ + +--- + +``` +<ชนิด>[ละได้ ขอบเขต]: <รายละเอียด> + +[ละได้ เนื้อหา] + +[ละได้ ข้อความลงท้าย] +``` +--- + +
+โดย commit จะมีหน่วยโครงสร้างย่อย ๆ ตามนี้ เพื่อใช้ในการสื่อสารถึงความตั้งใจให้กับคนที่นำไลบรารี่ของคุณไปใช้งาน + +1. **fix:** commit ที่มี _ชนิด_ `fix` หมายถึงมีการแก้ไขบักในโค้ดของคุณ (จะสอดคล้องกับ [`PATCH`](http://semver.org/#summary) ใน semantic versioning) +2. **feat:** commit ที่มี _ชนิด_ `feat` หมายถึงมีการเพิ่มฟีเจอร์ใหม่เข้าไปในโค้ด (จะสอดคล้องกับ [`MINOR`](http://semver.org/#summary) ใน semantic versioning) +3. **BREAKING CHANGE:** commit ที่ลงท้ายด้วย `BREAKING CHANGE:` ในข้อความลงท้าย หรือ ต่อท้ายด้วย `!` หลังจาก type หรือ scope จะหมายถึงมีการเพิ่มการเปลี่ยนแปลงที่กระทบกับ API เดิม (จะสอดคล้องกับ [`MAJOR`](http://semver.org/#summary) ใน semantic versioning) +โดยที่ BREAKING CHANGE สามารถเป็นส่วนหนึ่งของ commit _ชนิด_ ไหนก็ได้ +1. _ชนิด_ อื่น ๆ ที่ไม่ใช่ `fix:` and `feat:` สามารถใช้ได้เช่นกัน เช่น [@commitlint/config-conventional](https://github.com/conventional-changelog/commitlint/tree/master/%40commitlint/config-conventional) (อ้างอิงจาก [ข้อตกลงของ Angular](https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#-commit-message-guidelines)) ได้แนะนำชนิด `build:`, `chore:`, + `ci:`, `docs:`, `style:`, `refactor:`, `perf:`, `test:` และอื่น ๆ +1. _ข้อความลงท้าย_ ที่นอกเหนือจาก `BREAKING CHANGE: <รายละเอียด>` สามารถใช้ได้ และเขียนตามข้อตกลงเดียวกันกับ + [git trailer format](https://git-scm.com/docs/git-interpret-trailers) + +ชนิดอื่น ๆ เพิ่มเติมไม่ได้อยู่ในขอบเขตตามข้อกำหนดของ Conventional Commits นี้ และไม่ได้มีผลกระทบอะไรใน semantic versioning (ถ้าไม่ได้ระบุใน BREAKING CHANGE) +

+ขอบเขตอาจจะถูกระบุไปกับชนิดของ commit เพื่อบอกข้อมูลของบริบทเพิ่มเติม โดยจะระบุอยู่ในเครื่องหมายวงเล็บ เช่น `feat(parser): add ability to parse arrays` + +## ตัวอย่าง + +### ข้อความ commit ที่มีการระบุรายละเอียด และลงท้ายด้วย 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 +``` + +### ข้อความ commit ที่มี `!` เพื่อบ่งบอก breaking change +``` +refactor!: drop support for Node 6 +``` + +### ข้อความ commit ที่มีทั้ง `!` และ BREAKING CHANGE ลงท้าย +``` +refactor!: drop support for Node 6 + +BREAKING CHANGE: refactor to use JavaScript features not available in Node 6. +``` + +### ข้อความ commit ที่ไม่มีเนื้อหา +``` +docs: correct spelling of CHANGELOG +``` + +### ข้อความ commit ที่ระบุขอบเขต +``` +feat(lang): add polish language +``` + +### ข้อความ commit ที่มีเนื้อหาหลายย่อหน้า และมีข้อความลงท้ายหลายข้อความ +``` +fix: correct minor typos in code + +see the issue for details + +on typos fixed. + +Reviewed-by: Z +Refs #133 +``` + +## ข้อกำหนด + +คำสำคัญ “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, และ “OPTIONAL” ในเอกสารฉบับนี้จะถูกแปลตามที่อธิบายไว้ใน [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt) + +1. ข้อความ commit จะต้องขึ้นต้นด้วย ชนิด ซึ่งประกอบด้วยคำนาม `feat`, `fix`, ฯลฯ และตามด้วยขอบเขตซึ่งอาจจะละไว้ได้ และตามด้วย `!` ซึ่งอาจจะละไว้ได้ และเครื่องหมายโคล่อน (:) และเว้นวรรค +2. ชนิด `feat` จะถูกใช้เมื่อใน commit นั้นมีการเพิ่มฟีเจอร์ใหม่เข้าไปในแอพพลิเคชั่น หรือไลบรารี่ของคุณ +3. ชนิด `fix` จะถูกใช้เมื่อ commit นั้นเป็นการแก้ไขบักสำหรับแอพพลิเคชั่นของคุณ +4. ขอบเขตอาจจะถูกเขียนหลังจากชนิด โดยขอบเขตจะต้องอธิบายได้ถูกส่วนของโค้ด และอยู่ภายใต้วงเล็บ เช่น `fix(parser):` +5. คำอธิบายจะต้องอยู่ต่อจากเครื่องหมายโคล่อนและเว้นวรรคที่อยู่หลังจากชนิดและขอบเขตในตอนแรกทันที +คำอธิบายจะเป็นข้อความสรุปอย่างสั้นสำหรับการเปลี่ยนแปลงของโค้ด เช่น _fix: array parsing issue when multiple spaces were contained in string_ +1. เนื้อหา commit ที่ยาวกว่าสามารถใส่เพิ่มหลังจากข้อความ commit แบบสั้นแล้วได้ โดยให้ใส่ข้อมูลในบริบทเพิ่มเติมที่เกี่ยวข้องกับความเปลี่ยนแปลงของโค้ด โดยเนื้อหานี้จะต้องเริ่มด้วยการเว้นบรรทัดว่างหนึ่งบรรทัดหลังจากรายละเอียดของ commit ในบรรทัดแรก +2. เนื้อหา commit ใส่ได้ตามอิสระ และอาจจะมีหลายย่อหน้าก็ได้ +3. ข้อความลงท้ายอาจจะมีมากกว่าหนึ่ง และจะต้องอยู่หลังจากเนื้อหาโดยการเว้นบรรทัดว่างหนึ่งบรรทัด โดยข้อความลงท้ายแต่ละข้อความจะต้องประกอบด้วย กลุ่มคำ และตามด้วย `:<เว้นวรรค>` หรือ `<เว้นวรรค>#` เป็นตัวคั่น และตามด้วยข้อความ (ส่วนนี้ได้แรงบันดาลใจมาจาก + [git trailer convention](https://git-scm.com/docs/git-interpret-trailers)) +4. กลุ่มคำในข้อความลงท้ายจะต้องใช้ `-` แทนช่องว่าง เช่น `Acked-by` (ซึ่งจะช่วยแยกแยะส่วนที่เป็นข้อความลงท้ายกับเนื้อหาที่มีหลายย่อหน้าออกจากกัน) ข้อยกเว้นเดียวคือ `BREAKING CHANGE` ซึ่งอาจจะถูกใช้เป็นกลุ่มคำได้เช่นกัน +5. ข้อความในข้อความลงท้ายอาจจะมีเว้นวรรค และมีการขึ้นบรรทัดใหม่ก็ได้ การแยกข้อความลงท้ายหนึ่งข้อความจะสิ้นสุดเมื่อเจอกลุ่มคำและตัวคั่นในข้อความลงท้ายถัดไป +6. การเปลี่ยนแปลงที่มีผลกระทบจะต้องมีการบ่งชี้ให้เห็นในส่วนของชนิด หรือขอบเขตในตอนต้น หรือเป็นส่วนหนึ่งของข้อความลงท้าย +7. ถ้าการเปลี่ยนแปลงที่มีผลกระทบเป็นส่วนหนึ่งของข้อความลงท้าย การเปลี่ยนแปลงนั้นจะต้องขึ้นต้นด้วยคำว่า BREAKING CHANGE (ตัวอักษรตัวใหญ่ทั้งหมด) และตามด้วยเครื่องหมายโคลอน `:` เว้นวรรค และรายละเอียด เช่น +_BREAKING CHANGE: environment variables now take precedence over config files_ +1. ถ้าการเปลี่ยนแปลงที่มีผลกระทบเป็นส่วนหนึ่งของชนิดหรือขอบเขตในตอนต้น จะต้องใส่ `!` ต่อท้ายทันที ก่อนเครื่องหมายโคลอน `:` และเมื่อใช้ `!` อาจจะไม่ต้องใส่ `BREAKING CHANGE:` ในข้อความลงท้ายก็ได้ และรายละเอียดของ commit จะถูกใช้เพื่ออธิบายถึงสิ่งที่กระทบนั้น ๆ +2. ชนิดของ commit อื่น ๆ นอกเหนือจาก `feat` และ `fix` อาจจะถูกใช้ในข้อความ commit ได้ เช่น _docs: updated ref docs._ +3. ส่วนประกอบอื่น ๆ ใน Conventional Commits จะไม่ไม่ให้ความสำคัญกับตัวอักษรใหญ่หรือเล็ก ยกเว้นแต่คำว่า BREAKING CHANGE ซึ่งจะต้องเป็นตัวใหญ่เสมอ +4. BREAKING-CHANGE จะมีความหมายเดียวกันกับ BREAKING CHANGE เมื่อถูกใช้เป็นกลุ่มคำในข้อความลงท้าย + +## ทำไมถึงควรใช้ Conventional Commits + +* ใช้ในการสร้าง CHANGELOG โดยอัตโนมัติ +* ใช้ช่วยในการตัดสินใจในการปรับเวอร์ชั่นตาม semantic version โดยอัตโนมัติ (โดยดูจากชนิดของ commit ที่บันทึก) +* ใช้สื่อสารถึงธรรมชาติของการเปลี่ยนแปลงให้กับเพื่อนร่วมทีม สาธารณะ และผู้ที่เกี่ยวข้องอื่น ๆ +* ใช้เริ่มกระบวนการ build และการเผยแพร่สู่สาธารณะ +* ช่วยให้ผู้ที่จะมีส่วนร่วมในโปรเจกต์ทำงานได้ง่ายขึ้นโดยช่วยให้พวกเขาสามารถดูข้อความ commit ย้อนหลังแบบมีโครงสร้างได้ + +## คำถามที่พบบ่อย + +### ฉันจะจัดการกับข้อความ commit ในช่วงเริ่มต้นของการพัฒนาได้อย่างไร? + +เราแนะนำให้คุณทำเหมือนกับคุณได้รีลีสผลิตภัณฑ์ของคุณแล้ว โดยปกติ *บางคน* ถึงแม้จะหมายถึงเพื่อนร่วมทีมพัฒนาซอฟต์แวร์ของคุณก็ตาม มาใช้ซอฟต์แวร์ของคุณ เขาก็อยากที่จะรู้ว่าส่วนไหนถูกแก้ไขแล้ว ส่วนไหนที่มีการเปลี่ยนแปลง และรายละเอียดส่วนอื่น ๆ + +### ชนิดของ commit ควรจะเป็นตัวใหญ่ หรือตัวเล็ก? + +จะเป็นตัวใหญ่หรือตัวเล็กก็ได้ แต่มันจะเยี่ยมมากถ้ามันสอดคล้องกันทั้งหมด + +### ฉันควรจะทำอย่างไรถ้า commit นั้นเป็นไปได้มากกว่าหนึ่งชนิด​? + +กลับไปแก้ไขและพยายามแบ่งออกให้เป็นหลาย commit เท่าที่จะเป็นไปได้ ประโยชน์ส่วนหนึ่งของ Conventional Commits คือการที่มันช่วยให้เราสามารถจัดการกับ commit และ PR ได้ดีกว่าเดิม + +### นี่มันจะไม่ทำให้การพัฒนาและรอบการทำงานช้าลงกว่าเดิมหรือ? + +มันทำให้การทำงานแบบไม่มีการจัดการช้าลง แต่มันจะช่วยให้คุณทำงานได้เร็วขึ้นในระยะยาวกับหลาย ๆ โปรเจกต์ที่มีส่วนร่วมจากหลาย ๆ คน + +### Conventional Commits จะทำให้นักพัฒนาจำกัดจำนวนของชนิดที่พวกเขาทำเพราะจะทำให้พวกเขาติดอยู่กับชนิดที่มีอยู่หรือไม่? + +Conventional Commits สนับสนุนเราให้สามารถสร้างชนิดได้มากกว่านั้น เช่น fixes นอกจากนั้นแล้ว ความยืดหยุ่นของ Conventional Commits ยังอนุญาตให้ทีมของคุณสร้างชนิดของพวกเขาขึ้นมาเอง และปรับเปลี่ยนมันได้ตลอดเวลาอีกด้วย + +### นี่เกี่ยวข้องกับ SemVer อย่างไร? + +commit ที่มีชนิดเป็น `fix` จะถูกมองเป็น `PATCH` ใน release ส่วน commit ชนิดที่เป็น `feat` จะถูกมองเป็น `MINOR` release และ commits ที่เป็น `BREAKING CHANGE` ไม่ว่าจะเป็นชนิดใดก็ตาม จะถูกมองเป็น `MAJOR` release + +### ฉันควรจะใส่เวอร์ชั่นของส่วนขยายให้กับข้อกำหนดของ Conventional Commits อย่างไร เช่น `@jameswomack/conventional-commit-spec`? + +เราแนะนำให้ใช้ SemVer ในการที่จะรีลีสส่วนขยายของคุณให้กับข้อกำหนดนี้ (และสนับสนุนให้คุณสร้างส่วนขยายนี้ด้วย!) + +### ฉันจะทำอย่างไรถ้าฉันใส่ชนิดของ commit ผิดโดยไม่ได้ตั้งใจ? + +#### เมื่อคุณใช้ชนิดที่เป็นส่วนหนึ่งในข้อตกลง แต่ผิดชนิด เช่น ใช้ `fix` แทนที่จะเป็น `feat` + +ก่อนที่จะรวม หรือรีลีสความผิดพลาดนั้น เราแนะนำให้ใช้ `git rebase -i` เพื่อแก้ไขข้อความใน commit ย้อนหลัง แต่ถ้าทำหลังจากที่รีลีสไปแล้ว การแก้ไขจะแตกต่างกันไปขึ้นอยู่กับเครื่องมือและวิธีการที่คุณใช้ + +#### เมื่อคุณใช้ชนิดที่ *ไม่ได้* เป็นส่วนหนึ่งในข้อตกลง เช่น ใช้ `feet` แทนที่จะเป็น `feat` + +ในสถานการณ์ที่แย่ที่สุด มันไม่ใช่วันสิ้นโลกถ้าคุณจะใส่ commit ที่ไม่สอดคล้องกับข้อกำหนดของ Conventional Commits มันมีความหมายง่าย ๆ คือ commit นั้นจะถูกมองข้ามไปถ้าใช้เครื่องมือที่อ้างอิงตามข้อกำหนดนี้เท่านั้นเอง + +### คนที่มีส่วนร่วมในโปรเจกต์ทั้งหมดจะต้องใช้ข้อกำหนดของ Conventional Commits นี้หรือไม่? + +ไม่! ถ้าคุณใช้ลำดับการทำงานแบบที่ต้องยุบรวม commit บน Git คนที่เป็นผู้ดูแลจะสามารถจัดการกับข้อความ commit ในขณะที่รวม commit เข้ามาโดยที่ไม่เป็นภาระกับผู้ที่ไม่ค่อยได้ commit +ลำดับการทำงานโดยทั่วไปสำหรับแบบนี้คือต้องทำให้ระบบ git ของคุณทำการยุบรวม commit ที่มาจาก pull request โดยอัตโนมัติ และแนะนำฟอร์มให้กับผู้ดูแลเพื่อใส่ข้อความ commit ที่เหมาะสมในการรวม commit เข้ามา + +### Conventional Commits จะจัดการกับการย้อนกลับ commit ได้อย่างไร? + +การย้อนกลับโค้ดอาจจะซับซ้อนได้: คุณกำลังย้อนกลับหลาย ๆ commit หรือไม่? ถ้าคุณกำลังย้อนกลับฟีเจอร์ ในการรีลีสซอฟต์แวร์ครั้งถัดไปจะกลายเป็นเพียงการ patch หรือไม่? + +Conventional Commits ไม่ได้บอกถึงวิธีการอย่างชัดเจนว่าจะต้องทำอย่างไรเมื่อเกิดการย้อนกลับ แต่เราปล่อยให้เป็นการจัดการของนักพัฒนาเครื่องมือเป็นผู้ใช้ความยืดหยุ่นของ _ชนิด_ และ _ข้อความลงท้าย_ ในการพัฒนาตรรกะในการจัดการการย้อนกลับ + +คำแนะนำหนึ่งคือการใช้ชนิด `revert` และข้อความลงท้ายที่มีการอ้างถึงหมายเลข commit ที่จะถูกย้อนกลับ + +``` +revert: let us never again speak of the noodle incident + +Refs: 676104e, a215868 +``` + +## เกี่ยวกับ + +ข้อกำหนดของ The Conventional Commits ได้รับแรงบันดาลใจ และอ้างอิงมาจาก [Angular Commit Guidelines](https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#-commit-message-guidelines). + +แบบร่างฉบับแรกของข้อกำหนดนี้ถูกเขียนขึ้นโดยความร่วมมือของกลุ่มคนที่มีส่วนร่วมในโปรเจกต์เหล่านี้ + +* [conventional-changelog](https://github.com/conventional-changelog/conventional-changelog): ชุดของเครื่องมือที่จะใช้แยกข้อความ commit ที่สอดคล้องตามข้อตกลงจากประวัติใน git +* [parse-commit-message](https://npmjs.com/package/parse-commit-message): เครื่องมือที่สามารถสร้างส่วนต่อขยายสำหรับในการแยก แปลงให้เป็นข้อความ และตรวจสอบความถูกต้องสำหรับข้อความ commit ที่สอดคล้องตามข้อตกลง +* [bumped](https://bumped.github.io): เครื่องมือที่ใช้ในการรีลีสซอฟต์แวร์ที่ช่วยให้ทำกิจกรรมบางอย่างก่อนและหลังการรีลีสซอฟต์แวร์เวอร์ชั่นใหม่ออกไป +* [unleash](https://github.com/netflix/unleash): เครื่องมือที่จะช่วยในการจัดการวัฏจักรการรีลีสซอฟต์แวร์และเผยแพร่อย่างอัตโนมัติ +* [lerna](https://github.com/lerna/lerna): เครื่องมือในการจัดการซอฟต์แวร์ที่เป็นแบบ monorepo ซึ่งต่อยอดมาจากโปรเจ็กต์ Babel + +## เครื่องมือสำหรับ Conventional Commits + +* [fastlane-plugin](https://github.com/xotahal/fastlane-plugin-semantic_release): สอดคล้องกับข้อกำหนดในการจัดการเวอร์ชั่น และสร้างบันทึกการเปลี่ยนแปลงโดยอัตโนมัติ +* [commitizen/cz-cli](https://github.com/commitizen/cz-cli): เครื่องมือสำหรับ Node.js เพื่อใช้สร้างข้อความ commit ที่สอดคล้องตามข้อกำหนดของ Conventional Commits +* [commitizen-tools/commitizen](https://github.com/commitizen-tools/commitizen): เครื่องมือที่เขียนด้วยภาษาไพธอนในการสร้างกฏในการ commit สำหรับโปรเจ็กต์ และช่วยปรับเลขเวอร์ชั่น และสร้างบันทึกการเปลี่ยนแปลงโดยอัตโนมัติ +* [php-commitizen](https://github.com/damianopetrungaro/php-commitizen): เครื่องมือสำหรับภาษา PHP เพื่อใช้สร้างข้อความ messages ที่สอดคล้องตามข้อกำหนดของ Conventional Commits โดยที่สามารถปรับแต่ง และใช้เป็น depedency ของ composer สำหรับโปรเจ็กต์ PHP หรือใช้โดยทั่วไปสำหรับโปรเจ็กต์ที่ไม่ใช่ PHP +* [commitlint](https://github.com/conventional-changelog/commitlint): ตัวตรวจสอบที่จะตรวจสอบว่าข้อความ commit ของคุณสอดคล้องกับรูปแบบของ Conventional Commits หรือไม่ +* [gitlint](https://github.com/jorisroovers/gitlint): ตัวตรวจสอบข้อความ commit สำหรับ git เขียนด้วยภาษาไพธอน สามารถปรับแต่งค่าเพื่อ [บังคับใช้รูปแบบ Conventional Commits](https://jorisroovers.com/gitlint/contrib_rules/#ct1-contrib-title-conventional-commits) ได้ +* [conform](https://github.com/autonomy/conform): เครื่องมือที่สามารถบังคับการใช้กฏบน git รวมถึง Conventional Commits ได้ +* [detect-next-version](https://npmjs.com/package/detect-next-version): ตัวแยก ตรวจจับ ดึงค่า และดึงลักษณะของ Conventional Commits +* [recommended-bump](https://www.npmjs.com/package/recommended-bump): ช่วยคำนวณเลขเวอร์ชั่นโดยอ้างอิงจาก Conventional Commits +* [git-commits-since](https://www.npmjs.com/package/git-commits-since): ดึงข้อความ commit แบบดิบจากช่วงเวลาหรือจาก tag ใน git ที่อยู่ในรูปแบบ SemVer (โดยปริยาย) และรองรับปลักอิน +* [standard-version](https://github.com/conventional-changelog/standard-version): ช่วยกำหนดเลขเวอร์ชั่นให้โดยอัตโนมัติ และจัดการ CHANGELOG โดยใช้ปุ่มยุบรวม commit (squash) ใหม่ใน GitHub และลำดับการทำงานแบบที่สอดคล้องกับ Conventional Commits +* [Conventional Commit](https://github.com/lppedd/idea-conventional-commit): จัดเตรียมรูปแบบสำหรับการสร้าง และตรวจสอบ Conventional Commits ที่สามารถเพิ่มเติมได้ภายใต้หน้าจอ ทุกคนสามารถเข้าใช้งานได้ผ่าน [JetBrains IDEs](https://www.jetbrains.com/). +* [Git Commit Template](https://plugins.jetbrains.com/plugin/9861-git-commit-template): เพิ่มการสนับสนุนการใช้ Conventional Commits ในโปรแกรม [JetBrains Editors](https://www.jetbrains.com/) (IntelliJ IDEA, PyCharm, PhpStorm...). +* [commitsar](https://github.com/commitsar-app/commitsar): เครื่องมือสำหรับภาษาโกในการตรวจสอบว่ามี branch ไหนใน git สอดคล้องกับ Conventional Commits หรือไม่ มาพร้อมกับ Docker image สำหรับการใช้งาน CI +* [semantic-release](https://github.com/semantic-release/semantic-release): เครื่องมือที่ช่วยในการจัดการลำดับทั้งหมดในการรีลีสแพ็กเกจแบบอัตโนมัติ รวมไปถึงการกำหนดเลขเวอร์ชั่นถัดไป การสร้างบันทึกในการรีลีส และการปล่อยแพ็คเกจสู่สาธารณะ +* [python-semantic-release](https://github.com/relekang/python-semantic-release): ตัวช่วยกำหนดเลขเวอร์ชั่นแบบ SemVer สำหรับโปรเจกต์ของภาษาไพธอน ส่วนนี่เป็นการพัฒนาด้วยภาษาไพธอนสำหรับ [semantic-release](https://github.com/semantic-release/semantic-release) Node.js +* [VSCode Conventional Commits](https://marketplace.visualstudio.com/items?itemName=vivaxy.vscode-conventional-commits): เพิ่มการสนับสนุนการใช้ Conventional Commits ลงใน VSCode +* [Pyhist](https://github.com/jgoodman8/pyhist): เครื่องมือสำหรับภาษาไพธอนในการปรับค่าเวอร์ชั่นจากข้อมูลย้อนหลังใน git และช่วยสร้างบันทึกการเปลี่ยนแปลง + +## โปรเจกต์ที่ใช้ Conventional Commits + +* [yargs](https://github.com/yargs/yargs): ตัวแยกค่าอากิวเมนต์ผ่าน command line ในแนวไพเรทที่ทุกคนชื่นชอบ +* [istanbuljs](https://github.com/istanbuljs/istanbuljs): ชุดของเครื่องมือและไลบรารี่แบบโอเพ่นซอร์สในการเพิ่ม code coverage ลงไปในชุดทดสอบของจาวาสคริปต์ของคุณ +* [uPortal-home](https://github.com/UW-Madison-DoIT/angularjs-portal) และ [uPortal-application-framework](https://github.com/UW-Madison-DoIT/uw-frame): ส่วนขยายความสามารถของส่วนติดต่อผู้ใช้เพิ่มเติมของ [Apereo uPortal](https://www.apereo.org/projects/uportal). +* [massive.js](https://github.com/dmfay/massive-js): ไลบรารี่สำหรับเข้าถึงข้อมูลสำหรับ Node และ PostgreSQL +* [electron](https://github.com/electron/electron): สำหรับ Build แอพพลิเคชั่นบนเดสก์ท็อปแบบ cross-platform ด้วยจาวาสคริปต์ HTML และ CSS +* [scroll-utility](https://github.com/LeDDGroup/scroll-utility): เครื่องมือที่ช่วยในการเลื่อนหน้าจออย่างง่ายในการทำให้ element อยู่ตรงกลางจอ และมีอนิเมชั่นที่ลื่นไหล +* [Blaze UI](https://github.com/BlazeUI/blaze): เครื่องมือในการจัดการส่วนติดต่อผู้ใช้แบบไม่ได้ใช้เฟรมเวิร์คที่เป็นโอเพ่นซอร์ส +* [Monica](https://github.com/monicahq/monica): ระบบในการจัดการความสัมพันธ์ส่วนบุคคลแบบโอเพ่นซอร์ส +* [mhy](https://mhy.js.org): กล่องเครื่องมือและชุดสภาพแวดล้อมสำหรับการพัฒนาแบบไม่ต้องตั้งค่าอะไร และมีทุกอย่างให้พร้อม และใช้งานได้หลากหลาย +* [@tandil/diffparse](https://github.com/danielduarte/diffparse#readme): ตัวแยกไฟล์ชนิด Diff แบบง่าย (unified diff format). +* [@tandil/diffsplit](https://github.com/danielduarte/diffsplit#readme): ตัวแบ่งไฟล์ .diff และ .patch ออกมาเป็นไฟล์ของใครของมัน +* [@thi.ng/umbrella](https://github.com/thi-ng/umbrella): ประมาณ 100 โปรเจกต์แบบ monorepo ในภาษา TypeScript สำหรับการพัฒนาแบบ data driven +* [yii2-basic-firestarter](https://github.com/HunWalk/yii2-basic-firestarter): 🔥 เทมเพลตของแอพพลิเคชั่น Yii2 +* [dcyou/resume](https://github.com/dcyou/resume): 😎 เทมเพลตในการสร้าง CV แบบออนไลน์อย่างง่ายและรวดเร็ว +* [Nintex Forms](https://www.nintex.com/workflow-automation/modern-forms/): สร้างฟอร์มออนไลน์อย่างง่ายและไดนามิกเพื่อรับค่าและส่งข้อมูลที่เป็นปัจจุบันและถูกต้อง +* [Tina CMS](https://tinacms.org): เครื่องมือโอเพ่นซอร์สสำหรับการสร้างตัวจัดการฝั่งหน้าบ้านสำหรับเว็บไซต์ของคุณ +* [Uno Platform](https://platform.uno): สร้างแอพพลิเคชั่นสำหรับมือถือ เดสก์ท็อป และ WebAssembly ด้วยภาษา C# และ XAML วันนี้ โอเพ่นซอร์ส และได้รับการสนับสนุนอย่างมืออาชีพ + +[![Conventional Commits](https://img.shields.io/badge/Conventional%20Commits-1.0.0-yellow.svg)](https://conventionalcommits.org) + +_ต้องการเพิ่มโปรเจกต์ของคุณลงในรายชื่อนี้?_ [ส่ง pull request](https://github.com/conventional-changelog/conventionalcommits.org/pulls).