กลยุทธ์สำหรับการตรวจสอบโค้ดก่อนที่จะรวมไปถึงต้นแบบจากสาขาคุณลักษณะ

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

1. ฉันเช็คเอ้าท์สาขาใหม่จากหลักให้เรียกมันว่า fb_ # 1
2. ฉันส่งไปสองสามครั้งและต้องการรวมกลับเป็นหลัก
3. ก่อนที่ฉันจะรวมใครบางคนควรทำการตรวจทานโค้ด

ตอนนี้มีความเป็นไปได้ 2 แบบ:

1

1. ฉันรวมต้นแบบเข้ากับ fb_ # 1 ( ไม่ใช่ fb_ # 1 เป็นหลัก) เพื่อทำให้ทันสมัยที่สุด
2. เพื่อนร่วมทีมจะตรวจทานการเปลี่ยนแปลงระหว่างหัวหน้าหลักและหัวหน้า fb_ # 1
3. หาก fb_ # 1 ไม่เป็นไรเราจะรวม fb_ # 1 เป็นหลัก
4. ข้อดี: ไม่มีรหัสที่ล้าสมัยในการตรวจสอบ
5. ข้อด้อย: ถ้ามีคนอื่นรวมบางอย่างระหว่าง "1. " และ "2. " การเปลี่ยนแปลงของเขาจะปรากฏในการตรวจสอบแม้ว่าจะเป็นของการตรวจสอบอื่น

ครั้งที่ 2

1. เพื่อนร่วมทีมตรวจสอบการเปลี่ยนแปลงระหว่างจุดชำระเงิน (git merge-base master fb_ # 1) และ fb_ # 1 หัว
2. ข้อดี: เราเห็นสิ่งที่เปลี่ยนแปลงระหว่างการทำงานกับฟีเจอร์สาขา
3. ข้อด้อย: รหัสที่ล้าสมัยบางอย่างอาจปรากฏในการตรวจสอบ

คุณคิดว่าวิธีไหนดีกว่าและเพราะอะไร อาจมีวิธีอื่นที่เหมาะสมกว่านี้อีกหรือ

ตัวเลือกแรกของคุณมีหลายรูปแบบ:

1. ผสานหลักไปยัง fb_ # 1 (ไม่ใช่ fb_ # 1 ถึงหลัก) เพื่อทำให้ทันสมัยที่สุดเท่าที่จะทำได้
2. เพื่อนร่วมทีมตรวจสอบการเปลี่ยนแปลงระหว่างอาจารย์ณ จุดที่คุณรวมกับหัว fb_ # 1
3. หาก fb_ # 1 ไม่เป็นไรเราจะรวม fb_ # 1 เป็นหลัก
4. ตรวจสอบอย่างรวดเร็วว่าการผสานนั้นใช้ได้

เช่น.

... ma -- ... -- mm -- ... -- mf  <- master
      \            \         /
       f1 ... fn -- fm -----      <-- fb_#1

ที่อยู่:

• maเป็นบรรพบุรุษของเจ้านายและ fb_ # 1
• fnคือการเปลี่ยนแปลงครั้งล่าสุดในสาขาของคุณ
• mmคือความมุ่งมั่นที่เป็นหัวหน้า / หัวหน้าในเวลาที่คุณรวมเข้ากับสาขาของคุณ (ให้fm )

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

สิ่งนี้ถือว่าการตรวจสอบนั้นรวดเร็วเมื่อเทียบกับความถี่ปกติของการเปลี่ยนแปลงที่ส่งไปยังมาสเตอร์ดังนั้นfm -> mfมักจะเป็นกรอไปข้างหน้า

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

3

• คุณrebaseสาขาบนมาสเตอร์เพื่อทำให้เป็นปัจจุบันและแยกการเปลี่ยนแปลง

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

• คุณใช้การรีบูตแบบโต้ตอบ ( git rebase -iและgit commit --amend) เพื่อเรียงลำดับใหม่แก้ไขและล้างข้อมูลการเปลี่ยนแปลงเพื่อให้แต่ละการเปลี่ยนแปลงปิดทางตรรกะ

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

• ข้อดี:

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

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

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

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

อันที่จริงแล้วมีความเป็นไปได้ที่สาม - และส่วนใหญ่อาจเป็นจำนวนมากเนื่องจาก GIT เป็นการนำเฟรมเวิร์ก SCM มาใช้มากกว่าการใช้ระเบียบวิธี SCM rebaseนี้ไปได้ที่สามจะขึ้นอยู่กับ

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

นี่คือคำแนะนำของฉันสำหรับtopicสาขาของคุณ:

1. (ขั้นตอนเพิ่มเติม) คุณจะลดระดับหัวข้อของคุณแบบโต้ตอบtopicในจุดแยกสาขา (ดู--fixupตัวเลือกสำหรับcommitและ-iและ--autosquashตัวเลือกบนrebase) ซึ่งเปิดโอกาสให้คุณเขียนคำมั่นสัญญาของคุณในวิธีที่ง่ายต่อการตรวจสอบ topic-1ผลนี้ในสาขา

2. คุณ rebase หัวข้อสาขาของคุณที่ด้านบนของสาขาการรวมของคุณคล้ายกับการผสาน แต่ประวัติศาสตร์ "ไม่ก่อให้เกิดมลพิษ" ด้วยการผสานที่เป็นเพียงสิ่งประดิษฐ์วิศวกรรมซอฟต์แวร์ topic-2ผลนี้ในสาขา

3. ส่งให้เพื่อนร่วมทีมที่ความคิดเห็นมันกับปลายของtopic-2master

4. ถ้าtopic-2ไม่เป็นไรก็ให้รวมมันเป็นหลัก

หมายเหตุสาขาที่สาขาอ้างถึงต้นไม้ที่รับมอบทั้งหมดจะถูกเรียกโดย GIT ดังนั้นในตอนท้ายของกระบวนการเฉพาะสาขาเท่านั้นที่topic-2มีชื่อใน GIT

ข้อดี:

• ไม่มีรหัสล้าสมัยในการตรวจสอบ
• ไม่มีบทวิจารณ์ "การรวม บริษัท ต่างประเทศ" ปลอม (ปรากฏการณ์ที่คุณอธิบายไว้ในที่ 1)
• โอกาสในการเขียนซ้ำกระทำอย่างสะอาด

จุดด้อย:

• แทนที่จะสาขาหนึ่งtopic-0มีสามสิ่งประดิษฐ์สาขาtopic-0, topic-1และtopic-2ที่สร้างขึ้นในการกระทำต้นไม้ (แม้ว่าจะตลอดเวลาเพียงหนึ่งในนั้นเท่านั้นที่มีชื่อใน GIT)

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

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

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