แบบแผนการตั้งชื่อที่ดีสำหรับสาขาที่มีชื่อใน {DVCS} ที่คุณเลือก

16

เรากำลังผสานรวม Mercurial อย่างช้าๆในสำนักงานของเราและทำการพัฒนาเว็บไซต์ที่เราเริ่มใช้สาขาที่มีชื่อ

เราไม่พบธรรมเนียมที่ดีเท่าการตั้งชื่อสาขาของเรา

พวกเราเหนื่อย:

FeatureName (สามารถเห็นสิ่งนี้ทำให้เกิดปัญหาในบรรทัด)
DEVInitial_FeatureName (อาจสับสนเมื่อนักพัฒนาเข้ามาและลงไปที่บรรทัด)
{uniqueID (int)} _ คุณสมบัติ

จนถึงตอนนี้ uniqueID_featureName กำลังชนะเรากำลังคิดที่จะเก็บมันไว้ในฐานข้อมูลขนาดเล็กเพื่อใช้อ้างอิง

มันจะมี: branchID (int), featureName (varchar), featureDescription (varchar), วันที่, ใคร ฯลฯ ...

สิ่งนี้จะทำให้เราสาขาเช่น: 1_NewWhizBangFeature, 2_NowWithMoreFoo, ... และเราจะมีการอ้างอิงง่าย ๆ ว่าสาขานั้นทำอะไรโดยไม่ต้องตรวจสอบบันทึก

ทางออกที่ดีกว่าออกมี?

version-control mercurial

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

14

หากคุณไม่มีตัวติดตามปัญหาฉันขอแนะนำให้ตั้งค่าแล้วใช้ {issue tracker name} _ {หมายเลขตั๋ว} เมื่อมีคนอีกหลายปีนับจากนี้ส่งข้อผิดพลาดและคุณไม่ทราบว่าคุณลักษณะควรทำงานอย่างไรมันจะง่ายในการใส่คำอธิบายประกอบไฟล์และกลับไปที่ที่ผู้ใช้อาจร้องขอการทำงานที่แน่นอน

— Asa Ayers
แหล่งที่มา

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

— jfrobishow

5

คุณควรจะสร้างตั๋วสำหรับคุณสมบัติใหม่ เป็นงานที่ต้องติดตามด้วย +1 สำหรับการกำหนดรหัสเฉพาะ

— AShelly

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

— Asa Ayers

2

ฉันขอแนะนำให้ทำให้มันง่ายและตั้งชื่อสาขาตามFeatureName(หรือfeature-name ) การประชุม ใช่นี่หมายถึงเนมสเปซที่แชร์ แต่นี่ไม่ค่อยมีปัญหาในโลกแห่งความเป็นจริง เมื่อคุณสมบัติเสร็จสิ้นและรวมเข้ากับการฉีดอย่างสมบูรณ์สาขาสามารถลบได้อย่างปลอดภัย

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

— Adam Byrtek
แหล่งที่มา

1

ฉันเห็นด้วยนี่คือวิธีที่จะไป คุณจะมีสาขาอะไรในโลกที่คุณไม่สามารถหลีกเลี่ยงการชนกันได้?

— ทางเลือก

ยุติธรรมพอรับรายละเอียดที่เชื่อมโยงกับชื่อที่ฉันคิดว่าสำคัญสำหรับเรา ... ความมุ่งมั่นครั้งแรกควรมี แต่ฉันไม่รู้วิธีที่จะดึงข้อมูลออกมาอย่างรวดเร็ว

— jfrobishow

1

ในสภาพแวดล้อมขององค์กรขนาดใหญ่การให้นักพัฒนาสร้างชื่อสำหรับฟีเจอร์จะทำให้ปวดหัวไม่ช้าก็เร็ว

— AShelly

1

ฉันเห็นเพราะในนักพัฒนา "สภาพแวดล้อมขององค์กรขนาดใหญ่" ไม่สามารถเชื่อถือได้ แต่เดี๋ยวก่อนพวกมันยังสร้างชื่อตัวแปรฟังก์ชั่นและไฟล์ เราควรจัดตั้งคณะกรรมการเพื่อควบคุมสิ่งนั้นด้วย! (ประชด)

— Adam Byrtek

2

ฉันขอแนะนำให้ใช้แบบฟอร์มดังกล่าว (เป็นตัวอย่าง):

BUG_ID
BUG # ID
TICKET_ID
TICKET # ID
feature_bla-BLA BLA-
ปล่อย x.xx.xx
release_x.xx.xx
build_2010-20-12
build_4565
BRANCH_x.xx.xx

เพียงเลือกคำนำหน้าดี (เพื่อให้ตัวกรองเอาต์พุตจากสาขา hg ) กฎการใช้ตัวพิมพ์ใหญ่และตัวคั่นระหว่างคำนำหน้ากับ ID / ชื่อ

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

+1 เราไปด้วย BUGID_ {freeCamelCasedTextDescription} ในที่สุด

— jfrobishow