Project vs Repository ใน GitHub

ใน GitHub ความแตกต่างทางแนวคิดระหว่างโครงการ (ที่สามารถสร้างขึ้นภายในที่เก็บ) และที่เก็บคืออะไร

ผมเคยเห็นคำถามที่คล้ายกันหลายคน ( ที่นี่ , ที่นี่และที่นี่ ) ใน SO แต่ไม่มีของพวกเขาอธิบายถึงสิ่งที่เป็นโครงการ GitHub สิ่งที่เป็นที่เก็บ GitHub และเมื่อใช้หนึ่งของพวกเขาแต่ละคน

ฉันจะขอบคุณถ้ามีคนอธิบายแต่ละคำศัพท์และให้ตัวอย่างของเวลาที่จะใช้ / สร้างแต่ละคำ ตัวอย่างเช่นถ้าฉันมีแอปพลิเคชั่นต้นแบบหลายตัวทั้งหมดเป็นอิสระจากกันฉันจะสร้างอะไรเพื่อจัดการซอร์สโค้ดของพวกเขาในลักษณะที่เป็นระเบียบ

GitHub เมื่อเร็ว ๆ นี้แนะนำคุณลักษณะใหม่ที่เรียกว่าโครงการ นี่เป็นบอร์ดภาพที่เป็นปกติของเครื่องมือการจัดการโครงการหลายอย่าง:

พื้นที่เก็บข้อมูลเป็นเอกสารบน GitHub:

พื้นที่เก็บข้อมูลเป็นองค์ประกอบพื้นฐานที่สุดของ GitHub พวกเขาง่ายที่สุดที่จะจินตนาการว่าเป็นโฟลเดอร์ของโครงการ ที่เก็บมีไฟล์โครงการทั้งหมด (รวมถึงเอกสารประกอบ) และเก็บประวัติการแก้ไขของไฟล์แต่ละไฟล์ ที่เก็บสามารถมีผู้ทำงานร่วมกันหลายคนและสามารถเป็นได้ทั้งสาธารณะหรือส่วนตัว

โครงการเป็นเอกสารบน GitHub:

บอร์ดโครงการบน GitHub ช่วยคุณจัดระเบียบและจัดลำดับความสำคัญงานของคุณ คุณสามารถสร้างบอร์ดโปรเจ็กต์สำหรับการทำงานของคุณสมบัติเฉพาะโรดแมพที่ครอบคลุมหรือแม้แต่ปล่อยรายการตรวจสอบ ด้วยบอร์ดโครงการคุณมีความยืดหยุ่นในการสร้างเวิร์กโฟลว์แบบกำหนดเองที่เหมาะกับความต้องการของคุณ

ส่วนหนึ่งของความสับสนคือฟีเจอร์ใหม่โครงการขัดแย้งกับการใช้งานที่มากเกินไปของโปรเจ็กต์คำในเอกสารด้านบน

ความเป็นจริง 1: โครงการและพื้นที่เก็บข้อมูลเป็นคำพ้องความหมายเสมอใน GitHub

ความจริงที่ 2: นี่ไม่ใช่กรณีอีกต่อไป

มีความสับสนมากมายเกี่ยวกับที่เก็บและโครงการ ในอดีตทั้งสองคำนี้ใช้กันอย่างแพร่หลายโดยผู้ใช้และเอกสารของ GitHub สิ่งนี้สะท้อนให้เห็นจากคำตอบและความคิดเห็นบางส่วนที่นี่ซึ่งอธิบายความแตกต่างที่ลึกซึ้งระหว่างคำเหล่านั้นและเมื่อใดที่คำหนึ่งต้องการเหนือสิ่งอื่น ความแตกต่างนั้นบอบบางอยู่เสมอเช่นตัวติดตามปัญหาเป็นส่วนหนึ่งของโครงการ แต่ไม่ได้เป็นส่วนหนึ่งของที่เก็บซึ่งอาจคิดว่าเป็นสิ่งคอมไพล์อย่างเคร่งครัด ฯลฯ

ไม่อีกแล้ว.

ปัจจุบัน repos และโครงการอ้างถึงเอนทิตีประเภทต่าง ๆที่มีAPI แยกต่างหาก :

• https://developer.github.com/v3/repos/
• https://developer.github.com/v3/projects/

ตั้งแต่นั้นมามันก็ไม่ถูกต้องที่จะเรียก repo โครงการหรือในทางกลับกัน โปรดทราบว่ามันมักจะสับสนในเอกสารอย่างเป็นทางการและเป็นที่น่าเสียดายว่าคำศัพท์ที่ใช้กันอย่างแพร่หลายนั้นได้รับเลือกให้เป็นชื่อของนิติบุคคลใหม่ แต่ในกรณีนี้เราต้องอยู่กับมัน

ผลที่ตามมาก็คือว่า repos และโครงการมักจะสับสนและทุกครั้งที่คุณอ่านเกี่ยวกับโครงการ GitHub คุณต้องสงสัยว่าจริงๆแล้วมันเกี่ยวกับโครงการหรือเกี่ยวกับ repos หากพวกเขาเลือกชื่ออื่นหรือตัวย่อเช่น "proj" จากนั้นเราสามารถรู้ได้ว่าสิ่งที่กล่าวถึงคือเอนทิตีแบบใหม่วัตถุที่แม่นยำที่มีคุณสมบัติเป็นรูปธรรม

คำที่มักจะชัดเจนคือ"คณะกรรมการโครงการ"

เราเรียนรู้อะไรจาก API

จุดสิ้นสุดแรกในเอกสารของ Projects API:

• https://developer.github.com/v3/projects/#list-repository-projects

เป็น: รายการโครงการพื้นที่เก็บข้อมูล หมายความว่าพื้นที่เก็บข้อมูลสามารถมีหลายโครงการ ดังนั้นทั้งสองไม่สามารถหมายถึงสิ่งเดียวกัน มันรวมถึงการตอบสนองหากโครงการถูกปิดใช้งาน :

{
  "message": "Projects are disabled for this repo",
  "documentation_url": "https://developer.github.com/v3"
}

ซึ่งหมายความว่าบาง repos สามารถปิดการใช้งานโครงการ อีกครั้งสิ่งเหล่านั้นจะไม่เหมือนเดิมเมื่อ repo สามารถปิดการใช้งานโครงการได้

มีปลายทางที่น่าสนใจอื่น ๆ :

• สร้างโครงการที่เก็บ -POST /repos/:owner/:repo/projects
• สร้างโครงการองค์กร -POST /orgs/:org/projects

แต่ไม่มี :

• สร้างโครงการของผู้ใช้ -POST /users/:user/projects

ซึ่งทำให้เราแตกต่าง:

1. ที่เก็บข้อมูลสามารถเป็นของผู้ใช้หรือองค์กร
2. โครงการสามารถเป็นของที่เก็บหรือองค์กร

หรือที่สำคัญกว่า:

1. โปรเจ็กต์สามารถเป็นของที่เก็บข้อมูล แต่ไม่ใช่ในทางกลับกัน
2. โปรเจ็กต์สามารถเป็นขององค์กร แต่ไม่ใช่สำหรับผู้ใช้
3. ที่เก็บข้อมูลสามารถเป็นขององค์กรและผู้ใช้งานได้

ดูสิ่งนี้ด้วย:

• https://help.github.com/articles/about-project-boards/

ฉันรู้ว่ามันสับสน ฉันพยายามอธิบายอย่างแม่นยำที่สุดเท่าที่จะทำได้

GitHub Repositories ใช้เพื่อจัดเก็บไฟล์โฟลเดอร์และทรัพยากรอื่น ๆ ทั้งหมดที่คุณใส่ใจ

โครงการ Git: มันเป็นหนึ่งในทรัพยากรใน Git Repository และการใช้งานหลักของมันคือการจัดการโครงการด้วย visual board หากคุณสร้างโครงการใน Git Repository มันจะสร้างบอร์ดเสมือนเช่นบอร์ด Kanban เพื่อจัดการโครงการ

ด้วยวิธีนี้คุณสามารถมีหลายโครงการในที่เก็บ

โดยทั่วไปบน GitHub, 1 = 1 พื้นที่เก็บข้อมูลโครงการ ตัวอย่างเช่น: https://github.com/spring-projects/spring-boot แต่มันก็ไม่ใช่กฎที่ยากนัก

พื้นที่เก็บข้อมูล 1 = หลายโครงการ ตัวอย่างเช่น: https://github.com/donhuvy/java_examples

1 โครงการ = เก็บจำนวนมาก ตัวอย่างเช่น: https://github.com/zendframework/zendframework (1 โครงการชื่อ Zend Framework 3 มี 61 + 1 = 62 ที่เก็บไม่เชื่ออย่าปล่อยให้นับโมดูลของ Zend Framework + ที่เก็บหลัก)

ฉันเห็นด้วยกับความคิดเห็นของ@Brandon Ibbotson ทั้งหมด :

พื้นที่เก็บข้อมูล GitHub เป็นเพียง "ไดเรกทอรี" ที่โฟลเดอร์และไฟล์สามารถมีอยู่

สำหรับคำศัพท์คอมไพล์โครงการคือโฟลเดอร์ที่เนื้อหา (ไฟล์) ใช้งานจริง โดยที่Repository เป็น repositoryที่ git เก็บบันทึกการเปลี่ยนแปลงทุกอย่างในโฟลเดอร์project แต่โดยทั่วไปแล้วทั้งสองนี้ถือได้ว่าเหมือนกัน โครงการ = พื้นที่เก็บข้อมูล

ความแตกต่างทางแนวคิดในความเข้าใจของฉันคือโครงการสามารถมี repo จำนวนมากและเป็นอิสระต่อกันขณะที่ repo อาจมีหลายโครงการพร้อมกัน Repo เป็นเพียงแหล่งเก็บข้อมูลสำหรับรหัสในขณะที่โครงการกำลังรวบรวมงานสำหรับคุณสมบัติบางอย่าง

มันสมเหตุสมผลไหม repo ขนาดใหญ่สามารถมีโครงการจำนวนมากที่ทำงานโดยคนที่แตกต่างกันในเวลาเดียวกัน (คุณสมบัติที่แตกต่างมากมายถูกเพิ่มเข้าไปใน monolith) โครงการขนาดใหญ่อาจมี repos ขนาดเล็กจำนวนมากที่แยกจากกัน แต่เป็นส่วนหนึ่งของโครงการเดียวกันที่โต้ตอบกับแต่ละโครงการ อื่น ๆ - บริการขนาดเล็ก? มันเป็นเรื่องส่วนตัวในสิ่งที่คุณต้องการจะทำ ฉันคิดว่า repo (พื้นที่เก็บข้อมูล) vs project (task) เป็นข้อแตกต่างที่สำคัญ - ถ้าฉันผิดโปรดแจ้งให้เราทราบ / อธิบาย! ขอบคุณ

นี่คือความเข้าใจส่วนตัวของฉันเกี่ยวกับหัวข้อ

สำหรับโครงการเราสามารถควบคุมเวอร์ชันได้ด้วยที่เก็บต่างๆ และสำหรับพื้นที่เก็บข้อมูลก็สามารถจัดการโครงการทั้งหมดหรือบางส่วนของโครงการ

เกี่ยวกับโครงการของคุณ (แอปพลิเคชันต้นแบบหลายตัวที่ไม่ขึ้นอยู่กับแต่ละแอปพลิเคชัน) คุณสามารถจัดการโครงการด้วยที่เก็บหนึ่งแห่งหรือที่เก็บหลายแห่งความแตกต่าง:

1. จัดการโดยหนึ่งที่เก็บ หากมีการเปลี่ยนแปลงหนึ่งในแอปพลิเคชั่นโครงการทั้งหมด (แอปพลิเคชันทั้งหมด) จะถูกกำหนดให้เป็นเวอร์ชั่นใหม่

2. จัดการโดยที่เก็บหลายแห่ง หากมีการเปลี่ยนแปลงแอปพลิเคชันเดียวจะมีผลกับที่เก็บซึ่งจัดการแอปพลิเคชันเท่านั้น เวอร์ชันสำหรับที่เก็บอื่นไม่ถูกเปลี่ยน