ข้อดีข้อเสียของ git-flow vs github-flow คืออะไร? [ปิด]

เราเพิ่งเริ่มใช้ GitLab

ปัจจุบันใช้เวิร์กโฟลว์แบบ "รวมศูนย์"

เรากำลังพิจารณาที่จะย้ายไปที่ github-flow แต่ฉันต้องการให้แน่ใจ

ข้อดีข้อเสียของgit-flow vs github-flowคืออะไร?

ตามที่กล่าวไว้ใน GitMinutes ตอนที่ 17 โดยNicholas Zakasในบทความของเขาเรื่อง " GitHub workflows inside of a company ":

Git-flowคือกระบวนการสำหรับจัดการการเปลี่ยนแปลงใน Git ที่สร้างโดย Vincent Driessen และมาพร้อมกับส่วนขยาย Gitสำหรับจัดการโฟลว์นั้น
ความคิดทั่วไปที่อยู่เบื้องหลังคอมไพล์ไหลคือการมีสาขาหลายแยกที่มักจะอยู่ในแต่ละเพื่อวัตถุประสงค์ที่แตกต่างกัน: master, develop, feature, และrelease ขั้นตอนการพัฒนาฟีเจอร์หรือจุดบกพร่องจะไหลจากสาขาหนึ่งไปยังอีกสาขาหนึ่งก่อนที่จะเปิดตัวในที่สุดhotfix

ผู้ตอบแบบสอบถามบางส่วนระบุว่าใช้git-flowโดยทั่วไป
บางคนเริ่มต้นgit-flowและย้ายออกจากมัน

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

ในระยะสั้น:

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

คุณสามารถดูภาพประกอบที่น่าสนใจเกี่ยวกับเวิร์กโฟลว์ง่ายๆโดยใช้GitHub-Flow ได้ที่:
" โมเดลการแยกคอมไพล์อย่างง่าย " โดยมีองค์ประกอบหลัก ได้แก่ :

1. master จะต้องทำให้ใช้งานได้เสมอ
2. การเปลี่ยนแปลงทั้งหมดที่ทำผ่านสาขาคุณลักษณะ (ดึงคำขอ + รวม)
3. rebase เพื่อหลีกเลี่ยง / แก้ไขความขัดแย้ง รวมเข้ากับmaster

สำหรับขั้นตอนการทำงานที่สมบูรณ์มากขึ้นและมีประสิทธิภาพจริงเห็นgitworkflow (หนึ่งคำ)

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

หลายเวอร์ชันในการผลิต - ใช้Git-flow

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

เวอร์ชันเดียวในการผลิตซอฟต์แวร์อย่างง่าย - ใช้Github-flow

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

เวอร์ชันเดียวในการผลิต แต่มีซอฟต์แวร์ที่ซับซ้อนมาก - ใช้Gitlab-flow

ซอฟต์แวร์ขนาดใหญ่เช่น Facebook และ Gmail คุณอาจต้องแนะนำ สาขาการปรับใช้ระหว่างสาขาและสาขาหลักของคุณซึ่งเครื่องมือ CI / CD> สามารถทำงานได้ก่อนที่จะเข้าสู่การผลิต Idea คือการนำเสนอการป้องกันที่มากขึ้นสำหรับเวอร์ชันที่ใช้งานจริงเนื่องจากผู้คนหลายล้านคนใช้งาน

ฉันใช้โมเดล git-flow มานานกว่าหนึ่งปีแล้วและมันก็โอเค

แต่จริงๆแล้วมันขึ้นอยู่กับวิธีการพัฒนาและปรับใช้แอปพลิเคชันของคุณ

ทำงานได้ดีเมื่อคุณมีแอปพลิเคชันที่มีขั้นตอนการพัฒนา / การปรับใช้ที่ช้า

แต่ตัวอย่างเช่น GitHub เรามีแอปพลิเคชันที่มีขั้นตอนการพัฒนา / การปรับใช้ที่รวดเร็วเราปรับใช้ทุกวันและบางครั้งวันละหลายครั้งในกรณีนี้ git-flow มีแนวโน้มที่จะทำให้ทุกอย่างช้าลงในความคิดของฉันและฉันใช้ GitHub ไหล.

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

มีอย่างน้อยหนึ่ง GUI ที่สนับสนุน Git-ไหลสำหรับ Mac และ Windows SourceTree

ทุกวันนี้ฉันเอนเอียงไปที่กระแส GitHub มากขึ้นเนื่องจากความเรียบง่ายและจัดการได้ง่าย นอกจากนี้เนื่องจาก "ใช้งานได้เร็วมักจะ" ...

หวังว่านี่จะช่วยได้