ความถี่ในการส่งมอบการเปลี่ยนแปลงการควบคุมแหล่งที่มา? [ปิด]

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

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

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

ทุกครั้งที่ฉันกรอกรหัส "เต็มความคิด" ที่รวบรวมและเรียกใช้ฉันจะเช็คอิน ซึ่งมักจะจบลงที่ใดก็ได้ระหว่าง 15-60 นาที บางครั้งอาจนานกว่านี้ แต่ฉันพยายามเช็คอินเสมอหากมีการเปลี่ยนแปลงรหัสจำนวนมากที่ฉันไม่ต้องการเขียนใหม่ในกรณีที่เกิดข้อผิดพลาด ฉันมักจะตรวจสอบให้แน่ใจว่ารหัสของฉันรวบรวมและฉันเช็คอินในตอนท้ายของวันทำงานก่อนที่ฉันจะกลับบ้าน

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

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

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

ฉันชอบบทความเล็ก ๆ นี้จาก Jeff Atwood: เช็คอินก่อนเช็คอินบ่อย

ฉันยอมรับรหัสกลุ่มตรรกะที่เสร็จสิ้นแล้ว / เสถียร / รวบรวมและพยายามที่จะไม่ออกจากวันโดยไม่ยอมรับสิ่งที่ฉันทำในวันนั้น

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

ฉันทำทุกครั้งที่ทำภารกิจ ซึ่งมักใช้เวลา 30 นาทีถึง 1 ชั่วโมง

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

ฉันทำตามโอเพนซอร์ส (ถอดความ) - กระทำเร็วกระทำบ่อย

โดยทั่วไปเมื่อใดก็ตามที่ฉันคิดว่าฉันได้เพิ่มฟังก์ชั่นที่มีประโยชน์ (ไม่ว่าจะเล็ก) โดยไม่มีปัญหาสำหรับสมาชิกในทีมคนอื่น ๆ

กลยุทธ์ที่ใช้บ่อยครั้งนี้มีประโยชน์อย่างยิ่งในสภาพแวดล้อมการรวมแบบต่อเนื่องเนื่องจากสามารถทดสอบการรวมกับความพยายามในการพัฒนาอื่น ๆ

อย่าส่งรหัสที่ใช้งานไม่ได้จริง ๆ อย่าใช้ที่เก็บของคุณเป็นโซลูชันสำรอง

ให้สำรองข้อมูลรหัสที่ไม่สมบูรณ์ของคุณไว้ภายในด้วยวิธีอัตโนมัติ Time Machine ดูแลฉันและมีโปรแกรมฟรีมากมายสำหรับแพลตฟอร์มอื่น ๆ

กฎง่ายๆที่ฉันใช้คือการเช็คอินเมื่อกลุ่มของไฟล์ที่กำลังเช็คอินสามารถถูกปกคลุมด้วยความคิดเห็นเช็คอินเดียว

นี่คือโดยทั่วไปเพื่อให้แน่ใจว่าการเช็คอินเป็นอะตอมและความคิดเห็นสามารถถูกย่อยโดยนักพัฒนาอื่น ๆ ได้อย่างง่ายดาย

โดยเฉพาะอย่างยิ่งเมื่อการเปลี่ยนแปลงของคุณมีผลกับไฟล์กำหนดค่า (เช่นไฟล์บริบทสปริงหรือไฟล์กำหนดค่า struts) ที่มีขอบเขตกว้างของแอปพลิเคชัน หากคุณทำการเปลี่ยนแปลง 'กลุ่ม' หลายอย่างก่อนที่จะเช็คอินผลกระทบของมันจะทับซ้อนกันในไฟล์การกำหนดค่าทำให้ทั้ง 2 กลุ่มรวมเข้าด้วยกัน

ฉันไม่คิดว่าคุณควรกังวลมากเกี่ยวกับความถี่ สิ่งสำคัญที่นี่คืออะไรเมื่อใดและทำไม การบอกว่าคุณต้องทำทุก ๆ 3 ชั่วโมงหรือทุก ๆ 24 ชั่วโมงก็ไม่สมเหตุสมผล กระทำเมื่อคุณมีบางสิ่งที่จะต้องทำไม่ใช่ถ้าคุณไม่มี

นี่คือสารสกัดจากแนวทางปฏิบัติที่ดีที่สุดที่ฉันแนะนำสำหรับการควบคุมเวอร์ชัน :

[... ] หากคุณทำการเปลี่ยนแปลงหลายอย่างในโครงการในเวลาเดียวกันให้แบ่งพวกมันออกเป็นส่วนตรรกะและคอมมิทเหล่านั้นในหลาย ๆ เซสชัน สิ่งนี้ทำให้ง่ายต่อการติดตามประวัติของการเปลี่ยนแปลงแต่ละอย่างซึ่งจะช่วยให้คุณประหยัดเวลาได้มากเมื่อพยายามค้นหาและแก้ไขข้อบกพร่องในภายหลัง ตัวอย่างเช่นหากคุณใช้งานคุณสมบัติ A, B และ C และแก้ไขข้อบกพร่องที่ 1, 2 และ 3 นั่นควรจะส่งผลให้รวมอย่างน้อยหกคอมมิชชันหนึ่งอันสำหรับแต่ละฟีเจอร์และอีกอันสำหรับแต่ละบั๊ก หากคุณกำลังทำงานกับคุณสมบัติที่ยิ่งใหญ่หรือทำการปรับโครงสร้างใหม่อย่างกว้างขวางพิจารณาแยกงานของคุณออกเป็นส่วนย่อย ๆ และทำการคอมมิตหลังจากแต่ละส่วนเสร็จสมบูรณ์ นอกจากนี้เมื่อใช้การเปลี่ยนแปลงที่เป็นอิสระกับโมดูลโลจิคัลหลายโมดูลให้คอมมิตการเปลี่ยนแปลงแต่ละโมดูลแยกกันแม้ว่าจะเป็นส่วนหนึ่งของการเปลี่ยนแปลงที่ยิ่งใหญ่

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

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

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

นี่คือบล็อกโพสต์ที่เกี่ยวข้อง: Coding Horror: Check In Early, Check In บ่อย

ดังที่คนอื่น ๆ ได้กล่าวไว้ลองใช้ตรรกะอันหนึ่งที่ "สมบูรณ์" พอที่จะไม่ได้รับการพัฒนาอย่างอื่น (เช่นสร้างและผ่านการทดสอบอัตโนมัติ)

แต่ละทีม dev / บริษัท จะต้องกำหนดสิ่งที่ "สมบูรณ์พอ" สำหรับแต่ละสาขา ตัวอย่างเช่นคุณอาจมีสาขาคุณลักษณะที่ต้องใช้รหัสในการสร้างเท่านั้น Trunk ที่ต้องใช้รหัสในการผ่านการทดสอบอัตโนมัติและป้ายกำกับที่ระบุสิ่งที่ผ่านการทดสอบ QA ... หรืออะไรทำนองนั้น

ฉันไม่ได้บอกว่านี่เป็นรูปแบบที่ดีที่จะติดตาม ฉันแค่ชี้ให้เห็นว่าการ "เสร็จสิ้น" ขึ้นอยู่กับนโยบายของทีม / บริษัท ของคุณ

ช่วงเวลาที่คุณคิดเกี่ยวกับมัน

(ตราบเท่าที่สิ่งที่คุณเช็คอินปลอดภัย)

ขึ้นอยู่กับระบบซอร์สโค้ดของคุณและสิ่งอื่นที่คุณมี หากคุณใช้ Git ให้ทำทุกครั้งที่เสร็จสิ้นขั้นตอน ฉันใช้ SVN และฉันต้องการส่งมอบเมื่อฉันทำคุณสมบัติทั้งหมดเสร็จทุกหนึ่งถึงห้าชั่วโมง ถ้าฉันใช้ CVS ฉันก็ทำเช่นเดียวกัน

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

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

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

ฉันชอบเช็คอินเป็นประจำ นั่นคือทุกครั้งที่ฉันทำตามเป้าหมาย

นี่คือมักจะสองชั่วโมงทุก

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

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

1. ทำงานมากขึ้นต่อการเช็คอิน; checkins น้อย == ความคิดเห็นน้อย
2. เปลี่ยนนโยบายการเช็คอินของ บริษัท หากฉันเพิ่งทำการปรับโครงสร้างใหม่และหน่วยทดสอบทำงานเป็นสีเขียวทั้งหมดฉันอาจผ่อนคลายกฎได้หรือไม่
3. ยกเลิกการเปลี่ยนแปลงจนกว่าจะมีใครสามารถตรวจสอบและทำงานต่อไปได้ นี่อาจเป็นปัญหาได้หากผู้ตรวจสอบไม่ชอบรหัสและต้องออกแบบใหม่ การเล่นปาหี่ขั้นตอนที่แตกต่างกันของงานโดยการเปลี่ยนแปลง 'การเก็บเข้าลิ้นชัก' จะกลายเป็นความยุ่งเหยิง

ฉันชอบที่จะคอมมิชชันการเปลี่ยนแปลงทุก ๆ 30-60 นาทีตราบใดที่มันรวบรวมอย่างหมดจดและไม่มีการถดถอยในการทดสอบหน่วย

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

ในความถี่ของการกระทำฉันคิดอย่างนี้ความเจ็บปวดจะเกิดขึ้นกับฉันมากแค่ไหนถ้าฮาร์ดดิสก์ของฉันเกิดขัดข้องและฉันไม่ได้ทำอะไรเลย - ปริมาณของสิ่งนี้สำหรับฉันใช้เวลาประมาณ 2 ชั่วโมง

แน่นอนฉันไม่เคยกระทำสิ่งที่ไม่ได้รวบรวม

อย่างน้อยวันละครั้ง

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

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

รูปแบบที่ดีที่สุดที่ฉันเคยใช้มีสองคำตอบสำหรับคำถามนั้น

เราใช้ที่เก็บข้อมูลที่แยกจากกัน 2 แห่งโดยที่หนึ่งคือที่เก็บโครงการกว้างและอีกแห่งเป็นที่เก็บข้อมูลส่วนตัวของเรา (เราใช้ rcs ในเวลานั้น)

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

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

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

อย่างไรก็ตามฉันมีผลลัพธ์ที่ยอมรับได้โดยการสร้างสาขาการพัฒนา "ส่วนบุคคล" ในพื้นที่เก็บข้อมูลการโค่นล้ม - ตรวจสอบเข้าไปในสาขาอย่างสม่ำเสมอ

หากคุณกำลังทำงานในสาขาที่ไม่ได้รับการเปิดเผยความมุ่งมั่นนั้นปลอดภัยเสมอ

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

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

ฉันยังเชื่อในวลี 'กระทำบ่อย ๆ แต่เช้า' ฉันชอบ VCS แบบกระจายอำนาจเช่นMercurialและไม่มีปัญหาในการคอมมิทหลายสิ่งและผลักดันอัปสตรีมในภายหลัง

นี่เป็นคำถามที่พบบ่อย แต่คำถามที่แท้จริงคือ: คุณสามารถส่งรหัสที่ยังไม่เสร็จได้หรือไม่?

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

และโปรดตรวจสอบให้แน่ใจว่าคุณแสดงความคิดเห็นอย่างถูกต้อง