แนวทางปฏิบัติที่ดีที่สุดของ SVN - การทำงานเป็นทีม

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

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

ขอบคุณสำหรับคำตอบที่ยอดเยี่ยม - พวกเขาช่วยได้มาก

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

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

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

อย่าทำการเปลี่ยนแปลงการจัดรูปแบบด้วยการเปลี่ยนแปลงโค้ด

หากคุณต้องการปรับโครงสร้างช่องว่างของไฟล์ขนาดใหญ่ ( Control+ K+ D) ให้ดี ยอมรับการเปลี่ยนแปลงการจัดรูปแบบแยกจากการเปลี่ยนแปลงทางตรรกะจริง เช่นเดียวกันหากคุณต้องการย้ายฟังก์ชันไปรอบ ๆ ไฟล์ ทำการย้ายแยกจากการแก้ไขจริง

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

มีการกล่าวถึงมากมายแล้วและนี่คือบางส่วนเพิ่มเติม:

1. หากคุณมีไฟล์ที่คุณไม่ต้องการอยู่ในการควบคุมแหล่งที่มา (เช่นการตั้งค่าไฟล์รวบรวม ฯลฯ ) เพิ่มลงในรายชื่อ วิธีนี้จะทำให้คุณสังเกตเห็นไฟล์ใด ๆ ที่คุณลืมเพิ่มโดยคาดหวังรายการไฟล์ว่าง ๆ ที่ SVN ไม่รู้จักเสมอ

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

3. ผสานรวมกับตัวติดตามข้อบกพร่องของคุณเพื่อให้การอ้างอิงถึงการคอมมิตปรากฏในคำขอจุดบกพร่อง / คุณสมบัติพร้อมลิงก์ไปยังส่วนต่าง เครื่องมือติดตามข้อผิดพลาดเช่นMantisBTรองรับสิ่งนี้

4. พิจารณาการรวมเข้ากับการรวมแบบต่อเนื่อง (เช่นCruiseControl.NET ), NAnt for Build และNUnit / VS สำหรับการทดสอบหน่วย วิธีนี้เมื่อรหัสเช็คอินของผู้ใช้หรือในช่วงเวลาที่กำหนดรหัสจะได้รับการคอมไพล์การทดสอบหน่วยจะถูกเรียกใช้และผู้พัฒนาจะได้รับคำติชมของกระบวนการ สิ่งนี้จะแจ้งเตือนคนที่เหลือในทีมด้วยหากพื้นที่เก็บข้อมูลเสีย (เช่นไม่ได้สร้าง)

พื้นฐาน:

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

คำตอบที่ผู้คนให้มานั้นยอดเยี่ยมมาก เรื่องนี้สามารถสรุป doc ใช้ SVN สำหรับปฏิบัติที่ดีที่สุดสำหรับ SVN
ทำซ้ำ:

1. ตั้งค่าโครงสร้างที่เก็บของคุณ (คุณควรมีรูทโปรเจ็กต์ที่มีลำต้นกิ่งก้านและแท็กอยู่ด้านล่าง)
2. เลือกการแตกสาขานโยบายของคุณ (สาขาส่วนตัวสาขาต่อเหตุการณ์สำคัญ / รุ่น / ข้อผิดพลาด ฯลฯ ) และปฏิบัติตาม - ฉันขอแนะนำให้แยกสาขามากกว่าน้อยกว่า แต่ไม่จำเป็นต้องมีสาขาส่วนตัว
3. เลือกการติดแท็กใหม่ตามนโยบายของคุณ - แท็กยิ่งมากยิ่งดี แต่ที่สำคัญที่สุดคือตัดสินใจเกี่ยวกับรูปแบบการตั้งชื่อแท็กของคุณ
4. เลือกนโยบายของคุณที่จะดำเนินการตามขั้นตอน - รักษาลำต้นให้ "สะอาด" ที่สุดเท่าที่จะเป็นไปได้ควรปล่อยให้เป็นไปได้ทุกเมื่อ

ฉันต้องการสรุปแนวทางปฏิบัติที่ดีที่สุดที่ฉันยึดถือ:

1. อย่ากระทำไบนารี ควรมีที่เก็บแยกต่างหากสำหรับไบนารีเช่นNexus , IvyหรือArtifactory Artifactory

2. ควรจะมีโครงสร้างที่เก็บ โดยส่วนตัวแล้วฉันใช้โครงสร้างที่เก็บต่อไปนี้:

   /trunk
   /tags
       /builds
           /PA
           /A
           /B
       /releases
           /AR
           /BR
           /RC
           /ST
   /branches
       /experimental
       /maintenance
           /versions
           /platforms
       /releases
   

3. ใช้รายการที่เฉพาะเจาะจงของประเภทสาขา รายชื่อของฉันคือต่อไปนี้: การทดลอง , การบำรุงรักษา , รุ่น , แพลตฟอร์ม , ประชาสัมพันธ์
4. ใช้แท็กประเภทเฉพาะ: PA(pre-alpha), A(alpha), B(beta), AR(alpha-release), BR(beta-release), RC(release amount), ST(stable)
5. ลดความจำเป็นในการรวมให้น้อยที่สุด ควรมีกฎเมื่อการรวมเป็นไปได้ / ได้รับการสนับสนุนและเมื่อไม่เป็นเช่นนั้น
6. รุ่นเลข ควรมีการกำหนดแนวทางการกำหนดหมายเลขเวอร์ชันเพื่อยึดติด โดยปกติจะมีการอธิบายไว้ในเอกสารเช่นแผนการจัดการการกำหนดค่าซอฟต์แวร์ซึ่งเป็นส่วนหนึ่งของเอกสารโครงการระดับสูง โดยส่วนตัวแล้วฉันใช้วิธีการกำหนดหมายเลขเวอร์ชันที่ซับซ้อน ตามแนวทางนี้เวอร์ชันต่างๆจะมีรูปแบบดังต่อไปนี้: Nxx (สาขาการบำรุงรักษา / การสนับสนุน), NMx (สาขาที่วางจำหน่าย), NxK (สร้าง), NMK (รีลีส)
7. กระทำให้บ่อยที่สุดกระทำบ่อยเท่าที่เป็นไปได้หากมีแนวโน้มที่จะยาก (เช่นเมื่อควรมีการเปลี่ยนแปลงมากเกินไปในการใช้คุณลักษณะและแม้แต่คอมไพล์โค้ด) ควรใช้สาขาทดลอง
8. ลำต้นควรมีการพัฒนาล่าสุด ตัวอย่างเช่นเมื่อมีทางเลือกว่าจะพัฒนาแอปพลิเคชันเวอร์ชันหลัก ( Nxx ) ใหม่ได้อย่างไรในลำตัวหรือในสาขาควรตัดสินใจให้ความสำคัญกับลำต้นเสมอ รุ่นเก่าควรจะแยกเข้าไปในการบำรุงรักษาการสนับสนุน /สาขา สันนิษฐานว่ามีความแตกต่างที่ชัดเจนระหว่างเวอร์ชันหลักและข้อมูลจำเพาะ (สถาปัตยกรรมความเข้ากันได้) เกิดขึ้นเร็วที่สุดเร็วที่สุดเท่าที่เป็นไปได้
9. เข้มงวด 'ไม่ทำลายการสร้างนโยบายบนกิ่งไม้ที่วางจำหน่าย ในระหว่างนี้ไม่ควรเข้มงวดกับลำต้นตราบเท่าที่อาจมีทั้งการพัฒนาแบบทดลองหรือโค้ดเบสที่ต้องผสานปัญหาเพื่อแก้ไข
10. ใช้SVN: ภายนอก จะช่วยให้สามารถแยกโครงการของคุณสร้างขั้นตอนการจัดการรุ่นโปร่งใสแบ่งและพิชิตฟังก์ชันการทำงานที่แตกต่าง
11. ใช้ติดตามปัญหา คุณจะสามารถชี้ให้เห็นการอ้างอิงปัญหาในข้อความคอมมิต
12. ปิดการใช้งานที่ว่างเปล่ากระทำข้อความ สามารถทำได้โดยใช้ตะขอก่อนคอมมิต
13. กำหนดสาขาที่คุณต้องการรวมเข้าด้วยกันอย่างต่อเนื่อง ยกตัวอย่างเช่นผมชอบใช้บูรณาการอย่างต่อเนื่องสำหรับลำต้น , การบำรุงรักษาและการเปิดตัวสาขา
14. กำหนดนโยบายการบูรณาการอย่างต่อเนื่องสำหรับสาขาประเภทต่างๆ ขณะที่ผมชี้ให้เห็นก่อนหน้านี้ส่วนใหญ่ที่เข้มงวด "ไม่ทำลายสร้าง" กฎนำไปใช้กับปล่อยสาขาขณะที่ลำต้นและบำรุงรักษาสาขาอาจจะเสียบางครั้ง นอกจากนี้ยังมีความแตกต่างระหว่างรายการการตรวจสอบที่ดำเนินการบนลำต้น / การบำรุงรักษาและการปล่อยสาขา

คุณสามารถค้นหาโครงร่างแนวทางปฏิบัติที่ดีที่สุดในการโค่นล้มของฉันได้ในรูปแบบของแผนภาพที่แสดงหลักการสำคัญของแนวทางการจัดการการกำหนดค่าซอฟต์แวร์ที่ฉันใช้

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

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

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

เรียนรู้เกี่ยวกับการแยกสาขาและการรวมเครื่องมือและอนุสัญญา

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

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

ไมล์สะสมของคุณอาจแตกต่างกันไปและอาจมากเกินไปสำหรับคนสองคนหรือมากกว่านั้น

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

ฉันแนะนำTortoise SVN (ถ้าคุณใช้ Windows) และVisual SVN (ถ้าคุณใช้ VS)

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

นอกเหนือจากนโยบายการแตกแขนงและคณะ (โดยที่ขนาดเดียวไม่พอดีกับทั้งหมด) คุณควรมีความมุ่งมั่นที่ดี:

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

กฎทองสำหรับการควบคุมแหล่งที่มา: Check In Early, Check In บ่อยๆ

สำหรับเคล็ดลับในการจัดระเบียบที่เก็บของคุณ:

• คุณจัดระเบียบที่เก็บการควบคุมเวอร์ชันของคุณอย่างไร
• SVN Book บทที่ 5. การบริหารที่เก็บ
• เค้าโครงที่เก็บ

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

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

หนึ่งในตัวอย่างของการผสานรวมกับตัวติดตามข้อผิดพลาดและการบังคับใช้นโยบายการกระทำอาจเป็นสคริปต์ hooks ก่อน / หลังการกระทำของTracซึ่งสามารถปฏิเสธการกระทำได้หากข้อความที่ส่งไม่ได้อ้างอิงตั๋วใด ๆ ในตัวติดตามข้อบกพร่องและเพิ่มความคิดเห็นไปยังที่มีอยู่ ตั๋วตามเนื้อหาของข้อความ (เช่นข้อความคอมมิตอาจมีบางอย่างเช่น "Fixes # 1, # 2 and # 8" โดยที่ # 1, # 2, # 8 คือหมายเลขตั๋ว)

แนวทางปฏิบัติที่ดีที่สุดในการใช้SVN :

1. เมื่อคุณเข้ามาที่สำนักงานเป็นครั้งแรกและเปิดโปรเจ็กต์Eclipseของคุณขั้นตอนแรกที่ต้องทำคืออัปเดตโปรเจ็กต์ของคุณ

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

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

3. อย่าผูกมัด / อัปเดตไฟล์ข้อขัดแย้งโดยตรง

4. จะลบล้างและอัปเดตเมื่อใด

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

   หมายเหตุ: อย่าเก็บโครงการไว้โดยไม่อัปเดตนานกว่าหนึ่งวัน นอกจากนี้อย่าเก็บรหัสไว้โดยไม่ได้กระทำเป็นเวลาหลายวัน

5. สื่อสารว่าใครทำงานในองค์ประกอบเดียวกันและพูดคุยถึงสิ่งที่พวกเขาได้ทำการเปลี่ยนแปลงทุกวัน

6. อย่ายอมรับคุณสมบัติและไฟล์การกำหนดค่าเว้นแต่จะมีเหตุผลบางประการ เนื่องจากการตั้งค่าจะแตกต่างกันบนเซิร์ฟเวอร์และในระบบคลาวด์

7. อย่ากำหนดโฟลเดอร์เป้าหมายลงใน SVN ต้องดูแลเฉพาะซอร์สโค้ดและโฟลเดอร์ทรัพยากรในที่เก็บ SVN

8. เมื่อคุณทำรหัสหายอย่าตกใจ! คุณสามารถรับสำเนาก่อนหน้านี้กลับมาได้จากประวัติ SVN

9. อย่าชำระเงินโครงการในหลายที่ในดิสก์ของคุณ ชำระเงินในที่เดียวและใช้งานได้

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

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

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

• ความคิดเห็นที่แม่นยำสำหรับทุกการกระทำ

• อย่าทำลายงานสร้าง (สายหลัก)!

• ยอมรับทันทีที่หน่วยตรรกะเปลี่ยนแปลง

• หลีกเลี่ยงการใช้ Subversion เป็นเครื่องมือสำรอง

• การแยกสาขา / การรวมกันเล็กน้อยเท่าที่จะทำได้

.

รายละเอียดเพิ่มเติมสามารถพบได้ในSVN ปฏิบัติที่ดีที่สุด

DEV ทำงานในสาขา

1. ผูกพันกับสาขาของคุณบ่อยครั้ง
2. ไม่ต่อเนื่อง / โมดูลาร์ผูกพันกับสาขาของคุณ( ดูที่นี่ )
3. อัปเดต / ผสานจากลำตัวบ่อยครั้ง อย่านั่งบนกิ่งไม้ของคุณโดยไม่คิดใหม่

ชุมชน Trunk

1. ควรสร้าง / ทำงานเสมอ
2. หนึ่งประเด็นต่อการคอมมิต( ดูที่นี่อีกครั้ง )ส่วนใหญ่คุณหรือคนอื่น ๆ สามารถสำรองทีละรายการ
3. อย่ารวมการเปลี่ยนแปลง refactoring / whitespace กับการเปลี่ยนแปลงเชิงตรรกะ เพื่อนร่วมทีมของคุณจะมีช่วงเวลาที่ยากลำบากในการแยกสิ่งที่คุณทำจริงออกจากการกระทำ

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

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

ใช้สิ่งนี้สำหรับเทมเพลตความคิดเห็น:

[งาน / เรื่องราว xxx] [ผู้เยาว์ / รายใหญ่] [ความคิดเห็น] [ติดตามความคิดเห็น] [URL ของข้อบกพร่อง]