เวิร์กโฟลว์ GIT สำหรับการพัฒนาเว็บ

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

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

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

ดังนั้นทำไมเราไม่ใช้ git-flow ที่ GitHub? ปัญหาหลักคือเราปรับใช้ตลอดเวลา กระบวนการ git-flow นั้นถูกออกแบบมาเพื่อ“ ปล่อย” เราไม่มี“ รีลีส” เพราะเราปรับใช้กับการผลิตทุกวัน - บ่อยครั้งต่อวัน

FWIW ฉันได้ดูที่เวิร์กโฟลว์รอบนี้บนเว็บไซต์ของ Atlassian: https://www.atlassian.com/git/workflows#!workflow-feature-branch

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

เป็นคำถามเกี่ยวกับ SE ที่ขอให้เปรียบเทียบ git-flow กับ github-flow /programming/18188492/what-are-the-pros-and-cons-of-git-flow-vs-github -ไหล

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

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

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

• ส่วนกลาง ( แหล่งที่มา ): คล้ายกับเวิร์กโฟลว์ SVN แต่ตอนนี้อยู่ในสภาพแวดล้อมแบบกระจาย นักพัฒนาซอฟต์แวร์ทุกคนทำงานกับสำเนาส่วนบุคคลmasterและผลักดันการเปลี่ยนแปลงไปยังorigin/masterโดยตรงหรือผ่านคำขอการดึง

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

• Gitflow ( แหล่งที่มา ): สองสาขาหลักติดตามประวัติโครงการและdevelop masterอีก 3 สาขาที่เรียกว่าhotfix, releaseและfeatureถือเปลี่ยนแปลงที่เกิดขึ้นโดยตรงกับmasterการแก้ไขข้อบกพร่องที่สำคัญการผลิตจำนวนการเปลี่ยนแปลงรุ่นและรายละเอียดอื่น ๆ ก่อนที่จะมีการปล่อยหรือทำงานเกี่ยวกับคุณลักษณะเฉพาะเช่นเดียวกับสาขาคุณสมบัติตามลำดับ

• GitHub ไหล ( แหล่งที่มา ): นักพัฒนาสร้างสาขาออกจากfeature masterการเปลี่ยนแปลงถูกผลักผ่านคำขอดึง ยอมรับการเปลี่ยนแปลงเพื่อmaster นำไปใช้งานได้ทันทีโดย GitHub bot Hubot

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

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

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

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