ฉันจะควบคุมเวอร์ชันของโปรเจ็กต์ของฉันบน GitHub ได้อย่างไร

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

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

ตอนนี้เวอร์ชัน1.0นั้นเผยแพร่แล้วและเรามีปัญหาบางอย่างที่ยื่นสำหรับเวอร์ชันของซอฟต์แวร์นั้น เราต้องการเริ่มพัฒนาเวอร์ชัน1.1เพื่อแก้ไขปัญหาเหล่านั้นที่เราได้แนะนำโดยเร่งโครงการ

ตอนนี้คำถามคือ:

เราจะควบคุมการควบคุมเวอร์ชันได้อย่างไร?

เราควรจะสร้างสาขาใหม่v1.0และเก็บรุ่น1.0ของซอฟต์แวร์ไว้ที่นั่นและพัฒนาในบางสาขา (หรือไม่) รวมเข้าด้วยmasterกันใช้งานกับเวอร์ชัน1.1หรือไม่

มีการประชุมที่นั่นสำหรับสถานการณ์แบบนั้นเหรอ?

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

คำตอบ:

ฉันได้พบ (และเริ่มปรับใช้) โมเดลสาขาต่อไปนี้ :

ภาพจาก nvie.com

^{(ภาพจากบทความ)}

มีแนวทางปฏิบัติที่ดีมากมายและกฎเข้มงวดที่อธิบายไว้ในบทความนั้นฉันขอแนะนำ

จุดที่น่าสนใจ:

สาขาหลักคือที่ที่คุณติดแท็กเวอร์ชันของคุณ ไม่มีการพัฒนาเกิดขึ้นที่นี่ ในกรณีที่มีข้อผิดพลาดที่ถูกปรับใช้ในการผลิตคุณแก้ไขข้อผิดพลาดในสาขาโปรแกรมแก้ไขด่วนรวมกลับและแท็กรุ่นใหม่
การพัฒนาเกิดขึ้นในส่วนพัฒนาและคุณลักษณะ โดยส่วนตัวแล้วฉันทำการแก้ไขบั๊กในสาขา devel และฟีเจอร์บนฟีเจอร์สาขา
เมื่อซอฟต์แวร์เริ่มเข้าถึงการวางจำหน่ายฉันออกไปเพื่อแยกสาขา สาขาที่วางจำหน่ายเป็นที่ที่ฉันสัมผัสครั้งสุดท้าย หมายเลขเวอร์ชั่น Bump เปลี่ยนข้อมูลเมตาเป็นต้นและแก้ไขข้อผิดพลาดเล็กน้อย เมื่อเสร็จแล้วฉันจะรวมเป็นหลักติดแท็กและเรียกมันว่าเป็นรุ่น
สองสาขาหลัก: อาจารย์คือ "สาขาศักดิ์สิทธิ์"; หัวของมันเป็นรหัสการผลิตล่าสุดเสมอและการพัฒนาเป็นสาขาทุกคืน หัวของมันมักจะสะท้อนถึงการเพิ่มล่าสุด (แต่ไม่เสถียรที่เป็นไปได้) ในรหัส

ในกรณีเฉพาะของคุณขั้นตอนจะขึ้นอยู่กับว่ารุ่นนั้นเป็นอย่างไร หากเป็นคุณลักษณะที่ถูกทิ้งไว้ฉันจะกลับไปที่การพัฒนาและทำสิ่งทั้งหมดอีกครั้ง หากเป็นข้อบกพร่องในรุ่นที่ปรับใช้ฉันจะแยกออกไปยังสาขาโปรแกรมแก้ไขด่วนแก้ไขข้อบกพร่องผสานกลับและแท็ก v1.1 หากเป็นทั้งฉันจะแก้ไขข้อบกพร่องก่อนจากนั้นเพิ่มคุณสมบัติที่สองตามที่อธิบายไว้

— Tamás Szelei
แหล่งที่มา

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

— tugberk

ในคอมไพล์เป้าหมายของการแท็กคือการส่ง หมายความว่าคุณพูดว่า: "นี่คือการกระทำนี้และฉันเรียกมันว่า 'v1.3' นับจากนี้เป็นต้นไป" ในทางปฏิบัติซึ่งหมายความว่าคุณเปลี่ยนไปที่สาขาหลักรวมในสาขา devel (ตอนนี้มีเสถียรภาพ) กระทำและติดแท็ก จากนั้นคุณสามารถแสดงรายการแท็กทั้งหมดเปลี่ยนกลับเป็นรหัสนั้นในกรณีที่คุณต้องการดูว่ามีอะไรเกิดขึ้นบ้างในรีลีสที่ผ่านมา มีแท็กมากกว่าเล็กน้อย (ซึ่งมีประโยชน์สำหรับการพัฒนาแบบกระจายขนาดใหญ่เช่นเคอร์เนล linux) หากคุณสนใจผมขอแนะนำหนังสือ progit

— Tamás Szelei

ProGit เป็นหนึ่งในหนังสือที่ฉันจะอ่านตั้งแต่เริ่มต้น ตอนนี้ฉันแค่อ่านชิ้นส่วนที่ฉันสนใจเพื่อให้งานเสร็จ จนถึงตอนนี้เราได้พัฒนาสาขาหลักและฉันคิดว่าฉันควรจะรักษามัน แต่ฉันจะเปิดสาขาอื่นที่เรียกว่า productionและใช้เป็นmasterสาขาตามโมเดลด้านบน

— tugberk

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

— tugberk

ก่อนอื่นคุณไม่จำเป็นต้องทำตามจดหมายเพียงแค่สร้างกฎที่คุณเก็บไว้ ทำสิ่งที่ดีที่สุดสำหรับคุณและสไตล์ทีมของคุณ ประการที่สองใช่คุณสมบัติหลายอย่างและสาขาที่วางจำหน่ายเป็นเรื่องปกติเว้นแต่คุณจะมีโครงการระยะสั้นที่มีคุณลักษณะเดียวและรุ่นที่วางจำหน่ายหนึ่ง :) การตั้งชื่ออ้างอิงจากบทความนี้คือ release- * และ feature- * ฉันเดาว่าคุณใส่หมายเลขเวอร์ชันในอนาคตแทนเครื่องหมายดอกจันสำหรับการเปิดตัวและรหัสตัวติดตามปัญหาในกรณีที่ฟีเจอร์แบรนช์

— Tamás Szelei

สิ่งที่ฉันเห็นเป็นส่วนใหญ่:

ปริญญาโทสำหรับผลิตภัณฑ์ของคุณ ในที่สุดทุกรุ่นในอนาคตของคุณ x.0 จะอยู่ในระดับปริญญาโท
คุณสร้างแท็ก / สาขาสำหรับแต่ละเวอร์ชันในการผลิตเพื่อให้คุณยังสามารถสนับสนุนพวกเขาสำหรับลูกค้าที่ต้องการ
การรวมการแก้ไขจากอย่างใดอย่างหนึ่งคือการจัดการในแต่ละกรณี

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

ขอบคุณ! ดังนั้นคุณคิดว่ามันมีเหตุผลที่จะให้สาขาชื่อ v1.0, v1.2 มีเหตุผล?

— tugberk

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

— Patrick Mevzek