การแก้ไขบั๊กจะอยู่ที่ไหนในโมเดล git-flow

ในปกติเรียกว่าโปรแกรมแก้ไขด่วนรุ่นGit ไหลไปในhotfix-*สาขาเฉพาะของพวกเขาและการแก้ไขการรวมขนาดเล็กทันทีก่อนที่จะปล่อยไปในrelease-*สาขา การแก้ไขข้อบกพร่องทั่วไปจากรุ่นก่อนหน้าดูเหมือนจะไม่มีสถานที่

พวกเขาควรจะปรากฏที่ไหน พวกเขาควรจะอยู่ในbug-*สาขาของตัวเองแตกแขนงออกdevelop(เหมือนfeatureกิ่ง)?

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

ความคิดเห็นของ Bart van Ingen Schenauนำมาซึ่งจุดที่ดี

Gitflow มีประเภทสาขาห้าประเภท: master,, developสาขาโปรแกรมแก้ไขด่วน (นำหน้าด้วยhotfix-), สาขาที่วางจำหน่าย (นำหน้าด้วยrelease-, และสาขาคุณสมบัติฟีเจอร์masterและdevelopสาขาเป็นสาขาที่ใช้งานมายาวนานและคุณไม่ผูกพันโดยตรงrelease-สาขาเหล่านั้นทำการวาดเส้น สำหรับรุ่นที่เฉพาะเจาะจงแล้วรองรับการแก้ไขข้อผิดพลาดระหว่างการระบุรุ่นถัดไปและรีลีสhotfix-สาขาต่าง ๆ มีไว้สำหรับการเผยแพร่ที่สำคัญนอกวงจรออกไปสู่การผลิตfeature-สาขาสำหรับการพัฒนาคุณลักษณะส่วนบุคคลสำหรับการเปิดตัวในอนาคต

มาจากสภาพแวดล้อมที่ PRs มีการใช้และนอกเหนือจากการเป็นนักพัฒนาแต่ละ committing สาขาคุณลักษณะอะไรควรจะมุ่งมั่นโดยตรงลงmaster, developหรือสาขาที่วางจำหน่าย สิ่งนี้ทำให้มั่นใจได้ว่าการเปลี่ยนแปลงทุกครั้งจะได้รับการตรวจสอบรหัสพร้อมกับการตรวจสอบความครอบคลุมการทดสอบที่เหมาะสมและผ่านการทดสอบในสภาพแวดล้อม CI ก่อนที่จะมีการเปลี่ยนแปลงใด ๆ ฉันจะไม่เห็นด้วย ไม่มีปัญหาใด ๆ กับการยอมรับการแก้ไขข้อบกพร่องก่อนวางจำหน่ายหรือการเปลี่ยนแปลงโดยตรงในสาขาที่วางจำหน่ายแล้วดึงพวกเขาไปสู่การพัฒนาแล้วสาขาคุณลักษณะ

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

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

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

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

นอกจากนี้ยังมีความคิดเห็นจากผู้เขียน git-flow ว่าสิ่งที่คุณถามอย่างแน่นอน: ไม่มีการแก้ไขข้อบกพร่องสาขา # 24