อธิบายการไหลของ Git ที่ปรับปรุงแล้ว

การสร้างความเสียหายโดยไม่ได้ตั้งใจด้วย Git นั้นง่ายเกินไป อย่างไรก็ตาม วิธีที่ดีที่สุดในการใช้ Git มักจะเป็นที่ถกเถียงกันอยู่เสมอ

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

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

ข่าวดี! รูปแบบการไหลของ Git แบบคลาสสิก โฟลว์ Git ที่ได้รับการ ปรับปรุง ช่วยลดความยุ่งยากในการดำเนินกลยุทธ์ทั่วไปของเวิร์กโฟลว์ Git ในขณะที่ยังคงข้อดีหลักไว้

ความงดงามและความทุกข์ยากของแบบจำลอง Git Flow แบบคลาสสิก

ฉันเป็นผู้สนับสนุนที่ดีของ Git flow นับตั้งแต่ฉันค้นพบว่ามันยอดเยี่ยมเพียงใดเมื่อพัฒนาผลิตภัณฑ์ที่พัฒนาโดย เพิ่มมูลค่าอย่างมีนัยสำคัญ (กล่าวอีกนัยหนึ่ง releases )

การเพิ่มมูลค่าที่มีนัยสำคัญต้องใช้เวลาเป็นจำนวนมากในการดำเนินการ เช่น การวิ่งสองสัปดาห์บวกที่มักใช้ในการพัฒนาบน Scrum หากทีมพัฒนาได้ปรับใช้กับการใช้งานจริงแล้ว อาจมีปัญหาหากขอบเขตของรุ่นถัดไปสะสมในที่เดียวกันกับที่รหัสการใช้งานจริงอยู่—เช่น ในสาขาหลักของ repo Git ที่พวกเขาใช้

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

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

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

กระบวนการโฟลว์ Git จัดการกับสถานการณ์พื้นฐานเหล่านี้โดยแยกสาขา "หลัก" (สาขาที่ใช้งานจริงหรือสาขา "เวอร์ชันปัจจุบัน") และ "พัฒนา" (สาขาการพัฒนาหรือ "รุ่นถัดไป") และให้กฎทั้งหมดเกี่ยวกับการใช้สาขาคุณลักษณะ/รุ่น/โปรแกรมแก้ไขด่วน . มันแก้ปัญหาปวดหัวได้อย่างมีประสิทธิภาพจากเวิร์กโฟลว์การพัฒนาผลิตภัณฑ์ตามรุ่น

แต่ถึงแม้จะเป็นโปรเจ็กต์ที่เหมาะสมกับโมเดล Git flow แบบคลาสสิก ฉันก็ยังประสบปัญหาทั่วไปที่อาจนำมาซึ่ง:

• การไหลของ Git นั้นซับซ้อน โดยมีสาขาที่มีอายุยืนยาวสองสาขา สาขาชั่วคราวสามประเภท และกฎเกณฑ์ที่เข้มงวดเกี่ยวกับวิธีที่สาขาจัดการซึ่งกันและกัน ความซับซ้อนดังกล่าวทำให้เกิดข้อผิดพลาดมากขึ้นและเพิ่มความพยายามที่จำเป็นในการแก้ไข
• สาขารีลีสและโปรแกรมแก้ไขด่วนต้องการ "การผสานสองครั้ง"—เมื่อกลายเป็นหลัก จากนั้นจึงค่อยพัฒนา บางครั้งคุณอาจลืมทำทั้งสองอย่าง คุณสามารถทำให้การแตกสาขาของ Git flow ง่ายขึ้นด้วยสคริปต์หรือปลั๊กอินไคลเอ็นต์ VCS GUI แต่คุณต้องตั้งค่าก่อนสำหรับเครื่องทุกเครื่องของนักพัฒนาทุกคนที่เกี่ยวข้องในโครงการที่กำหนด
• ในเวิร์กโฟลว์ CI/CD คุณมักจะลงเอยด้วยบิลด์สุดท้ายสองบิลด์สำหรับรีลีส—อันหนึ่งมาจากคอมมิตล่าสุดของรีลีสแบรนช์เอง และอีกอันจากการคอมมิตการรวมไปยังเมน พูดอย่างเคร่งครัด คุณควรใช้อันจากตัวหลัก แต่ทั้งสองมักจะเหมือนกัน ทำให้เกิดความสับสนได้

ป้อน "ปรับปรุง Git Flow"

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

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

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

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

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

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

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

ความคล้ายคลึงกันกับ Classic Git Flow: การแยกการพัฒนา

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

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

คุณลักษณะทั้งหมดที่สะสมในสาขาการพัฒนาจนถึงจุดตัดบางส่วนจะเป็นตัวกำหนดการเปิดตัวใหม่

สควอชผสาน

ฉันขอแนะนำอย่างยิ่งให้ใช้การรวมสควอชสำหรับสาขาคุณลักษณะเพื่อรักษาประวัติที่ดีและเป็นเส้นตรงเป็นส่วนใหญ่ หากไม่มีมัน คอมมิชชันกราฟ (จากเครื่องมือ GUI หรือ git log --graph ) เริ่มดูเลอะเทอะเมื่อทีมเล่นกลแม้สาขาคุณลักษณะเพียงไม่กี่อย่าง:

แต่ถึงแม้ว่าคุณจะพอใจกับภาพในสถานการณ์นี้ แต่ก็มีเหตุผลอื่นที่จะสควอช โดยไม่บีบอัด ให้คอมมิตมุมมองประวัติ—ในหมู่พวกเขาทั้ง git log ธรรมดา (ไม่มี --graph ) และ GitHub— บอกเล่าเรื่องราวที่ค่อนข้างไม่ต่อเนื่องกันแม้ในสถานการณ์การผสานที่ง่ายที่สุด:

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

ความแตกต่างจาก Classic Git Flow: รุ่นและโปรแกรมแก้ไขด่วน

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

เผยแพร่ใน Enhanced Git Flow

ทุกขั้นตอนของการเปิดตัว Git flow ที่ปรับปรุงแล้วนั้นแตกต่างจากกระบวนการ Git flow แบบคลาสสิก:

1. การเผยแพร่จะขึ้นอยู่กับหลักมากกว่าการพัฒนา แท็กส่วนปลายปัจจุบันของสาขาหลัก ด้วยสิ่งที่มีความหมาย ฉันใช้แท็กตามวันที่ปัจจุบันในรูปแบบ ISO 8601 ที่นำหน้าด้วย "v"—เช่น v2020-09-09
   • หากมีการเผยแพร่หลายรายการในหนึ่งวัน—เช่น โปรแกรมแก้ไขด่วน— รูปแบบอาจมีหมายเลขหรือตัวอักษรที่ต่อเนื่องกันติดอยู่ตามความจำเป็น
   • โปรดทราบว่าโดยทั่วไปแท็กไม่สอดคล้องกับวันที่เผยแพร่ พวกเขากำลังเพียงเพื่อบังคับให้ Git อ้างอิงถึงวิธีที่สาขาหลักพิจารณาเวลาที่กระบวนการเผยแพร่ครั้งต่อไปเริ่มต้นขึ้น
2. ดันแท็ก โดยใช้ git push origin <the new tag name>
3. หลังจากนั้น ก็ต้องแปลกใจเล็กน้อย: ลบสาขาหลักในพื้นที่ของคุณ ไม่ต้องกังวลเพราะเราจะกู้คืนในไม่ช้า
   • ความมุ่งมั่นทั้งหมดที่มีต่อ main ยังคงปลอดภัย—เราปกป้องพวกเขาจากการรวบรวมขยะโดยติดแท็ก main ในขั้นตอนก่อนหน้า ความมุ่งมั่นเหล่านี้ทั้งหมด—แม้แต่โปรแกรมแก้ไขด่วน ตามที่เราจะกล่าวถึงในไม่ช้า—ก็เป็นส่วนหนึ่งของการพัฒนาเช่นกัน
   • เพียงตรวจสอบให้แน่ใจว่ามีเพียงคนเดียวในทีมที่ทำสิ่งนี้สำหรับรุ่นใดก็ตาม นั่นคือบทบาทที่เรียกว่า "ผู้จัดการรุ่น" ผู้จัดการฝ่ายปล่อยมักจะเป็นสมาชิกในทีมที่มีประสบการณ์มากที่สุดและ/หรืออาวุโสที่สุด แต่ทีมก็ควรที่จะหลีกเลี่ยงสมาชิกในทีมคนใดคนหนึ่งที่รับบทบาทนี้อย่างถาวร การกระจายความรู้ระหว่างทีมนั้นสมเหตุสมผลกว่าเพื่อเพิ่มปัจจัยบัสที่น่าอับอาย
4. สร้างสาขาหลักในพื้นที่ใหม่ที่ส่วนปลายของสาขาการพัฒนาของคุณ
5. ผลักดันโครงสร้างใหม่นี้โดยใช้ git push --force เนื่องจาก repo ระยะไกลจะไม่ยอมรับ "การเปลี่ยนแปลงที่รุนแรง" ดังกล่าวอย่างง่ายดาย อีกครั้ง การดำเนินการนี้ไม่ปลอดภัยเท่าที่ควรในบริบทนี้ เนื่องจาก:
   • เราแค่ย้ายตัวชี้สาขาหลักจากคอมมิตหนึ่งไปยังอีกคอมมิตหนึ่ง
   • สมาชิกในทีมเพียงคนเดียวที่ทำการเปลี่ยนแปลงนี้ในแต่ละครั้ง
   • งานพัฒนาทุกวันเกิดขึ้นที่สาขาพัฒนา ดังนั้นคุณจะไม่รบกวนงานของใครเลยด้วยการย้ายงานหลักด้วยวิธีนี้
6. คุณมีรุ่นใหม่ของคุณ! ปรับใช้กับสภาพแวดล้อมการแสดงละคร และทดสอบ (เราจะพูดถึงรูปแบบ CI/CD ที่สะดวกด้านล่าง) การแก้ไขใดๆ ไปที่สาขาหลักโดยตรง และมันจะเริ่มแตกต่างไปจากสาขาที่พัฒนาด้วยเหตุนั้น
   • ในเวลาเดียวกัน คุณสามารถเริ่มทำงานกับรีลีสใหม่ในสาขาการพัฒนา ซึ่งเป็นข้อได้เปรียบเดียวกันกับที่เห็นในโฟลว์ Git แบบคลาสสิก
   • ในกรณีที่โชคร้ายที่จำเป็นต้องมีโปรแกรมแก้ไขด่วนสำหรับสิ่งที่อยู่ในระหว่างการใช้งานจริง (ไม่ใช่รุ่นที่กำลังจะมีขึ้นในขั้น) ณ จุดนี้ มีรายละเอียดเพิ่มเติมเกี่ยวกับสถานการณ์สมมตินี้ใน "การจัดการกับโปรแกรมแก้ไขด่วนระหว่างรุ่นที่ใช้งาน…” ด้านล่าง
7. เมื่อพิจารณาว่ารุ่นใหม่ของคุณมีความเสถียรเพียงพอ ให้ ปรับใช้เวอร์ชันสุดท้ายกับสภาพแวดล้อมการใช้งาน จริง และทำการรวมสควอชหลักเดียวเพื่อพัฒนา เพื่อรับการแก้ไขทั้งหมด

โปรแกรมแก้ไขด่วนใน Enhanced Git Flow

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

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

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

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

1. สร้างสาขา—เราจะเรียกมันว่า "รุ่นใหม่ล่าสุด" แต่ทีมของคุณสามารถใช้รูปแบบการตั้งชื่อใดๆ ได้ที่นี่—พร้อมคอมมิตเดียวกันกับส่วนปลายของ main ปัจจุบัน ดันออกใหม่.
2. ลบและสร้างสาขาหลักในพื้นที่ใหม่ที่คอมมิตของแท็กที่คุณสร้างไว้ก่อนหน้านี้สำหรับรุ่นที่ใช้งานอยู่ในปัจจุบัน ดันหลัก.
3. แนะนำการแก้ไขที่จำเป็นสำหรับ main ปรับใช้กับสภาวะแวดล้อม staging และทดสอบ เมื่อใดก็ตามที่พร้อม ปรับใช้กับการผลิต
4. เผยแพร่การเปลี่ยนแปลงจากตัวหลักปัจจุบันไปเป็นรุ่นใหม่ไม่ว่าจะผ่านการเลือกเชอร์รี่หรือแพตช์
5. หลังจากนั้น ทำซ้ำขั้นตอนการเปิดตัว: แท็กส่วนปลายของ main ปัจจุบันและกดแท็ก ลบและสร้าง local main ใหม่ที่ส่วนปลายของ new-release branch และบังคับให้กด main
   1. คุณอาจจะไม่ต้องการแท็กก่อนหน้า ดังนั้นคุณสามารถลบออกได้
   2. ตอนนี้สาขาที่ออกใหม่มีความซ้ำซ้อน คุณจึงสามารถลบออกได้เช่นกัน
6. ตอนนี้คุณควรจะไปตามปกติกับรุ่นใหม่ ปิดท้ายด้วยการเผยแพร่โปรแกรมแก้ไขด่วนฉุกเฉินจาก main เพื่อพัฒนาผ่านการเลือกเชอร์รี่หรือโปรแกรมแก้ไข

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

การตั้งค่า CI/CD ที่ด้านบนของ Enhanced Git Flow

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

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

ฉันพบว่ารูปแบบ CI/CD บางรูปแบบมีประโยชน์อย่างยิ่งเมื่อรวมกับโฟลว์ Git ที่ปรับปรุงแล้ว:

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

รูปแบบดังกล่าวค่อนข้างเรียบง่าย แต่มีกลไกที่ทรงพลังเพื่อรองรับการดำเนินการพัฒนาแบบวันต่อวัน

โมเดล Git Flow ที่ปรับปรุงแล้ว: การปรับปรุงและข้อจำกัดที่เป็นไปได้

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

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

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

ขอขอบคุณเป็นพิเศษกับเพื่อนร่วมงานของ Toptal Antoine Pham สำหรับบทบาทสำคัญของเขาในการพัฒนาแนวคิดเบื้องหลังการไหลของ Git ที่ปรับปรุงแล้ว

อ่านเพิ่มเติมในบล็อก Toptal Engineering:

• การพัฒนาแบบ Trunk-based กับ Git Flow
• Git เวิร์กโฟลว์สำหรับมือโปร: A Good Git Guide

ในฐานะ Microsoft Gold Partner Toptal เป็นเครือข่ายผู้เชี่ยวชาญของ Microsoft ที่ยอดเยี่ยม สร้างทีมที่มีประสิทธิภาพสูงพร้อมผู้เชี่ยวชาญที่คุณต้องการ - ทุกที่และทุกเวลาที่คุณต้องการ!