Git-Based Source Control ในองค์กร: เครื่องมือและแนวทางปฏิบัติที่แนะนำ?

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

แต่ตอนนี้ได้รับคำสั่งในที่ทำงานและตรงไปตรงมาเรากำลังมีปัญหา

git ดูเหมือนจะทำงานได้ไม่ดีสำหรับการพัฒนาแบบรวมศูนย์ในองค์กรขนาดใหญ่ (นักพัฒนา 20+ ราย) ที่มีนักพัฒนาที่มีความสามารถและระดับความซับซ้อนของคอมไพล์ที่แตกต่างกันโดยเฉพาะเมื่อเทียบกับระบบควบคุมแหล่งอื่น ๆ เช่น Perforce หรือ Subversion ซึ่ง มุ่งเป้าไปที่สภาพแวดล้อมแบบนั้น (ใช่ฉันรู้ว่าไลนัสไม่เคยตั้งใจอย่างนั้น)

แต่ - ด้วยเหตุผลทางการเมือง - เราติดอยู่กับคอมไพล์แม้ว่ามันจะแย่สำหรับสิ่งที่เราพยายามจะทำก็ตาม

นี่คือบางสิ่งที่เราเห็น:

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

อย่างไรก็ตามฉันได้ยินมาว่าผู้คนใช้คอมไพล์ได้สำเร็จในองค์กรพัฒนาขนาดใหญ่

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

BTW ฉันเคยถามคำถามนี้ใน LinkedIn แล้วและไม่มีคำตอบที่แท้จริง แต่มีคำตอบมากมาย "เอ้ยฉันก็อยากรู้เหมือนกัน!"

UPDATE: ขอชี้แจง ...

ที่ผมทำงานเราไม่สามารถใช้สิ่งอื่นนอกเหนือจากคอมไพล์ ไม่ใช่ทางเลือก เราติดอยู่กับมัน เราไม่สามารถใช้ Mercurial, svn, bitkeeper, Visual Source Safe, ClearCase, PVCS, SCCS, RCS, bazaar, Darcs, monotone, Perforce, Fossil, AccuRev, CVS หรือแม้แต่โปรเจ็กเตอร์ ol 'ที่ดีของ Apple ที่ฉันใช้ในปี 1987 ดังนั้นในขณะที่คุณยินดีที่จะพูดคุยเกี่ยวกับตัวเลือกอื่น ๆคุณจะไม่ได้รับเงินรางวัลถ้าคุณไม่พูดคุยเกี่ยวกับคอมไพล์

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

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

DVCS กับ CVCS ในบริบทขององค์กร:

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

อีกมิติหนึ่งในบริบทของวินัยคือการส่งเสริมการแตกแขนงและการทดลอง นี่คือคำพูดจากรายการ bliki ล่าสุดของ Martin Fowler ใน Version Control Toolsเขาได้พบคำอธิบายที่กระชับมากสำหรับปรากฏการณ์นี้

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

DVCS ช่วยให้เวิร์กโฟลว์มีความยืดหยุ่นเนื่องจากมีการติดตามชุดการเปลี่ยนแปลงผ่านตัวระบุที่ไม่ซ้ำกันทั่วโลกในกราฟ acyclic ที่กำหนดทิศทาง (DAG) แทนที่จะเป็นข้อความที่แตกต่าง สิ่งนี้ช่วยให้ติดตามที่มาและประวัติของชุดการเปลี่ยนแปลงได้อย่างโปร่งใสซึ่งอาจมีความสำคัญมาก

ขั้นตอนการทำงาน:

Larry Osterman (นักพัฒนาซอฟต์แวร์ของ Microsoft ที่ทำงานในทีม Windows) มีบล็อกโพสต์ที่ยอดเยี่ยมเกี่ยวกับขั้นตอนการทำงานที่ใช้ในทีม Windows โดยเฉพาะอย่างยิ่งพวกเขามี:

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

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

(ภาพนี้ขโมยมาจากhginit.comของ Joel Spolsky )

สิ่งหนึ่งที่ยังคงต้องกล่าวถึงในตอนนี้: - แม้ว่า DVCS จะมีความสามารถในการผสานที่ยอดเยี่ยม แต่ก็ไม่สามารถทดแทนการใช้การผสานรวมแบบต่อเนื่องได้ แม้ในตอนนั้นคุณจะมีความยืดหยุ่นอย่างมาก: CI สำหรับ repo trunk, CI สำหรับ repos ของทีม, ถาม & ตอบ repos เป็นต้น

Git ในบริบทขององค์กร:

Git อาจไม่ใช่ทางออกที่ดีที่สุดสำหรับบริบทขององค์กรอย่างที่คุณได้กล่าวไปแล้ว ฉันคิดว่าสิ่งที่สำคัญที่สุดคือ:

• ยังคงรองรับ Windows ที่ยังไม่บรรลุนิติภาวะ (โปรดแก้ไขฉันหากมีการเปลี่ยนแปลงเมื่อเร็ว ๆ นี้)ตอนนี้ windows มีไคลเอนต์ github windows , tortoisegit , SourceTree จาก atlassian
• ขาดเครื่องมือ GUI ที่เป็นผู้ใหญ่ไม่มีการรวมเครื่องมือ vdiff / merge สำหรับพลเมืองชั้นหนึ่ง
• อินเทอร์เฟซที่ไม่สอดคล้องกันโดยมีระดับนามธรรมที่ต่ำมากที่ด้านบนของการทำงานภายใน
• เส้นโค้งการเรียนรู้ที่สูงชันมากสำหรับผู้ใช้ svn
• Git มีประสิทธิภาพมากและทำให้ง่ายต่อการแก้ไขประวัติอันตรายมากหากคุณไม่รู้ว่ากำลังทำอะไรอยู่ (และบางครั้งคุณก็คิดว่าคุณรู้)
• ไม่มีตัวเลือกการสนับสนุนทางการค้า

ฉันไม่ต้องการเริ่ม git กับ hg flamewar ที่นี่คุณได้ทำตามขั้นตอนที่ถูกต้องแล้วโดยเปลี่ยนเป็น DVCS Mercurial กล่าวถึงบางประเด็นข้างต้นและฉันคิดว่ามันเหมาะกว่าในบริบทขององค์กร:

• รองรับ plattforms ทั้งหมดที่รัน python
• เครื่องมือ GUI ที่ยอดเยี่ยมบนแพลตฟอร์มหลักทั้งหมด (win / linux / OS X) การผสานรวมเครื่องมือชั้นหนึ่ง / vdiff
• อินเทอร์เฟซที่สอดคล้องกันมากเปลี่ยนได้ง่ายสำหรับผู้ใช้ svn
• สามารถทำสิ่งต่างๆส่วนใหญ่ git ก็ทำได้เช่นกัน แต่ให้นามธรรมที่สะอาดกว่า การดำเนินการที่เป็นอันตรายมีความชัดเจนเสมอ คุณลักษณะขั้นสูงมีให้ผ่านทางส่วนขยายที่ต้องเปิดใช้งานอย่างชัดเจน
• มีการสนับสนุนเชิงพาณิชย์จาก selenic

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

ลดแรงเสียดทาน:

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

1. รับหลักสูตรเบื้องต้นเกี่ยวกับคอมไพล์สำหรับทั้งทีม ซึ่งควรรวมถึงพื้นฐานเท่านั้นและแบบฝึกหัดบางอย่าง (สำคัญ!)
2. แปลง repo หลักไปยัง SVN และปล่อยให้ "หนุ่มสาวดาว" Git-SVN สิ่งนี้ทำให้นักพัฒนาส่วนใหญ่มีอินเทอร์เฟซที่ใช้งานง่ายและอาจชดเชยการขาดระเบียบวินัยในทีมของคุณในขณะที่ดาวรุ่งยังคงสามารถใช้คอมไพล์สำหรับ repos ของตนเองได้

พูดตามตรงฉันคิดว่าคุณมีปัญหาเรื่องคนมากกว่าปัญหาเรื่องเครื่องมือ จะทำอะไรได้บ้างเพื่อปรับปรุงสถานการณ์นี้

• คุณควรระบุให้ชัดเจนว่าคุณคิดว่ากระบวนการปัจจุบันของคุณจะจบลงด้วย codebase ที่บำรุงรักษาได้
• ลงทุนเวลาในการผสานรวมอย่างต่อเนื่อง ดังที่ฉันได้ระบุไว้ข้างต้นไม่ว่าคุณจะใช้ VCS ประเภทใดก็ตามจะไม่มีการแทนที่ CI คุณระบุว่ามีคนที่ยัดเยียดเรื่องไร้สาระให้กับ repo หลัก: ให้พวกเขาแก้ไขอึของพวกเขาในขณะที่การแจ้งเตือนสีแดงดับลงและกล่าวโทษพวกเขาที่ทำลายงานสร้าง (หรือไม่ตรงตามตัวชี้วัดคุณภาพหรืออะไรก็ตาม)

ฉันเป็นวิศวกร SCM ขององค์กรเพื่อการพัฒนาที่มีขนาดใหญ่พอสมควรและเราได้เปลี่ยนเป็น git จาก svn ในช่วงปีที่แล้ว เราใช้แบบรวมศูนย์

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

สำหรับข้อกังวลบางประการของคุณ:

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

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

ใช่ฉันรู้ว่าไลนัสไม่เคยตั้งใจอย่างนั้น

จริงๆแล้ว Linus ระบุว่าระบบรวมศูนย์ไม่สามารถทำงานได้

และมีอะไรผิดปกติกับขั้นตอนการทำงานของเผด็จการและผู้แทน?

จำไว้ว่าคอมไพล์เป็นระบบแบบกระจาย อย่าพยายามใช้เหมือนส่วนกลาง

(ปรับปรุง)

ปัญหาส่วนใหญ่ของคุณจะหมดไปถ้าคุณไม่พยายามใช้ git เหมือนกับว่ามันเป็น "svn on steroids" (เพราะมันไม่ใช่)

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

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

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

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

หากผู้ผสานรวมไม่มีเวลาตรวจสอบโค้ดก็ไม่เป็นไร แต่คุณยังต้องมีคนที่รวมการผสานจากทุกคน

การดึงคอมไพล์ไม่ได้ใช้เวลามากนัก

git pull A
git pull B
git pull C

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

• เครื่องมือ GUI ยังไม่สมบูรณ์

เครื่องมือ Gui สามารถจัดการกับสิ่งพื้นฐานได้ดี

การดำเนินการขั้นสูงต้องใช้ coder / nerdy mindset (เช่นฉันสบายใจที่จะทำงานจากบรรทัดคำสั่ง) ต้องใช้เวลาสักหน่อยในการทำความเข้าใจแนวคิด แต่ก็ไม่ยาก

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

สิ่งนี้จะไม่เป็นปัญหาเว้นแต่คุณจะมีนักพัฒนาที่ไร้ความสามารถจำนวนมากที่มีสิทธิ์เขียนเต็มไปยัง "ที่เก็บส่วนกลาง"

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

Git ไม่ทำให้การผสานรวมเป็นเรื่องง่าย

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

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

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

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

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

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

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

• เวิร์กโฟลว์อื่นที่ไม่ใช่ "อะไรก็ได้" หรือ "เผด็จการใจดี" นั้นยากที่จะส่งเสริมให้บังคับคนเดียว

ปัญหาเหล่านี้จะหมดไปเมื่อคุณหยุดพยายามใช้ git ราวกับว่ามันเป็นระบบรวมศูนย์

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

โทร.

คุณมีโครงการประเภทใด

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

แนวทางปฏิบัติที่ดีที่สุดคือการใช้สมองของคุณ

• ด้วยที่เก็บหลายแห่งยังไม่ชัดเจนว่าจะทำซ้ำแหล่งที่มาทั้งหมดที่คนอื่นมีได้อย่างไรโดยดึงจากที่เก็บส่วนกลางหรือทำบางอย่างเช่นรับทุกอย่าง ณ เวลา 4:30 น. เมื่อบ่ายวานนี้

ฉันไม่แน่ใจว่าคุณหมายถึงอะไร

ขอแนะนำhttp://code.google.com/p/gerrit/สำหรับการทำงานระดับองค์กร ช่วยให้คุณสามารถควบคุมการเข้าถึงและเวิร์กโฟลว์ตามการตรวจสอบในตัว ตรวจสอบสิทธิ์กับระบบ LDAP ใด ๆ คุณสามารถเชื่อมต่อกับฮัดสันได้ด้วยhttp://wiki.hudson-ci.org/display/HUDSON/Gerrit+Pluginให้คุณสร้างและทดสอบการเปลี่ยนแปลงในขณะที่ยังอยู่ระหว่างการตรวจสอบ มันเป็นการตั้งค่าที่น่าประทับใจจริงๆ

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

ฉันกำลังตอบคำถามนี้จากประสบการณ์ของฉันในฐานะผู้จัดการนักพัฒนาใน บริษัท โทรคมนาคมขนาดใหญ่ซึ่งเรานำ Git มาใช้ในปี 2010

คุณมีปัญหาค่อนข้างแตกต่างกันที่นี่:

• ขั้นตอนการทำงาน
• เครื่องมือไคลเอนต์
• การควบคุมการเข้าถึงเซิร์ฟเวอร์และการรวม

เวิร์กโฟลว์

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

เครื่องมือไคลเอนต์

ตอนนี้มีหลายทางเลือกให้ใช้งานตอนนี้เป็นพื้นที่ที่มีคนพลุกพล่านมาก นักพัฒนาจำนวนมากประสบความสำเร็จในการใช้IntelliJ IdeaและEclipse ด้วยปลั๊กอิน Gitโดยไม่มีสิ่งอื่นใด นอกจากนี้นักพัฒนา Linux ส่วนใหญ่ใช้ไคลเอนต์ CLI git โดยไม่มีปัญหาใด ๆ บางนักพัฒนา Mac จะประสบความสำเร็จโดยใช้หอ Git โปรดทราบว่าไม่มีไคลเอนต์ใดที่สามารถป้องกันไม่ให้ผู้ใช้ "ยุ่ง" กับที่เก็บส่วนกลางได้: จำเป็นต้องมีการควบคุมความผิดพลาดทางฝั่งเซิร์ฟเวอร์

การควบคุมการเข้าถึงเซิร์ฟเวอร์และการรวม

หากคุณต้องการหลีกเลี่ยงไม่ให้นักพัฒนา "ยุ่ง" ที่เก็บ Git ของคุณคุณต้องเลือกวิธีแก้ปัญหาที่:

• แสดงอินเทอร์เฟซผู้ดูแลระบบเว็บที่เหมาะสมเพื่อดำเนินการทุกอย่าง
• อนุญาตให้คุณบังคับใช้ข้อมูลประจำตัวของผู้ใช้ (การใช้ที่เก็บ Git "เปล่า" นั้นง่ายมากที่จะกระทำในนามของผู้อื่น)
• ให้การรักษาความปลอดภัยแบบละเอียด (ตัวอย่างเช่นคุณสามารถป้องกัน FORCE-PUSH และตั้งค่าบางสาขาให้อ่านเฉพาะสำหรับนักพัฒนา / กลุ่มบางคน)
• รวมเข้ากับระบบรับรองความถูกต้องขององค์กรของคุณ (เช่น LDAP, Windows ActiveDirectory)
• ให้การตรวจสอบอย่างสมบูรณ์ (การปฏิบัติตาม SOX บางครั้งมีความสำคัญมากสำหรับองค์กรขนาดใหญ่)

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

• Gitorious : สามารถให้การรักษาความปลอดภัยระดับการเข้าถึงขั้นพื้นฐานได้ แต่ขาดการควบคุมการอนุญาตแบบละเอียดดังนั้นคุณอาจต้องทำการเข้ารหัสเพื่อจัดการกับสถานการณ์เช่นสิทธิ์ระดับสาขา นอกจากนี้ยังขาดการบูรณาการกับกลไกการตรวจสอบสิทธิ์ขององค์กรที่มีอยู่
• GitHub Enterprise: เผยแพร่เมื่อเร็ว ๆ นี้โดย GitHub โดยมี GitHub ในองค์กรของคุณ ไม่มีการปฏิบัติตามข้อกำหนด SOX และการรักษาความปลอดภัยแบบละเอียด
• Gerrit : สามารถให้การรักษาความปลอดภัยระดับการเข้าถึงที่ละเอียดอ่อนและการรวมเข้ากับระบบตรวจสอบสิทธิ์ขององค์กร แต่ขาดการปฏิบัติตาม SOX และ SSO นอกจากนี้การดำเนินการบางอย่างสามารถทำได้ผ่าน SSH ผ่าน CLI เท่านั้น
• GitEnterprise : ให้สิทธิ์ระดับสาขา, SSO, การปฏิบัติตาม SOX, การดูแลระบบบนเว็บแบบเต็ม เมื่อเร็ว ๆ นี้ยังรวมเข้ากับ Gerrit เพื่อให้คุณได้รับอินสแตนซ์ Gerrit แบบเต็ม

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

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

เกี่ยวกับเครื่องมือผู้ใช้ MacOS X-พบ GitX (http://gitx.frim.nl/) ได้โดยง่ายและมีประสิทธิภาพมาก ข้อเสียเปรียบคือไม่รองรับ Git Client hooks (อันที่ต่ำกว่า $ GIT_ROOT / .git / hooks)

โดยรวมแล้วฉันพยายามอย่างยิ่งที่จะเลือกเครื่องมือที่สนับสนุนการควบคุมการเข้าถึงแบบละเอียดบน: - สาขา (เพื่อแยกสาขารีลีสที่เสถียรด้วยการรักษาความปลอดภัยที่เข้มงวดจากหัวข้อ - สาขาที่ต้องการความคล่องตัวและความยืดหยุ่นมากขึ้น) - การบังคับใช้ข้อมูลประจำตัว (ผู้เขียน / ผู้คอมมิชชัน ) นี่คือกุญแจสำคัญสำหรับ SOX - ข้อ จำกัด คำสั่ง git - การตรวจสอบเส้นทาง นี่คือกุญแจสำคัญสำหรับ SOX

สิ่งที่ฉันใช้กับคุณสมบัติเหล่านี้สำเร็จคือ:

1. รีวิว Gerrit Code (http://code.google.com/p/gerrit/)
2. GitEnterprise (http://gitenterprise.com)
3. CollabNet TeamForge (http://www.collab.net/gotgit) ใช้ Gerrit 2.1.8 อยู่เบื้องหลัง

ป.ล. อย่าประมาทการปฏิบัติตาม SOX และ CMMI : หลายครั้งมีตัวเลือกที่ จำกัด ซึ่งกำหนดโดยนโยบายองค์กรของ บริษัท เกี่ยวกับความปลอดภัย

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

Luca

เราเพิ่งเปลี่ยนจาก svn เป็น git เนื่องจาก git-daemon ไม่ทำงานกับ msysgit เราจึงเลือกใช้วิธีการจัดเก็บส่วนกลางบนเซิร์ฟเวอร์ Linux ที่มี gitosis

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

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

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

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

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

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

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

ฉันจะเพิ่มในโพสต์ "พิจารณาแล้ว" ด้วย

สิ่งที่ยอดเยี่ยมอย่างหนึ่งของบาซาร์คือความยืดหยุ่น นี่คือจุดที่เอาชนะระบบกระจายอื่น ๆ ทั้งหมด คุณสามารถใช้งาน Bazaar ในโหมดรวมศูนย์โหมดกระจายหรือรับสิ่งนี้: ทั้งสองอย่าง (หมายความว่านักพัฒนาสามารถเลือกรุ่นที่พวกเขาพอใจหรือรุ่นใดที่เหมาะกับกลุ่มงานของตนมากที่สุด) คุณยังสามารถยกเลิกการเชื่อมต่อที่เก็บข้อมูลส่วนกลางในขณะที่คุณอยู่บนท้องถนนและเชื่อมต่อใหม่เมื่อคุณกลับมา

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

• ติดตั้งเว็บอินเตอร์เฟสที่ดีเช่นGithub FI
• ยึดติดกับโมเดลที่ค่อนข้างรวมศูนย์ (เริ่มแรก) เพื่อให้ผู้คนสบายใจ
• รันบิวด์การรวมแบบต่อเนื่องสำหรับทุกสาขาที่แชร์
• แบ่งปันชุดตัวเลือกการกำหนดค่าคอมไพล์ส่วนกลางที่ดี
• รวม git เข้ากับเชลล์ของคุณด้วย bash เสร็จสิ้นและพร้อมต์กับสาขาปัจจุบัน
• ลองใช้ Git Integration ของ IntelliJ เป็นเครื่องมือผสาน
• ตรวจสอบว่าคุณ. gitignore ตามความเหมาะสม

เกี่ยวกับคะแนน 3 และ 4 (ต่อผู้ใช้ต่อส่วนสิทธิ์ต่อสาขา) ให้ดูที่gitolite (ครอบคลุมในหนังสือ Pro Git: http://progit.org/book/ch4-8.html )

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

GUI: ในขณะนี้ TortoiseGit v1.7.6 น่าจะใช้ได้ดีสำหรับการใช้งานประจำวันส่วนใหญ่ Log, Commit, Push, Pull, Fetch, Diff, Merge, Branch, Cherry-pick, Rebase, Tag, Export, Stash, Add submodule ฯลฯ ... รองรับ x64 แบบเนทีฟด้วย

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

เหมาะสำหรับการพัฒนา collabrative กว่า gitosis หรือ gitolite แต่เปิดแหล่งที่มาเป็นGitorious เป็นแอปพลิเคชั่น Ruby on Rails ที่จัดการการจัดการที่เก็บและการรวมเข้าด้วยกัน มันควรจะแก้ปัญหาของคุณได้หลายอย่าง

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

NXP กำลังจัดการ Git และ Subversion ด้วยแพลตฟอร์มเดียว (ในระดับองค์กร) โดยผสานรวมการพัฒนามือถือ Android กับโครงการซอฟต์แวร์แบบเดิม: http://www.youtube.com/watch?v=QX5wn0igv7Q