คุณควรปรับปรุงคุณภาพของรหัสขณะทำงานในฟีเจอร์ Branch

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

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

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

รู้สึกเหมือนมีจำนวนขาลงที่จะแก้ไข:

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

ด้านพลิกถ้าฉันไม่ทำในขณะที่ฉันอยู่ในไฟล์แล้วชัดเจนฉันจะลืมที่จะทำในเวลาสองสามวันเมื่อฉันรวมสาขาใน

ฉันถูกเตือนว่านี่เป็นพื้นฐานของความคิดเห็น (ฉันคิดว่าเป็นความจริงที่ชื่อรวมอยู่ด้วยshould) แต่ฉันรู้สึกเหมือนมีคำตอบ (แน่นอนว่าผู้คนใช้วิธีทั้งสองนี้ดังนั้นพวกเขาจึงต้องมีคำตอบ) นอกจากนี้คำถามเกี่ยวกับdevelopment methodologiesอยู่ในหัวข้อและฉันคิดว่าพวกเขาต้องการระดับความคิดเห็น

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

เช่น. ฉันกำลังทำงานกับคุณสมบัติ 'กระต่ายพิมพ์' และฉันค้นหารหัสเครื่องพิมพ์

Public class Printer(string type)
{
    If(type=="bunnies")
    {
        //print a bunny
    }
.....
}

ฉันเปลี่ยนเป็น:

Public class Printer(string type)
{
     PrintFunctionDictionary[type].Print();
}

ทำไม:

• ฉันกำลังทำงานกับรหัส
• ฉันต้องเปลี่ยนมันเพื่อเพิ่มฟังก์ชั่น
• ฟังก์ชั่นที่เพิ่มเข้ามาจะแนะนำวิธีการแก้ไขปัญหาที่ถูกแก้ไข

ฉันไม่ได้สุ่มกดส่วนอื่น ๆ ของรหัสฐานและ 'ทำให้ดีขึ้น' เช่นนี้จะ:

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

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

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

วัตถุประสงค์ของbranchประเภทคือเพื่อให้ความตั้งใจในการจัดการพวกเขา หากคุณกำลังต่อไปนี้รูปแบบของการแยก GitFlow แล้วคุณน่าจะมีประเภทชอบfeature, hotfix, releaseฯลฯ .. ในกรณีของสาขาคุณลักษณะของมันความตั้งใจคือการแค็ปซูลผสานลงในสาขาอื่น (เช่นdevelop) ที่แสดงให้เห็นว่านักพัฒนาที่รับผิดชอบในการ การผสานคุณสมบัตินี้คืออะไร หากรหัสที่คุณกำลังล้างไม่ได้เป็นส่วนหนึ่งของคุณสมบัตินั้นอย่าเปลี่ยนรหัส

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

นี่คือคำอธิบายที่ดีเกี่ยวกับกลยุทธ์ที่แตกต่าง: https://www.atlassian.com/git/tutorials/comparing-workflows/

หากฉันกำลังทำงานในสาขาฟีเจอร์และฉันพบรหัสที่น่าเกลียดฉันควรแก้ไขไหม

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

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

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

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