การทำงานเป็นทีมโดยไม่สับสน: ทำความเข้าใจกลยุทธ์การแตกสาขาใน Git

การแนะนำ

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

กลยุทธ์การแตกสาขาจำเป็นหรือไม่?

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

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

นั่นเป็นเหตุผลที่เรามีสามกลยุทธ์ที่ต้องพิจารณาด้านล่าง ไปกันเถอะ!

การไหลของ GitHub

กลยุทธ์การแยกสาขานี้เป็นที่ต้องการใน GitHub :) มันมาพร้อมกับกฎชุดหนึ่ง :

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

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

GitFlow

กลยุทธ์ก่อนหน้า (GitHub Flow) นั้นไม่ซับซ้อนมากนักที่แกนหลัก มีสาขาสองประเภท: สาขาหลักและสาขาคุณลักษณะ แต่ GitFlow จริงจังกว่า อย่างน้อยภาพด้านบนควรทำให้ชัดเจน :) กลยุทธ์นี้ทำงานอย่างไร โดยทั่วไป GitFlow ประกอบด้วยสาขาถาวรสองสาขาและสาขาชั่วคราวหลายประเภท ในบริบทของ GitHub Flow แบรนช์หลักจะคงอยู่และสาขาอื่นๆ จะอยู่ชั่วคราว สาขาถาวร

• มาสเตอร์: ห้ามใครแตะต้องหรือผลักอะไรไปที่สาขานี้ ในกลยุทธ์นี้ ต้นแบบแสดงถึงเวอร์ชันเสถียรล่าสุด ซึ่งใช้ในการผลิต (นั่นคือ บนเซิร์ฟเวอร์จริง)
• การพัฒนา: สาขาการพัฒนา. อาจไม่เสถียร

การพัฒนาเกิดขึ้นโดยใช้สามสาขาชั่วคราวเสริม :

1. สาขาคุณลักษณะ — สำหรับการพัฒนาฟังก์ชันใหม่
2. Release Branch — เพื่อเตรียมพร้อมสำหรับการเปิดตัวเวอร์ชันใหม่ของโครงการ
3. ฮอตฟิกซ์สาขา — สำหรับแก้ไขบั๊กที่ผู้ใช้จริงพบบนเซิร์ฟเวอร์จริงได้อย่างรวดเร็ว

สาขาคุณลักษณะ

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

ปล่อยสาขา

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

สาขา Hotfix

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

การฟอร์กเวิร์กโฟลว์

ในเวิร์กโฟลว์การฟอร์ก การพัฒนาเกี่ยวข้องกับที่เก็บสองแห่ง:

1. ที่เก็บดั้งเดิมซึ่งการเปลี่ยนแปลงทั้งหมดจะถูกรวมเข้าด้วยกัน
2. ที่เก็บส้อม นี่คือสำเนาของพื้นที่เก็บข้อมูลต้นฉบับ ซึ่งเป็นของนักพัฒนารายอื่นที่ต้องการเปลี่ยนแปลงต้นฉบับ

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

ตัวอย่างของเวิร์กโฟลว์การฟอร์ก

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

กลยุทธ์ใดที่จะเลือก

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

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

นั่นคือทั้งหมดที่ฉันอยากจะพูดเกี่ยวกับกลยุทธ์การแตกสาขาใน Git ขอบคุณสำหรับความสนใจของคุณ :) ติดตามฉันบน GitHubที่ฉันมักจะโพสต์ผลงานสร้างสรรค์ของฉันที่เกี่ยวข้องกับเทคโนโลยีและเครื่องมือต่างๆ ที่ฉันใช้ในการทำงาน