mirror of https://github.com/conventional-commits/conventionalcommits.org.git synced 2024-11-15 10:55:16 +01:00

docs: correcting casing on proper noun (#335 )

Semantic Versioning is the name of the specification, hence it is a proper noun and this patch corrects the casing.

2021-03-17 16:54:19 +01:00

36 KiB

Raw Blame History

draft

aliases

false

/th/

Conventional Commits 1.0.0

ข้อสรุป

ข้อกำหนดของ Conventional Commits คือข้อตกลงอย่างง่ายที่สร้างขึ้นสำหรับข้อความที่ commit ข้อกำหนดนี้จะรวมข้อกำหนดในการสร้างข้อความในการ commit อย่างชัดเจน ซึ่งจะช่วยให้สามารถเขียนชุดเครื่องมืออัตโนมัติต่อยอดได้ง่ายขึ้น ข้อตกลงนี้จะใช้รูปแบบเดียวกับ SemVer โดยมีการอธิบายถึงฟีเจอร์ การแก้ไขต่าง ๆ และการเปลี่ยนแปลงที่ขัดต่อเวอร์ชั่นก่อนหน้าลงไปในข้อความที่ commit

ข่้อความที่ commit ควรจะมีโครงสร้างตามนี้

<ชนิด>[ละได้ ขอบเขต]: <รายละเอียด>

[ละได้ เนื้อหา]

[ละได้ ข้อความลงท้าย]

โดย commit จะมีหน่วยโครงสร้างย่อย ๆ ตามนี้ เพื่อใช้ในการสื่อสารถึงความตั้งใจให้กับคนที่นำไลบรารี่ของคุณไปใช้งาน

fix: commit ที่มี ชนิด fix หมายถึงมีการแก้ไขบักในโค้ดของคุณ (จะสอดคล้องกับ PATCH ใน Semantic Versioning)
feat: commit ที่มี ชนิด feat หมายถึงมีการเพิ่มฟีเจอร์ใหม่เข้าไปในโค้ด (จะสอดคล้องกับ MINOR ใน Semantic Versioning)
BREAKING CHANGE: commit ที่ลงท้ายด้วย BREAKING CHANGE: ในข้อความลงท้าย หรือ ต่อท้ายด้วย ! หลังจาก type หรือ scope จะหมายถึงมีการเพิ่มการเปลี่ยนแปลงที่กระทบกับ API เดิม (จะสอดคล้องกับ MAJOR ใน Semantic Versioning) โดยที่ BREAKING CHANGE สามารถเป็นส่วนหนึ่งของ commit ชนิด ไหนก็ได้
ชนิด อื่น ๆ ที่ไม่ใช่ fix: and feat: สามารถใช้ได้เช่นกัน เช่น @commitlint/config-conventional (อ้างอิงจาก ข้อตกลงของ Angular) ได้แนะนำชนิด build:, chore:, ci:, docs:, style:, refactor:, perf:, test: และอื่น ๆ
ข้อความลงท้าย ที่นอกเหนือจาก BREAKING CHANGE: <รายละเอียด> สามารถใช้ได้ และเขียนตามข้อตกลงเดียวกันกับ git trailer format

ชนิดอื่น ๆ เพิ่มเติมไม่ได้อยู่ในขอบเขตตามข้อกำหนดของ Conventional Commits นี้ และไม่ได้มีผลกระทบอะไรใน Semantic Versioning (ถ้าไม่ได้ระบุใน BREAKING CHANGE)

ขอบเขตอาจจะถูกระบุไปกับชนิดของ commit เพื่อบอกข้อมูลของบริบทเพิ่มเติม โดยจะระบุอยู่ในเครื่องหมายวงเล็บ เช่น feat(parser): add ability to parse arrays

ตัวอย่าง

ข้อความ commit ที่มีการระบุรายละเอียด และลงท้ายด้วย breaking change ในข้อความลงท้าย

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

ข้อความ commit จะต้องขึ้นต้นด้วย ชนิด ซึ่งประกอบด้วยคำนาม feat, fix, ฯลฯ และตามด้วยขอบเขตซึ่งอาจจะละไว้ได้ และตามด้วย ! ซึ่งอาจจะละไว้ได้ และเครื่องหมายโคล่อน (:) และเว้นวรรค
ชนิด feat จะถูกใช้เมื่อใน commit นั้นมีการเพิ่มฟีเจอร์ใหม่เข้าไปในแอพพลิเคชั่น หรือไลบรารี่ของคุณ
ชนิด fix จะถูกใช้เมื่อ commit นั้นเป็นการแก้ไขบักสำหรับแอพพลิเคชั่นของคุณ
ขอบเขตอาจจะถูกเขียนหลังจากชนิด โดยขอบเขตจะต้องอธิบายได้ถูกส่วนของโค้ด และอยู่ภายใต้วงเล็บ เช่น fix(parser):
คำอธิบายจะต้องอยู่ต่อจากเครื่องหมายโคล่อนและเว้นวรรคที่อยู่หลังจากชนิดและขอบเขตในตอนแรกทันที คำอธิบายจะเป็นข้อความสรุปอย่างสั้นสำหรับการเปลี่ยนแปลงของโค้ด เช่น fix: array parsing issue when multiple spaces were contained in string
เนื้อหา commit ที่ยาวกว่าสามารถใส่เพิ่มหลังจากข้อความ commit แบบสั้นแล้วได้ โดยให้ใส่ข้อมูลในบริบทเพิ่มเติมที่เกี่ยวข้องกับความเปลี่ยนแปลงของโค้ด โดยเนื้อหานี้จะต้องเริ่มด้วยการเว้นบรรทัดว่างหนึ่งบรรทัดหลังจากรายละเอียดของ commit ในบรรทัดแรก
เนื้อหา commit ใส่ได้ตามอิสระ และอาจจะมีหลายย่อหน้าก็ได้
ข้อความลงท้ายอาจจะมีมากกว่าหนึ่ง และจะต้องอยู่หลังจากเนื้อหาโดยการเว้นบรรทัดว่างหนึ่งบรรทัด โดยข้อความลงท้ายแต่ละข้อความจะต้องประกอบด้วย กลุ่มคำ และตามด้วย :<เว้นวรรค> หรือ <เว้นวรรค># เป็นตัวคั่น และตามด้วยข้อความ (ส่วนนี้ได้แรงบันดาลใจมาจาก git trailer convention)
กลุ่มคำในข้อความลงท้ายจะต้องใช้ - แทนช่องว่าง เช่น Acked-by (ซึ่งจะช่วยแยกแยะส่วนที่เป็นข้อความลงท้ายกับเนื้อหาที่มีหลายย่อหน้าออกจากกัน) ข้อยกเว้นเดียวคือ BREAKING CHANGE ซึ่งอาจจะถูกใช้เป็นกลุ่มคำได้เช่นกัน
ข้อความในข้อความลงท้ายอาจจะมีเว้นวรรค และมีการขึ้นบรรทัดใหม่ก็ได้ การแยกข้อความลงท้ายหนึ่งข้อความจะสิ้นสุดเมื่อเจอกลุ่มคำและตัวคั่นในข้อความลงท้ายถัดไป
การเปลี่ยนแปลงที่มีผลกระทบจะต้องมีการบ่งชี้ให้เห็นในส่วนของชนิด หรือขอบเขตในตอนต้น หรือเป็นส่วนหนึ่งของข้อความลงท้าย
ถ้าการเปลี่ยนแปลงที่มีผลกระทบเป็นส่วนหนึ่งของข้อความลงท้าย การเปลี่ยนแปลงนั้นจะต้องขึ้นต้นด้วยคำว่า BREAKING CHANGE (ตัวอักษรตัวใหญ่ทั้งหมด) และตามด้วยเครื่องหมายโคลอน : เว้นวรรค และรายละเอียด เช่น BREAKING CHANGE: environment variables now take precedence over config files
ถ้าการเปลี่ยนแปลงที่มีผลกระทบเป็นส่วนหนึ่งของชนิดหรือขอบเขตในตอนต้น จะต้องใส่ ! ต่อท้ายทันที ก่อนเครื่องหมายโคลอน : และเมื่อใช้ ! อาจจะไม่ต้องใส่ BREAKING CHANGE: ในข้อความลงท้ายก็ได้ และรายละเอียดของ commit จะถูกใช้เพื่ออธิบายถึงสิ่งที่กระทบนั้น ๆ
ชนิดของ commit อื่น ๆ นอกเหนือจาก feat และ fix อาจจะถูกใช้ในข้อความ commit ได้ เช่น docs: updated ref docs.
ส่วนประกอบอื่น ๆ ใน Conventional Commits จะไม่ไม่ให้ความสำคัญกับตัวอักษรใหญ่หรือเล็ก ยกเว้นแต่คำว่า BREAKING CHANGE ซึ่งจะต้องเป็นตัวใหญ่เสมอ
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.

แบบร่างฉบับแรกของข้อกำหนดนี้ถูกเขียนขึ้นโดยความร่วมมือของกลุ่มคนที่มีส่วนร่วมในโปรเจกต์เหล่านี้

conventional-changelog: ชุดของเครื่องมือที่จะใช้แยกข้อความ commit ที่สอดคล้องตามข้อตกลงจากประวัติใน git
parse-commit-message: เครื่องมือที่สามารถสร้างส่วนต่อขยายสำหรับในการแยก แปลงให้เป็นข้อความ และตรวจสอบความถูกต้องสำหรับข้อความ commit ที่สอดคล้องตามข้อตกลง
bumped: เครื่องมือที่ใช้ในการรีลีสซอฟต์แวร์ที่ช่วยให้ทำกิจกรรมบางอย่างก่อนและหลังการรีลีสซอฟต์แวร์เวอร์ชั่นใหม่ออกไป
unleash: เครื่องมือที่จะช่วยในการจัดการวัฏจักรการรีลีสซอฟต์แวร์และเผยแพร่อย่างอัตโนมัติ
lerna: เครื่องมือในการจัดการซอฟต์แวร์ที่เป็นแบบ monorepo ซึ่งต่อยอดมาจากโปรเจ็กต์ Babel

เครื่องมือสำหรับ Conventional Commits

fastlane-plugin: สอดคล้องกับข้อกำหนดในการจัดการเวอร์ชั่น และสร้างบันทึกการเปลี่ยนแปลงโดยอัตโนมัติ
commitizen/cz-cli: เครื่องมือสำหรับ Node.js เพื่อใช้สร้างข้อความ commit ที่สอดคล้องตามข้อกำหนดของ Conventional Commits
commitizen-tools/commitizen: เครื่องมือที่เขียนด้วยภาษาไพธอนในการสร้างกฏในการ commit สำหรับโปรเจ็กต์ และช่วยปรับเลขเวอร์ชั่น และสร้างบันทึกการเปลี่ยนแปลงโดยอัตโนมัติ
php-commitizen: เครื่องมือสำหรับภาษา PHP เพื่อใช้สร้างข้อความ messages ที่สอดคล้องตามข้อกำหนดของ Conventional Commits โดยที่สามารถปรับแต่ง และใช้เป็น depedency ของ composer สำหรับโปรเจ็กต์ PHP หรือใช้โดยทั่วไปสำหรับโปรเจ็กต์ที่ไม่ใช่ PHP
commitlint: ตัวตรวจสอบที่จะตรวจสอบว่าข้อความ commit ของคุณสอดคล้องกับรูปแบบของ Conventional Commits หรือไม่
gitlint: ตัวตรวจสอบข้อความ commit สำหรับ git เขียนด้วยภาษาไพธอน สามารถปรับแต่งค่าเพื่อ บังคับใช้รูปแบบ Conventional Commits ได้
conform: เครื่องมือที่สามารถบังคับการใช้กฏบน git รวมถึง Conventional Commits ได้
detect-next-version: ตัวแยก ตรวจจับ ดึงค่า และดึงลักษณะของ Conventional Commits
recommended-bump: ช่วยคำนวณเลขเวอร์ชั่นโดยอ้างอิงจาก Conventional Commits
git-commits-since: ดึงข้อความ commit แบบดิบจากช่วงเวลาหรือจาก tag ใน git ที่อยู่ในรูปแบบ SemVer (โดยปริยาย) และรองรับปลักอิน
standard-version: ช่วยกำหนดเลขเวอร์ชั่นให้โดยอัตโนมัติ และจัดการ CHANGELOG โดยใช้ปุ่มยุบรวม commit (squash) ใหม่ใน GitHub และลำดับการทำงานแบบที่สอดคล้องกับ Conventional Commits
Conventional Commit: จัดเตรียมรูปแบบสำหรับการสร้าง และตรวจสอบ Conventional Commits ที่สามารถเพิ่มเติมได้ภายใต้หน้าจอ ทุกคนสามารถเข้าใช้งานได้ผ่าน JetBrains IDEs.
Git Commit Template: เพิ่มการสนับสนุนการใช้ Conventional Commits ในโปรแกรม JetBrains Editors (IntelliJ IDEA, PyCharm, PhpStorm...).
commitsar: เครื่องมือสำหรับภาษาโกในการตรวจสอบว่ามี branch ไหนใน git สอดคล้องกับ Conventional Commits หรือไม่ มาพร้อมกับ Docker image สำหรับการใช้งาน CI
semantic-release: เครื่องมือที่ช่วยในการจัดการลำดับทั้งหมดในการรีลีสแพ็กเกจแบบอัตโนมัติ รวมไปถึงการกำหนดเลขเวอร์ชั่นถัดไป การสร้างบันทึกในการรีลีส และการปล่อยแพ็คเกจสู่สาธารณะ
python-semantic-release: ตัวช่วยกำหนดเลขเวอร์ชั่นแบบ SemVer สำหรับโปรเจกต์ของภาษาไพธอน ส่วนนี่เป็นการพัฒนาด้วยภาษาไพธอนสำหรับ semantic-release Node.js
VSCode Conventional Commits: เพิ่มการสนับสนุนการใช้ Conventional Commits ลงใน VSCode
Pyhist: เครื่องมือสำหรับภาษาไพธอนในการปรับค่าเวอร์ชั่นจากข้อมูลย้อนหลังใน git และช่วยสร้างบันทึกการเปลี่ยนแปลง

โปรเจกต์ที่ใช้ Conventional Commits

yargs: ตัวแยกค่าอากิวเมนต์ผ่าน command line ในแนวไพเรทที่ทุกคนชื่นชอบ
istanbuljs: ชุดของเครื่องมือและไลบรารี่แบบโอเพ่นซอร์สในการเพิ่ม code coverage ลงไปในชุดทดสอบของจาวาสคริปต์ของคุณ
uPortal-home และ uPortal-application-framework: ส่วนขยายความสามารถของส่วนติดต่อผู้ใช้เพิ่มเติมของ Apereo uPortal.
massive.js: ไลบรารี่สำหรับเข้าถึงข้อมูลสำหรับ Node และ PostgreSQL
electron: สำหรับ Build แอพพลิเคชั่นบนเดสก์ท็อปแบบ cross-platform ด้วยจาวาสคริปต์ HTML และ CSS
scroll-utility: เครื่องมือที่ช่วยในการเลื่อนหน้าจออย่างง่ายในการทำให้ element อยู่ตรงกลางจอ และมีอนิเมชั่นที่ลื่นไหล
Blaze UI: เครื่องมือในการจัดการส่วนติดต่อผู้ใช้แบบไม่ได้ใช้เฟรมเวิร์คที่เป็นโอเพ่นซอร์ส
Monica: ระบบในการจัดการความสัมพันธ์ส่วนบุคคลแบบโอเพ่นซอร์ส
mhy: กล่องเครื่องมือและชุดสภาพแวดล้อมสำหรับการพัฒนาแบบไม่ต้องตั้งค่าอะไร และมีทุกอย่างให้พร้อม และใช้งานได้หลากหลาย
@tandil/diffparse: ตัวแยกไฟล์ชนิด Diff แบบง่าย (unified diff format).
@tandil/diffsplit: ตัวแบ่งไฟล์ .diff และ .patch ออกมาเป็นไฟล์ของใครของมัน
@thi.ng/umbrella: ประมาณ 100 โปรเจกต์แบบ monorepo ในภาษา TypeScript สำหรับการพัฒนาแบบ data driven
yii2-basic-firestarter: 🔥 เทมเพลตของแอพพลิเคชั่น Yii2
dcyou/resume: 😎 เทมเพลตในการสร้าง CV แบบออนไลน์อย่างง่ายและรวดเร็ว
Nintex Forms: สร้างฟอร์มออนไลน์อย่างง่ายและไดนามิกเพื่อรับค่าและส่งข้อมูลที่เป็นปัจจุบันและถูกต้อง
Tina CMS: เครื่องมือโอเพ่นซอร์สสำหรับการสร้างตัวจัดการฝั่งหน้าบ้านสำหรับเว็บไซต์ของคุณ
Uno Platform: สร้างแอพพลิเคชั่นสำหรับมือถือ เดสก์ท็อป และ WebAssembly ด้วยภาษา C# และ XAML วันนี้ โอเพ่นซอร์ส และได้รับการสนับสนุนอย่างมืออาชีพ

ต้องการเพิ่มโปรเจกต์ของคุณลงในรายชื่อนี้? ส่ง pull request.

36 KiB Raw Blame History