Git เวิร์กโฟลว์สำหรับมือโปร: A Good Git Guide

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

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

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

การทำงานร่วมกัน

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

สาขาบูรณาการ

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

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

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

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

สาขาหัวข้อ

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

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

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

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

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

ส้อม

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

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

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

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

ตรวจสอบให้แน่ใจว่าคุณใช้เครื่องมือที่อำนวยความสะดวกในการฟอร์กและดึงคำขอเพื่อใช้ประโยชน์จากรูปแบบนี้ เครื่องมือเหล่านี้ไม่ได้จำกัดเฉพาะ Github: ตัวเลือกยอดนิยมอื่นๆ ได้แก่ Bitbucket และ GitlLab แต่ยังมีบริการโฮสต์เวิร์กโฟลว์ Git อีกสองสามบริการที่จะมีคุณสมบัติเหล่านี้ (หรือคล้ายกัน) เลือกบริการที่เหมาะกับคุณที่สุด

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

โคลน

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

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

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

อย่า สร้างสำเนาที่โฮสต์ของพื้นที่เก็บข้อมูลของลูกค้าโดยไม่ได้รับอนุญาต คุณอาจละเมิดข้อตกลงตามสัญญา ตรวจสอบล่วงหน้าว่าการปฏิบัตินี้จะเป็นประโยชน์ต่อโครงการกับลูกค้า

การจัดการการเปิดตัว

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

สาขาสิ่งแวดล้อม

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

ทีมที่ทำงานกับกระบวนการเหล่านี้มักมีการตั้งค่าสภาพแวดล้อมแอปพลิเคชันสำหรับแต่ละขั้นตอนในไปป์ไลน์ เช่น "QA", "Staging" และ "Production" ในกรณีเหล่านี้ โครงสร้างพื้นฐานอยู่ในสถานที่เพื่อสนับสนุนบุคลากรที่รับผิดชอบในการลงนามในคุณลักษณะหรือการสนับสนุนในส่วนของตนว่ามีความพร้อมในการผลิต (เช่น การทดสอบเชิงสำรวจ, QA, การทดสอบการยอมรับ) ก่อนที่จะย้ายไปยังบุคคลต่อไป เวที. ซึ่งทำให้พวกเขามีที่ของตนเองในการปรับใช้ ทดสอบ และประเมินตามข้อกำหนด โดยมีเวิร์กโฟลว์ Git เพื่อบันทึกการเดินทางผ่านอุโมงค์การลงชื่อออก

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

อย่า ใช้รูปแบบนี้โดยไม่พิจารณาถึงประโยชน์ระยะยาวของรูปแบบอื่นก่อน

สาขาที่วางจำหน่าย

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

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

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

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

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

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

การอนุญาตให้ปล่อยสาขาเดียวที่มีอยู่ในช่วงเวลาที่กำหนด จะช่วยให้แน่ใจว่าคุณจะหลีกเลี่ยงค่าใช้จ่ายในการรักษาสายการวางจำหน่ายหลายสาขาให้ซิงค์กัน

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

เผยแพร่เวลา

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

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

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

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

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

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

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

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

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

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

รุ่นสาขา

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

พื้นที่เก็บข้อมูลที่ใช้สาขาเวอร์ชันจะมีหนึ่งสาขาต่อเวอร์ชันรองของแอปพลิเคชัน มีการอธิบายเวอร์ชันหลัก เวอร์ชันรอง และเวอร์ชันแพตช์ในเอกสารการกำหนดเวอร์ชันเชิงความหมาย เวอร์ชันต่างๆ มักใช้หลักการตั้งชื่อเพื่อรวมคำว่า "เสถียร" และวางหมายเลขแพตช์จากเวอร์ชันแอปพลิเคชัน: เช่น 2-3-stable เพื่อทำให้จุดประสงค์และความน่าเชื่อถือชัดเจนสำหรับผู้ใช้ปลายทาง

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

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

อย่า ใช้สาขาของเวอร์ชันเว้นแต่คุณจะสนับสนุนที่เก็บของคุณมากกว่าหนึ่งเวอร์ชัน

สรุป

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

รูปแบบในคู่มือนี้สามารถช่วยคุณในการมองการณ์ไกลในการปรับระบบควบคุมเวอร์ชันแบบกระจายของคุณให้เหมาะกับคุณ หากคุณต้องการอ่านเกี่ยวกับเวิร์กโฟลว์ Git อย่าลืมตรวจสอบ Gitflow, Github Flow และที่สำคัญที่สุดคือเอกสารประกอบ git-scm ที่น่าทึ่ง!