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

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

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

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

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

แต่ละเฟสของ ____ จะสร้างเอกสารบางประเภทเพื่อส่งต่อไปยังเฟสถัดไป

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

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

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

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

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

สาขาหัวข้อ

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

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

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

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

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

ส้อม

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

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

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

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

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

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

โคลน

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

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

วิธีคำนวณความยืดหยุ่นของราคาอุปสงค์

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

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

การจัดการรุ่น

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

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

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

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

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

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

สาขาเผยแพร่

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

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

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

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

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

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

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

แบบอักษรที่ดีที่สุดสำหรับการออกแบบการพิมพ์

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

การเผยแพร่ที่ประทับเวลา

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

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

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

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

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

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

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

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

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

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

สาขาเวอร์ชัน

คู่มือการศึกษาสถาปนิกโซลูชันที่ผ่านการรับรอง aws: การสอบที่เกี่ยวข้อง saa-c01

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

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

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

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

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

สรุป

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

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

ที่เกี่ยวข้อง: อธิบายขั้นตอนของ Git ที่ปรับปรุงแล้ว