การพัฒนาแบบ Trunk-based กับ Git Flow

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

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

ระบบควบคุมเวอร์ชันเปลี่ยนโลกอย่างไร

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

เสียเวลา พื้นที่ฮาร์ดไดรฟ์ และเงินเป็นจำนวนมาก

เมื่อเราดูประวัติ เราสามารถแยกแยะความแตกต่างของซอฟต์แวร์ควบคุมเวอร์ชันได้สามชั่วอายุคน

ลองดูที่พวกเขา:

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

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

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

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

รูปแบบการพัฒนา

ปัจจุบันระบบควบคุมเวอร์ชันที่ได้รับความนิยมมากที่สุดคือ Git โดยมีส่วนแบ่งตลาดประมาณ 70 เปอร์เซ็นต์ในปี 2559

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

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

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

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

ลองพิจารณา ทั้งสองอย่างอย่าง ละเอียดถี่ถ้วนและเรียนรู้ว่าเราควรใช้อย่างไรและเมื่อใด

Git Flow

ในโมเดลการพัฒนา Git flow คุณมีสาขาการพัฒนาหลักหนึ่งสาขาที่มีสิทธิ์เข้าถึงอย่างเข้มงวด มักเรียกว่าสาขา develop

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

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

ด้านล่างนี้ คุณสามารถดูไดอะแกรมโฟลว์ Git ซึ่งแสดงเวิร์กโฟลว์ทั่วไป:

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

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

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

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

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

Git Flow ข้อดีและข้อเสีย

อย่างที่คุณเห็น การทำ Pull Request อาจไม่ใช่ทางเลือกที่ดีที่สุดเสมอไป ควรใช้ตามความเหมาะสมเท่านั้น

Git Flow ทำงานได้ดีที่สุดเมื่อใด

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

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

  

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

Git Flow จะสร้างปัญหาได้เมื่อใด

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

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

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

เวิร์กโฟลว์การพัฒนาตามลำต้น

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

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

มาดูเวิร์กโฟลว์การพัฒนาบนลำต้นกัน

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

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

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

ข้อดีและข้อเสียของการพัฒนาบนลำต้น

มาดูค่าใช้จ่ายทั้งสองด้านให้ละเอียดยิ่งขึ้น—สถานการณ์ที่ดีที่สุดและแย่ที่สุด

การพัฒนาแบบ Trunk-based ทำงานได้ดีที่สุดเมื่อใด

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

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

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

เมื่อใดที่การพัฒนาบนฐานรากสามารถก่อให้เกิดปัญหาได้

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

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

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

ใช้เครื่องมือที่เหมาะสมสำหรับงานที่เหมาะสม

อย่างที่ฉันพูดไปก่อนหน้านี้ Git เป็นเพียงเครื่องมือ ต้องใช้อย่างเหมาะสมเช่นเดียวกับเครื่องมืออื่นๆ

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

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

อย่างไรก็ตาม หากคุณทำงานกับโปรแกรมเมอร์รุ่นเยาว์หรือคนที่คุณไม่ไว้วางใจอย่างเต็มที่ Git flow เป็นทางเลือกที่ดีกว่ามาก

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