จะใช้ SVN, สาขาได้อย่างไร? แท็ก? กระโปรงหลังรถ?

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

สิ่งที่ฉันต้องการล้างคือหัวข้อต่อไปนี้:

• คุณยอมรับบ่อยแค่ไหน? ในฐานะที่เป็นมักจะเป็นหนึ่งจะกดCtrl+ s?
• สาขาคืออะไรและแท็กคืออะไรและคุณควบคุมได้อย่างไร
• SVN คืออะไร? เฉพาะซอร์สโค้ดหรือคุณแชร์ไฟล์อื่นที่นี่เช่นกัน? (ไม่ถือว่าเป็นไฟล์ที่มีเวอร์ชัน .. )

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

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

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

คุณยังคงพัฒนาในสาขาหรือในลำต้น

กลยุทธ์การแยกทาง

ฉันถามตัวเองด้วยคำถามเดียวกันเมื่อเรานำ Subversion มาใช้ที่นี่นักพัฒนาประมาณ 20 คนกระจายกันทั่วโครงการ 4 - 6 โครงการ ฉันไม่พบแหล่งที่ดีที่มี '' คำตอบ '' นี่คือบางส่วนของวิธีที่คำตอบของเราพัฒนาขึ้นในช่วง 3 ปีที่ผ่านมา:

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

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

- เราแทบจะไม่ใช้แท็กแม้ว่าเราคิดว่าเราควรจะใช้แท็กเหล่านี้เพื่อระบุรุ่นที่จะออกสู่การผลิต

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

ธงในถนนเรียกว่า 'แท็ก' และส้อมบนท้องถนนจะแบ่งออกเป็น 'สาขา' บางครั้งกิ่งก้านก็กลับมารวมกัน

- เราใส่เนื้อหาทั้งหมดที่จำเป็นในการสร้างไฟล์เรียกทำงาน (หรือระบบ) ลงในที่เก็บ; นั่นหมายความว่าอย่างน้อยซอร์สโค้ดและสร้างไฟล์ (หรือไฟล์โครงการสำหรับ Visual Studio) แต่เมื่อเรามีไอคอนและไฟล์กำหนดค่าและสิ่งอื่น ๆ ทั้งหมดนั่นจะเข้าสู่พื้นที่เก็บข้อมูล เอกสารบางเล่มพบว่าเป็นของ repo; แน่นอนว่าเอกสารใด ๆ เช่นไฟล์ช่วยเหลือที่อาจเป็นส่วนหนึ่งของโปรแกรมและเป็นสถานที่ที่มีประโยชน์ในการวางเอกสารสำหรับนักพัฒนา

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

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

* How often do you commit? As often as one would press ctrl + s?

บ่อยเท่าที่เป็นไปได้. รหัสไม่มีอยู่เว้นแต่จะอยู่ภายใต้การควบคุมแหล่งที่มา :)

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

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

เมื่อฉันทำงานในสาขาของตัวเองฉันชอบที่จะกระทำให้มากที่สุดเท่าที่จะทำได้

* What is a Branch and what is a Tag and how do you control them?

อ่านหนังสือ SVN - เป็นที่ที่คุณควรเริ่มเมื่อเรียนรู้ SVN:

• สาขาคืออะไร
• แท็ก

* What goes into the SVN?

เอกสาร, ไบนารีขนาดเล็กที่จำเป็นสำหรับการสร้างและสิ่งอื่น ๆ ที่มีค่าบางอย่างไปที่การควบคุมแหล่งที่มา

ต่อไปนี้เป็นแหล่งข้อมูลเกี่ยวกับความถี่ในการส่งมอบข้อความโครงสร้างโครงการสิ่งที่ต้องควบคุมภายใต้แหล่งข้อมูลและแนวทางทั่วไปอื่น ๆ :

• วิธีปฏิบัติที่ดีที่สุดของการควบคุมเวอร์ชัน (บล็อกของตัวเอง)
• เช็คอินก่อนเวลาเช็คอินบ่อยครั้ง (เขียนรหัสสยองขวัญ) (ความคิดเห็นที่นี่มีคำแนะนำที่ดีมากมาย)
• นโยบายการกระทำของ KDE

คำถาม Stack Overflow เหล่านี้ยังมีข้อมูลที่เป็นประโยชน์ที่อาจเป็นที่สนใจ:

• การจัดระเบียบฐานรหัสต้นฉบับเมื่อผสมสองภาษาขึ้นไป (เช่น Java และ C ++)
• คำแนะนำสำหรับข้อความยืนยันที่ดี: รูปแบบ / แนวทาง?
• ความถี่ในการส่งมอบการเปลี่ยนแปลงการควบคุมแหล่งที่มา?
• การเรียนรู้การควบคุมเวอร์ชันและการเรียนรู้ที่ดี

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

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

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

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

สาขาสามารถใช้ในหนึ่งในสองวิธีโดยทั่วไป: 1) สาขาหนึ่งที่ใช้งานอยู่สำหรับการพัฒนา (และลำต้นยังคงมีเสถียรภาพ) หรือ 2) สาขาสำหรับเส้นทาง dev อื่น

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

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

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

เราได้รับลำต้น -> กิ่งก้านสาขา -> ผลิตผล (แท็ก / รีลีส)

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

แท็กเป็นสิ่งที่ส่งมอบเป็นหลัก ในขณะที่ลำต้นและกิ่งก้านผลิต

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

คุณยอมรับบ่อยแค่ไหน? บ่อยเท่าที่ใครจะกด ctrl + s?

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

สาขาคืออะไรและแท็กคืออะไรและคุณควบคุมได้อย่างไร

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

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

SVN คืออะไร? เฉพาะซอร์สโค้ดหรือคุณแชร์ไฟล์อื่นที่นี่เช่นกัน?

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

Eric Sink ที่ปรากฏใน SO podcast # 36 ในเดือนมกราคม 2009 ได้เขียนบทความที่ยอดเยี่ยมภายใต้ชื่อSource Control How-toแหล่งที่มาของการควบคุมวิธีการ

(Eric เป็นผู้ก่อตั้งSourceGearผู้ทำตลาด SourceSafe เวอร์ชันที่เข้ากันได้กับปลั๊กอิน แต่ไม่มีความน่ากลัว)

เพียงเพิ่มคำตอบอีกชุด:

• ฉันทำทุกครั้งที่ทำงานเสร็จ บางครั้งมันเป็นข้อผิดพลาดเล็ก ๆ ที่เพิ่งเปลี่ยนหนึ่งบรรทัดและฉันใช้เวลา 2 นาทีในการทำ; บางครั้งมันก็มีค่าเหงื่อสองสัปดาห์ นอกจากนี้ตามกฎทั่วไปคุณไม่ต้องทำสิ่งใดที่ทำลายการสร้าง ดังนั้นหากคุณใช้เวลานานในการทำบางสิ่งบางอย่างให้ใช้เวอร์ชันล่าสุดก่อนที่จะส่งมอบและดูว่าการเปลี่ยนแปลงของคุณทำลายโครงสร้างหรือไม่ แน่นอนถ้าฉันไปเป็นเวลานานโดยไม่ต้องทำอะไรมันก็ทำให้ฉันรู้สึกไม่สบายใจเพราะฉันไม่อยากทำงานแบบนั้น ใน TFS ฉันใช้สิ่งนี้ดีเป็น "ชั้นวาง" สำหรับสิ่งนี้ ใน SVN คุณจะต้องหลีกเลี่ยงอีกทางหนึ่ง อาจสร้างสาขาของคุณเองหรือสำรองไฟล์เหล่านี้ด้วยตนเองไปยังเครื่องอื่น
• สาขาเป็นสำเนาของโครงการทั้งหมดของคุณ ภาพประกอบที่ดีที่สุดสำหรับการใช้งานอาจเป็นเวอร์ชันของผลิตภัณฑ์ ลองนึกภาพว่าคุณกำลังทำงานในโครงการขนาดใหญ่ (เช่นเคอร์เนล Linux) หลังจากหลายเดือนของเหงื่อในที่สุดคุณก็มาถึงรุ่น 1.0 ที่คุณปล่อยสู่สาธารณะ หลังจากนั้นคุณเริ่มทำงานกับผลิตภัณฑ์เวอร์ชัน 2.0 ของคุณซึ่งกำลังจะดีขึ้น แต่ในขณะเดียวกันก็มีผู้คนมากมายที่ใช้เวอร์ชั่น 1.0 และคนเหล่านี้พบข้อบกพร่องที่คุณต้องแก้ไข ตอนนี้คุณไม่สามารถแก้ไขข้อผิดพลาดในรุ่น 2.0 ที่กำลังจะมาถึงและส่งให้กับลูกค้า - ยังไม่พร้อมเลย แต่คุณต้องดึงสำเนาเก่าของแหล่ง 1.0 แก้ไขข้อผิดพลาดที่นั่นและจัดส่งให้กับผู้คน นี่คือสิ่งที่สาขามีไว้สำหรับ เมื่อคุณปล่อย 1 0 เวอร์ชันที่คุณสร้างสาขาใน SVN ซึ่งสร้างสำเนาของซอร์สโค้ด ณ จุดนั้น สาขานี้มีชื่อว่า "1.0" จากนั้นคุณยังคงทำงานในเวอร์ชันถัดไปในแหล่งข้อมูลหลักของคุณ แต่ยังคงมี 1.0 สำเนาอยู่เหมือนเดิมในขณะที่วางจำหน่าย และคุณสามารถแก้ไขบั๊กที่นั่นได้ แท็กเป็นชื่อที่แนบมากับการแก้ไขเฉพาะเพื่อความสะดวกในการใช้งาน คุณสามารถพูดว่า "การแก้ไข 2342 ของซอร์สโค้ด" แต่ง่ายต่อการอ้างถึงว่าเป็น "การแก้ไขที่เสถียรครั้งแรก" :)
• ฉันมักจะใส่ทุกอย่างในแหล่งควบคุมที่เกี่ยวข้องโดยตรงกับการเขียนโปรแกรม ตัวอย่างเช่นเนื่องจากฉันกำลังสร้างเว็บเพจฉันก็ใส่รูปภาพและไฟล์ CSS ในการควบคุมแหล่งที่มาไม่ต้องพูดถึงไฟล์กำหนดค่าเป็นต้นเอกสารประกอบโครงการไม่ได้เข้าที่นั่น แต่จริง ๆ แล้วเป็นเรื่องของการตั้งค่า

คนอื่น ๆ ระบุว่ามันขึ้นอยู่กับสไตล์ของคุณ

คำถามใหญ่สำหรับคุณคือความถี่ที่คุณ "รวม" ซอฟต์แวร์ของคุณ การพัฒนาแบบทดสอบที่ขับเคลื่อน Agile และ Scrum (และอื่น ๆ อีกมากมาย) ขึ้นอยู่กับการเปลี่ยนแปลงเล็กน้อยและการรวมอย่างต่อเนื่อง พวกเขาเทศนาว่ามีการเปลี่ยนแปลงเล็กน้อยทุกคนค้นพบการหยุดพักและแก้ไขพวกเขาตลอดเวลา

อย่างไรก็ตามในโครงการขนาดใหญ่ (คิดว่ารัฐบาลกลาโหม 100k + LOC) คุณไม่สามารถใช้การรวมอย่างต่อเนื่องเพราะมันเป็นไปไม่ได้ ในสถานการณ์เหล่านี้อาจเป็นการดีกว่าที่จะใช้การแยกสาขาเพื่อทำข้อผูกพันเล็ก ๆ น้อย ๆ แต่นำกลับเข้าไปในลำต้นเฉพาะสิ่งที่จะใช้งานได้และพร้อมที่จะรวมเข้ากับตัวสร้าง

ข้อแม้อย่างหนึ่งที่มีการแตกแขนงก็คือถ้าพวกมันจัดการไม่ถูกต้องมันอาจเป็นฝันร้ายในพื้นที่เก็บข้อมูลของคุณเพื่อทำงานในลำตัวเนื่องจากทุกคนกำลังพัฒนาจากจุดต่าง ๆ บนลำต้น (ซึ่งเป็นข้อโต้แย้งที่ใหญ่ที่สุดข้อหนึ่งสำหรับ บูรณาการอย่างต่อเนื่อง)

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

การควบคุมเวอร์ชันด้วยการโค่นล้มเป็นแนวทางสำหรับผู้เริ่มต้นและมือเก่า

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

สำหรับการคอมมิชชันฉันใช้กลยุทธ์ต่อไปนี้:

• กระทำบ่อยที่สุด

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

• อย่าทำลายบิลด์บนคอมมิทใด ๆ - มันควรจะเป็นไปได้ที่จะดึงเวอร์ชันของที่เก็บและสร้างมันขึ้นมา

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

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

เช่น svn commit . -m 'bug #201 fixed y2k bug in code'จะบอกทุกคนที่มองประวัติศาสตร์ว่าการแก้ไขนั้นมีไว้เพื่ออะไร

ระบบติดตามบั๊กบางระบบ (เช่น trac) สามารถดูในที่เก็บสำหรับข้อความเหล่านี้และเชื่อมโยงกับตั๋ว ซึ่งทำให้การเปลี่ยนแปลงสิ่งที่เกี่ยวข้องกับตั๋วแต่ละเรื่องง่ายมาก

นโยบายในการทำงานของเราเป็นเช่นนี้ (ทีมนักพัฒนาที่ทำงานกับกรอบงานเชิงวัตถุ):

• อัปเดตจาก SVN ทุกวันเพื่อรับการเปลี่ยนแปลงของวันก่อนหน้า

• กระทำการทุกวันดังนั้นหากคุณป่วยหรือขาดงานในวันถัดไปคนอื่นสามารถเข้ามาแทนที่คุณได้อย่างง่ายดาย

• อย่าส่งรหัสที่ทำลายสิ่งใด ๆ เนื่องจากจะส่งผลต่อผู้พัฒนารายอื่น

• ทำงานชิ้นเล็ก ๆ และกระทำทุกวันด้วยความคิดเห็นที่มีความหมาย!

• ในฐานะทีม: รักษาสาขาการพัฒนาจากนั้นย้ายโค้ดก่อนวางจำหน่าย (สำหรับ QA) ลงในสาขาการผลิต สาขานี้ควรมีรหัสที่ทำงานได้อย่างสมบูรณ์เท่านั้น

คู่มือ TortoiseSVN TSVNอ้างอิงจากหนังสือการโค่นล้มแต่มีให้ในหลายภาษา

ฉันคิดว่ามีสองวิธีเกี่ยวกับการยอมรับความถี่:

1. ให้คำมั่นสัญญาบ่อยครั้งสำหรับแต่ละวิธีที่ถูกนำไปใช้งานส่วนเล็ก ๆ ของรหัส ฯลฯ
2. คอมมิทเฉพาะบางส่วนของโค้ดเช่นโมดูล ฯลฯ

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