ผู้ทำงานร่วมกันในที่เก็บ Github ส่วนตัวแต่ละแยก repo หรือไม่

ฉันกำลังทำงานในโครงการในขณะนี้และเรามีซอร์สโค้ดในที่เก็บส่วนตัวบน Github โดยที่เราทุกคนเป็นผู้ทำงานร่วมกัน

สิ่งที่เราไม่ชัดเจนคือวิธีแยกงานของเราออกจากกัน

สิ่งที่ฉันคิดว่าเราต้องทำคือ:

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

เมื่อพูดถึงที่เก็บข้อมูลส่วนตัวนี่คือสิ่งที่การฟอร์กควรจะใช้หรือฉันกำลังอธิบายสถานการณ์มากเกินไปหรือไม่?

— JMK
แหล่งที่มา

ใช่. ทำเช่นเดียวกับที่คุณแนะนำที่นี่เพียงสร้างทีมและทำให้ repo ของทีมเป็น "repo" หลัก ทุกคนทำ PRs รวมถึงหัวหน้าโครงการ

— RubberDuck

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

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

ในทีมขนาดเล็กที่เชื่อถือได้นี่ไม่จำเป็น เพื่อป้องกันไม่ให้คนอื่นเข้ามาในทางซึ่งกันและกันสามารถใช้กลยุทธ์เช่น Git Flow: แต่ละคุณลักษณะขนาดเล็กจะถูกนำไปใช้ในสาขาคุณลักษณะแยกต่างหาก เมื่อคุณสมบัติเสร็จสมบูรณ์แล้วจะถูกรวมเข้ากับสาขาหลัก ทีมส่วนใหญ่จะจับคู่กับคำขอดึงหรือการตรวจสอบรหัสตามการประชุม แต่เชื่อถือได้พอที่จะข้ามได้ถ้าเหมาะสม ในขณะที่ repos ที่แยกจากกันจะนำไปสู่นักพัฒนาที่เผยแพร่สถานะปัจจุบันของพวกเขาบน repos ที่แยกกัน แต่มองเห็นได้เป็นทีมใน repo ที่ใช้ร่วมกันเพียงครั้งเดียว การพัฒนาบน master / trunk ทั้งหมดนั้นเป็นสิ่งกีดขวางอย่างมากในเวิร์กโฟลว์ส่วนใหญ่

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

— อมร
แหล่งที่มา

เพื่อสะท้อนสิ่งที่ @amon พูดอย่างรวดเร็วฉันได้ทำงานในองค์กรที่นักพัฒนาทุกคนต้องแยกจาก repo หลักซึ่งเราทุกคนรู้สึกว่าเป็นเพียงขั้นตอนที่ไม่จำเป็นและไม่จำเป็น ฉันไม่เคยเข้าใจเลยว่าทำไมมันถึงจำเป็น แต่ทีม ops ของเราจะไม่พูดถึงมัน กระบวนการคือ: commit -> push -> pull request -> wait -> รอมากกว่านี้ -> พยายามรับความสนใจของทีม ops เกี่ยวกับ IRC -> เดินไปที่ ops guys และขอให้พวกเขาดูคำขอ pull -> รอ -> รหัสรวม -> ทำซ้ำ

— DaveyDaveDave

ฉันไม่สนับสนุนกระบวนการทำงานนี้ ฉันเคยประสบความขัดแย้งในการผสานที่ไม่ดีกับนักพัฒนาสองคนทั้งสองผลักไปที่ repo ซึ่งเป็นที่ยอมรับ ไม่ต้องพูดถึงมันเป็นการดีที่สุดที่จะให้คนอื่นตรวจสอบรหัสของคุณ มันง่ายกว่ามากที่จะส่งคำขอดึงหากคุณมีทางแยกและมี repo โครงการหนึ่งที่ยอมรับ ใช่แล้ว ฉันรู้ว่านั่นไม่ใช่ "กระจาย" อะไรก็ตาม โมเดล fork & PR ทำงานได้ดีขึ้นในประสบการณ์ของฉัน

— RubberDuck

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

— DaveyDaveDave

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

— Rudolf Olah

สิ่งนี้จะได้ผลหรือคุณสามารถใช้วิธีการแยกสาขาที่แต่ละ contrib มีสาขาของตัวเองซึ่งเมื่อทีมเห็นด้วยจะรวมกับเจ้านาย

— Margeaux Spring
แหล่งที่มา

ขอบคุณจะไปกับคำตอบที่อื่น ๆ ที่มีรายละเอียดมากขึ้น แต่ใช่ฉันเห็นด้วย :)

— JMK