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

การแนะนำ

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

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

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

• ทำงานในสาขาที่เขาต้องการ
• รวมเข้ากับสาขาอื่นที่เขาต้องการ
• ลบบางสาขา
• สร้างสิ่งใหม่
• และอื่นๆ—สมาชิกในทีมแต่ละคนอยู่ในกระแสที่ไม่สามารถควบคุมได้

ดังนั้นด้านล่างนี้จึงเป็นสามกลยุทธ์ ไป!

กลยุทธ์ GitHub Flow

กลยุทธ์การแตกแขนงไม่ว่าจะแปลกแค่ไหนก็เป็นที่ต้องการใน GitHub :) สิ่งที่แนบมาด้วยคือชุดกฎที่ต้องปฏิบัติตาม:

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

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

กลยุทธ์ GitFlow

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

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

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

1. สาขาฟีเจอร์ - สำหรับการพัฒนาฟังก์ชันใหม่
2. สาขาการเผยแพร่ - เพื่อเตรียมพร้อมสำหรับการเปิดตัวโครงการเวอร์ชันใหม่
3. สาขาโปรแกรมแก้ไขด่วนเป็นวิธีแก้ไขข้อบกพร่องอย่างรวดเร็วซึ่งพบโดยผู้ใช้จริงบนเซิร์ฟเวอร์จริง

จุดเด่นสาขา

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

ปล่อยสาขา

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

สาขาโปรแกรมแก้ไขด่วน

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

กลยุทธ์เวิร์กโฟลว์ Forking

ในฐานะที่เป็นส่วนหนึ่งของกลยุทธ์ Forking Workflow การพัฒนาจะดำเนินการในลักษณะที่มีที่เก็บสองแห่ง:

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

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

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

Forking Flow ถูกใช้บน GitHub เมื่อมีไลบรารี่ที่คุณต้องการใช้ มีตำหนิทำให้ใช้งานไม่เต็มที่ สมมติว่าคุณเจาะลึกปัญหามามากพอแล้วและรู้วิธีแก้ปัญหา เมื่อใช้กลยุทธ์ Forking Workflow คุณสามารถแก้ไขปัญหานี้ได้โดยไม่ต้องให้สิทธิ์ในการทำงานในพื้นที่เก็บข้อมูลไลบรารีดั้งเดิม ในการเริ่มต้นคุณต้องเลือกพื้นที่เก็บข้อมูลเช่นSpring Framework coreค้นหาปุ่ม Fork ที่มุมขวาบนแล้วคลิก: ขั้นตอนนี้จะใช้เวลาสักครู่หลังจากนั้นสำเนาของพื้นที่เก็บข้อมูลดั้งเดิมนี้จะปรากฏในของคุณ บัญชีส่วนตัวซึ่งจะระบุว่าเป็นทางแยก จากนั้นคุณสามารถทำงานกับ Repository นี้ตามปกติ เพิ่มการเปลี่ยนแปลงใน Master Branch และเมื่อทุกอย่างพร้อมแล้ว ให้สร้าง Pull-Request ไปยัง Repository ดั้งเดิม เมื่อต้องการทำเช่นนี้ ให้คลิก ปุ่ม คำขอดึงใหม่ :

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

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

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

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

ลิงค์ที่เป็นประโยชน์

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