ดังนั้นฉันจึงอยู่ระหว่างการขาย GIT ในที่ทำงาน สิ่งแรกที่ฉันต้องการคือการโน้มน้าวทุกคนว่า GIT ดีกว่าในสิ่งที่พวกเขาคุ้นเคยอยู่แล้ว ปัจจุบันเราใช้ Perforce มีใครผ่านการขายที่คล้ายกันบ้างไหม? ลิงค์ / คำแนะนำที่ดี?
หนึ่งในชัยชนะที่ยิ่งใหญ่คือเราสามารถทำงานได้โดยไม่ต้องเชื่อมต่อกับเครือข่าย IMO ที่ชนะอีกวิธีหนึ่งคือวิธีจัดการเพิ่ม / ชำระเงิน ยินดีรับคะแนนมากขึ้น! นอกจากนี้เรายังมี devs ทั้งหมดประมาณ 10-20 ตัว
คำตอบ:
ซอร์สโค้ดตัวแปล Perl 5 กำลังอยู่ในขั้นตอนการแปลงจาก Perforce เป็น git บางทีgit-p4rawผู้นำเข้าของ Sam Vilain อาจเป็นที่สนใจ
ในกรณีใด ๆ ซึ่งเป็นหนึ่งในชัยชนะที่สำคัญที่คุณกำลังจะมีมากกว่าทุกศูนย์ VCS และคนที่กระจายมากที่สุดยังเป็นดิบพองความเร็ว คุณนึกภาพไม่ออกเลยว่าการมีประวัติโครงการทั้งหมดอยู่ในมือเป็นเพียงเศษส่วนเศษส่วนของเสี้ยววินาทีจนกว่าคุณจะได้สัมผัส แม้แต่การสร้างบันทึกการคอมมิตของประวัติโปรเจ็กต์ทั้งหมดที่มีค่าความแตกต่างแบบเต็มสำหรับแต่ละคอมมิตก็สามารถวัดเป็นเศษเสี้ยวของวินาทีได้ Git เร็วมากจนหมวกของคุณจะปลิว VCS ที่ต้องไปกลับผ่านเครือข่ายก็ไม่มีโอกาสแข่งขันหรือแม้แต่ผ่านลิงค์ Gigabit Ethernet
นอกจากนี้คอมไพล์ยังช่วยให้เลือกอย่างรอบคอบเมื่อทำการคอมมิตจึงทำให้การเปลี่ยนแปลงในสำเนางานของคุณ (หรือแม้กระทั่งภายในไฟล์เดียว) สามารถกระจายออกไปในการคอมมิตหลาย ๆ ครั้งและข้ามสาขาต่างๆได้หากคุณต้องการ วิธีนี้ช่วยให้คุณจดบันทึกจิตใจน้อยลงในขณะทำงานคุณไม่จำเป็นต้องวางแผนงานของคุณอย่างรอบคอบตัดสินใจล่วงหน้าว่าคุณจะทำอะไรเปลี่ยนแปลงอะไรบ้างและอย่าลืมเลื่อนสิ่งอื่นใดออกไป คุณสามารถทำการเปลี่ยนแปลงใด ๆ ที่คุณต้องการเมื่อเกิดขึ้นกับคุณและยังคงแก้ปัญหาได้เกือบตลอดเวลา - เมื่อถึงเวลาที่ต้องกระทำ ที่ซ่อนสามารถช่วยได้มากที่นี่
ฉันพบว่าเมื่อรวมกันแล้วข้อเท็จจริงเหล่านี้ทำให้ฉันสร้างความมุ่งมั่นมากขึ้นและมีสมาธิมากขึ้นกว่าก่อนที่ฉันจะใช้คอมไพล์ นี้ในการเปิดไม่เพียง แต่ทำให้ประวัติของคุณโดยทั่วไปที่มีประโยชน์มากขึ้น git bisectแต่จะเป็นประโยชน์อย่างยิ่งสำหรับเครื่องมือมูลค่าเพิ่มเช่น
ฉันแน่ใจว่ามีหลายอย่างที่ฉันคิดไม่ถึงในตอนนี้ ปัญหาอย่างหนึ่งของการขายทีมของคุณในคอมไพล์ก็คือผลประโยชน์หลาย ๆ อย่างมีความสัมพันธ์กันและไม่เห็นด้วยกันดังที่ฉันได้บอกไว้ข้างต้นดังนั้นจึงยากที่จะดูรายการคุณสมบัติและประโยชน์ของคอมไพล์และสรุปว่าพวกเขาเป็นอย่างไร กำลังจะเปลี่ยนขั้นตอนการทำงานของคุณและการเปลี่ยนแปลงใดที่จะเป็นการปรับปรุงโบนาไฟด์ คุณต้องคำนึงถึงสิ่งนี้และคุณต้องชี้ให้ชัดเจนด้วย
ฉันใช้ Perforce ในที่ทำงาน ฉันยังใช้ Git เพราะฉันยังต้องการการควบคุมเวอร์ชันบางรูปแบบเมื่อฉันทำงานกับโค้ดและไม่สามารถเชื่อมต่อกับเซิร์ฟเวอร์ได้ ไม่กระทบงานออฟไลน์ก็ไม่เหมือนเดิม นี่คือที่ที่ฉันพบว่าคอมไพล์เป็นประโยชน์อย่างมาก:
นั่นคือ 2 เซ็นต์ของฉัน ในการป้องกันของ Perforce ฉันต้องพูดกฎการสนับสนุนลูกค้าของพวกเขาและเครื่องมือ Time Lapse View ของพวกเขาก็เช่นกัน ไม่รู้จะดูไทม์แลปส์ด้วยคอมไพล์ได้อย่างไร แต่เพื่อความสะดวกและประหยัดเวลาฉันจะใช้คอมไพล์ทุกวัน
ฉันต้องใช้ความมั่นใจมากในการเปลี่ยนจาก perforce ในสอง บริษัท ฉันใช้มันมากเกินพอ บริษัท เหล่านี้เป็นทั้งสอง บริษัท ที่มีสำนักงานแตกต่างกัน แต่สำนักงานได้รับการจัดตั้งขึ้นด้วยโครงสร้างพื้นฐานจำนวนมากดังนั้นจึงไม่จำเป็นต้องมีคุณสมบัติที่ไม่เชื่อมต่อ / ขาดการเชื่อมต่อ
คุณกำลังพูดถึงการเปลี่ยนแปลงของนักพัฒนากี่คน?
คำถามที่แท้จริงคืออะไรเกี่ยวกับการบังคับใช้ที่ไม่ตรงตามความต้องการขององค์กรของคุณที่คอมไพล์สามารถให้ได้? และในทำนองเดียวกัน git มีจุดอ่อนอะไรบ้างเมื่อเทียบกับ perforce? ถ้าคุณไม่สามารถตอบตัวเองได้การถามที่นี่จะไม่ช่วย คุณต้องหากรณีทางธุรกิจสำหรับ บริษัท ของคุณ (เช่นบางทีอาจเป็นเพราะต้นทุนการเป็นเจ้าของโดยรวมที่ต่ำกว่า (ซึ่งรวมถึงการสูญเสียผลผลิตสำหรับขั้นตอนการเรียนรู้ระหว่างกาลค่าใช้จ่ายในการดูแลระบบที่สูงขึ้น (อย่างน้อยในตอนแรก) ฯลฯ )
ฉันคิดว่าคุณอยู่ในการขายที่ยาก - การบังคับใช้เป็นสิ่งที่ดีที่จะพยายามแทนที่ ไม่ใช่เกมง่ายๆหากคุณพยายามบูต pvcs หรือ ssafe
ฉันคิดว่าในแง่ของการทำให้ผู้คนมีความสุขในระหว่าง / โพสต์การสลับไปมาสิ่งหนึ่งที่ควรหลีกเลี่ยงตั้งแต่เนิ่นๆก็คือความเป็นส่วนตัวของสาขาท้องถิ่นใน Git และเสรีภาพที่ให้พวกเขาทำผิดพลาด ให้พวกเขาทั้งหมดโคลนสาขาส่วนตัวสองสามแห่งจากโค้ดปัจจุบันจากนั้นทดลองใช้งาน เปลี่ยนชื่อไฟล์บางไฟล์ตรวจสอบข้อมูลรวมสิ่งต่างๆจากสาขาอื่นกรอกประวัติย้อนกลับฐานการเปลี่ยนแปลงชุดหนึ่งทับอีกชุดหนึ่งและอื่น ๆ แสดงให้เห็นว่าแม้แต่อุบัติเหตุที่เลวร้ายที่สุดในพื้นที่ก็ไม่มีผลต่อเพื่อนร่วมงาน สิ่งที่คุณต้องการคือสถานการณ์ที่นักพัฒนารู้สึกปลอดภัยเพื่อให้พวกเขาเรียนรู้ได้เร็วขึ้น (เนื่องจาก Git มีช่วงการเรียนรู้ที่สูงชันซึ่งสำคัญ) และในที่สุดพวกเขาก็จะมีประสิทธิภาพมากขึ้นในฐานะนักพัฒนา
เมื่อคุณพยายามเรียนรู้เครื่องมือจากส่วนกลางแน่นอนว่าคุณจะกังวลเกี่ยวกับการทำผิดบางอย่างที่ทำให้เกิดปัญหากับผู้ใช้ที่เก็บรายอื่น ความกลัวความอับอายเพียงอย่างเดียวก็เพียงพอแล้วที่จะกีดกันผู้คนจากการทดลอง แม้แต่การมีที่เก็บ "การฝึกอบรม" แบบพิเศษก็ไม่ได้ช่วยอะไรเพราะนักพัฒนาจะต้องเผชิญกับสถานการณ์ในระบบการผลิตที่พวกเขาไม่เคยเห็นระหว่างการฝึกอบรมอย่างหลีกเลี่ยงไม่ได้ดังนั้นพวกเขาจึงกลับมากังวล
แต่ลักษณะการกระจายของ Git ทำได้ด้วยสิ่งนี้ คุณสามารถทดลองใช้การทดลองใดก็ได้ในสาขาในพื้นที่และหากเกิดความผิดพลาดอย่างมากให้โยนสาขาออกไปและไม่มีใครต้องการทราบ เนื่องจากคุณสามารถสร้างสาขาในท้องถิ่นของอะไรก็ได้คุณจึงสามารถจำลองปัญหาที่คุณพบได้ด้วยที่เก็บข้อมูลจริง แต่ก็ไม่มีอันตรายจากการ "ทำลายโครงสร้าง" หรือทำให้ตัวเองเป็นคนโง่ คุณสามารถตรวจสอบทุกอย่างได้ทันทีที่คุณทำเสร็จแล้วไม่ต้องพยายามจัดชุดให้เป็นชุดเล็ก ๆ น้อย ๆ ดังนั้นไม่ใช่แค่การเปลี่ยนแปลงรหัสหลักสองรายการที่คุณใช้เวลาสี่ชั่วโมงในวันนี้ แต่ยังรวมถึงการสร้างการแก้ไขที่คุณจำได้ครึ่งทางและความผิดพลาดในการสะกดคำในเอกสารที่คุณพบขณะอธิบายบางสิ่งบางอย่างให้เพื่อนร่วมงานและอื่น ๆ และหากการเปลี่ยนแปลงที่สำคัญถูกยกเลิกเนื่องจากโครงการกำลังเปลี่ยนทิศทาง
git log --graph) เนื่องจากประวัติการแก้ไข Git มีแนวโน้มที่จะไม่เป็นเชิงเส้นและยากที่จะมองเห็นได้โดยไม่มีภาพ ฉันใช้ GitX และ SourceTree เป็น GUI แม้ว่า gitk (ซึ่งมาพร้อมกับ Git ในตอนนี้) จะผ่านได้ในพริบตา
ผู้คนใช้คุณลักษณะของ Perforce อะไรบ้าง?
ฉันถามเพราะถ้าทุกคนกำลังทำคือรับและวางจากบรรทัดคำสั่งคอมไพล์ก็ครอบคลุมและทำ RTS อื่น ๆ ทั้งหมด
เห็นได้ชัดว่าGitHub เสนอหลักสูตรฝึกอบรม git ให้กับ บริษัทต่างๆ Quoth โพสต์บล็อกของพวกเขาเกี่ยวกับเรื่องนี้ :
ฉันเคยไปที่วิทยาเขตของ Google หลายครั้งในช่วงสองสามสัปดาห์ที่ผ่านมาเพื่อช่วยฝึก Android ที่นั่นใน Git ฉันถูกถามโดย Shawn Pearce (คุณอาจรู้จักเขาจากความรุ่งโรจน์ Git และ EGit / JGit ของเขา - เขาเป็นฮีโร่ที่เข้ามาดูแลการบำรุงรักษาเมื่อ Junio ไม่อยู่ในเมือง) ให้เข้ามาช่วยเขาฝึกวิศวกรของ Google ที่ทำงานกับ Andriod ในการเปลี่ยนแปลง จาก Perforce ถึง Gitเพื่อให้ Android สามารถแชร์กับคนทั่วไปได้ ฉันสามารถบอกคุณได้ว่าฉันมีความสุขมากกว่าที่ได้ทำ
[…]
ขณะนี้ Logical Awesome เสนอบริการฝึกอบรมแบบกำหนดเองประเภทนี้ให้กับทุก บริษัทอย่างเป็นทางการซึ่งเราสามารถช่วยองค์กรของคุณในการฝึกอบรมและการวางแผนหากคุณคิดจะเปลี่ยนไปใช้ Git ด้วย
เน้นของฉัน
ฉันใช้ Perforce มาเป็นเวลานานและเมื่อเร็ว ๆ นี้ฉันก็เริ่มใช้ GIT ด้วย นี่คือความคิดเห็น "วัตถุประสงค์" ของฉัน:
คุณสมบัติของ Perforce:
คุณสมบัติ GIT:
โดยรวมสำหรับโครงการ OpenSource / Distributed ฉันมักจะแนะนำ GIT เพราะเป็นเหมือนแอปพลิเคชัน P2P และทุกคนสามารถมีส่วนร่วมในการพัฒนาได้ ตัวอย่างเช่นฉันจำได้ว่าตอนที่ฉันทำการพัฒนาระยะไกลกับ Perforce ฉันกำลังซิงค์โปรเจ็กต์ 4GB ผ่านลิงก์ 1Mbps หนึ่งครั้งในหนึ่งสัปดาห์ เสียเวลาไปมากเพราะเหตุนั้น เราต้องตั้งค่า VPN เพื่อทำเช่นนั้น
หากคุณมี บริษัท ขนาดเล็กและเซิร์ฟเวอร์ P4 จะพร้อมใช้งานอยู่เสมอฉันจะบอกว่า Perforce เป็นตัวเลือกที่ดีมากเช่นกัน
เราใช้ Git มาระยะหนึ่งแล้วเมื่อเร็ว ๆ นี้ฮาร์ดไดรฟ์ของเซิร์ฟเวอร์ Git ของเราขัดข้องและเราไม่สามารถเปลี่ยนกลับไปเป็นสถานะล่าสุดได้ เราสามารถกลับไปสู่สภาพเก่าได้ไม่กี่วัน เมื่อเซิร์ฟเวอร์สำรอง ทุกคนในทีมดึง / ผลักดันการเปลี่ยนแปลงและ voila เซิร์ฟเวอร์จะกลับสู่สถานะปัจจุบัน
ความแตกต่างที่สำคัญอย่างหนึ่งระหว่าง Perforce และ git (และที่กล่าวถึงกันมากที่สุด) คือการจัดการไฟล์ไบนารีขนาดใหญ่ตามลำดับ
เช่นในบล็อกนี้ของพนักงานที่ บริษัท พัฒนาวิดีโอเกม: http://corearchitecture.blogspot.com/2011/09/git-vs-perforce-from-game-development.html
อย่างไรก็ตามสิ่งที่สำคัญคือความแตกต่างของความเร็วระหว่าง git และ perforce เมื่อคุณมีพื้นที่เก็บข้อมูลขนาดใหญ่ 6gb ซึ่งมีทุกอย่างตั้งแต่เอกสารประกอบไปจนถึงไบนารีทุกตัวที่เคยสร้างมา (และสุดท้ายโอ้ใช่ประวัติแหล่งที่มาจริง) มักมาจาก ความจริงที่ว่า บริษัท ขนาดใหญ่มักจะดำเนินการ Perforce ดังนั้นพวกเขาจึงตั้งค่าให้ถ่ายโอนการดำเนินงานที่สำคัญทั้งหมดไปยังธนาคารเซิร์ฟเวอร์ขนาดใหญ่ที่ชั้นใต้ดิน
ข้อได้เปรียบที่สำคัญในส่วนของ Perforce มาจากปัจจัยที่ไม่มีส่วนเกี่ยวข้องใด ๆ กับ Perforce ความจริงที่ว่า บริษัท ที่ดำเนินการอยู่สามารถจ่ายธนาคารเซิร์ฟเวอร์ดังกล่าวได้
และสุดท้ายแล้ว Perforce และ git เป็นผลิตภัณฑ์ที่แตกต่างกัน Git ได้รับการออกแบบให้เป็น VCS เพียงอย่างเดียวและทำได้ดีกว่า Perforce มาก (เนื่องจากมีคุณสมบัติมากกว่าซึ่งโดยทั่วไปใช้งานง่ายกว่าโดยเฉพาะอย่างยิ่งในคำพูดอื่นการแยกสาขาใน Perforce ก็เหมือนกับการแสดงแบบเปิดใจ การผ่าตัดควรทำโดยผู้เชี่ยวชาญเท่านั้น: P) ( http://stevehanov.ca/blog/index.php?id=50 )
ผลประโยชน์อื่น ๆ ที่ บริษัท ที่ใช้ Perforce ได้รับมานั้นเป็นเพียงเพราะ Perforce ไม่ใช่ VCS แต่เพียงอย่างเดียว แต่ยังเป็นเซิร์ฟเวอร์ไฟล์รวมถึงมีคุณสมบัติอื่น ๆ สำหรับการทดสอบประสิทธิภาพของบิลด์ ฯลฯ
ประการสุดท้าย: Git เป็นโอเพ่นซอร์สและมีความยืดหยุ่นในการบูตมากขึ้นการแก้ไข git เพื่อถ่ายโอนการดำเนินการที่สำคัญไปยังเซิร์ฟเวอร์กลางนั้นไม่ยากนักโดยเรียกใช้ฮาร์ดแวร์ราคาแพง
ฉันคิดว่าสิ่งหนึ่งที่ฉันรู้ว่า GIT ชนะก็คือความสามารถในการ "เก็บรักษาส่วนท้ายบรรทัด" ในทุกไฟล์ในขณะที่ Perforce ดูเหมือนจะยืนยันที่จะแปลเป็นรูปแบบ Unix, Dos / Windows หรือ MacOS9 ("\ n", "\ r \ n "หรือ" \ r)
นี่เป็นความเจ็บปวดอย่างแท้จริงหากคุณกำลังเขียนสคริปต์ Unix ในสภาพแวดล้อม Windows หรือระบบปฏิบัติการแบบผสม เป็นไปไม่ได้ที่จะตั้งกฎเป็นรายไฟล์ - นามสกุล ตัวอย่างเช่นจะแปลงไฟล์. sh, .bash, .unix เป็นรูปแบบ Unix และแปลงไฟล์. ccp, .bat หรือ. com เป็นรูปแบบ Dos / Windows
ใน GIT (ฉันไม่แน่ใจว่าเป็นค่าเริ่มต้นตัวเลือกหรือตัวเลือกเดียว) คุณสามารถตั้งค่าเป็น "สงวนส่วนท้ายบรรทัด" ได้ นั่นหมายความว่าคุณสามารถเปลี่ยนส่วนท้ายบรรทัดของไฟล์ได้ด้วยตนเองจากนั้น GIT จะออกจากรูปแบบนั้นอย่างที่เป็นอยู่ สำหรับฉันแล้วสิ่งนี้ดูเหมือนจะเป็นวิธีที่ดีที่สุดในการทำสิ่งต่างๆและฉันไม่เข้าใจว่าเหตุใดจึงไม่ใช่ตัวเลือกสำหรับ Perforce
วิธีเดียวที่คุณสามารถบรรลุพฤติกรรมนี้คือการทำเครื่องหมายไฟล์เป็นไบนารี อย่างที่ฉันเห็นนั่นอาจเป็นการแฮ็กที่น่ารังเกียจในการแก้ไขปัญหาเกี่ยวกับคุณลักษณะที่ขาดหายไป นอกเหนือจากความน่าเบื่อที่จะต้องทำกับสคริปต์ทั้งหมดแล้วยังอาจแตกต่างกันมากที่สุด ฯลฯ
"โซลูชัน" ที่เราได้ตัดสินใจในขณะนี้คือการเรียกใช้คำสั่ง sed เพื่อลบการส่งคืนค่าการขนส่งทั้งหมดออกจากสคริปต์ทุกครั้งที่นำไปใช้กับสภาพแวดล้อม Unix สิ่งนี้ไม่เหมาะอย่างยิ่งโดยเฉพาะอย่างยิ่งเนื่องจากบางส่วนถูกปรับใช้ภายในไฟล์ WAR และบรรทัด sed จะต้องถูกเรียกใช้อีกครั้งเมื่อไม่ได้บรรจุ
นี่เป็นเพียงสิ่งที่ฉันคิดว่าทำให้ GIT ได้เปรียบอย่างมากซึ่งฉันไม่คิดว่าจะมีการกล่าวถึงข้างต้น
แก้ไข: หลังจากใช้ Perforce มานานกว่านี้ฉันต้องการเพิ่มความคิดเห็นอีกสองสามข้อ:
A) สิ่งที่ฉันพลาดจริงๆใน Perforce คือความแตกต่างที่ชัดเจนรวมถึงไฟล์ที่เปลี่ยนแปลงลบและเพิ่ม สิ่งนี้มีอยู่ใน GIT ด้วยgit diffคำสั่ง แต่ใน Perforce ไฟล์จะต้องได้รับการตรวจสอบก่อนที่จะบันทึกการเปลี่ยนแปลงและในขณะที่คุณอาจตั้งค่าตัวแก้ไขหลัก (เช่น Eclipse) ให้ตรวจสอบไฟล์โดยอัตโนมัติเมื่อคุณแก้ไขคุณ บางครั้งอาจแก้ไขไฟล์ด้วยวิธีอื่น (notepad คำสั่ง unix ฯลฯ ) และไฟล์ใหม่ดูเหมือนจะไม่ถูกเพิ่มโดยอัตโนมัติเลยแม้แต่การใช้ Eclipse และ p4eclipse ซึ่งอาจค่อนข้างน่ารำคาญ ดังนั้นในการค้นหาการเปลี่ยนแปลงทั้งหมดคุณต้องเรียกใช้ "ความแตกต่างกับ ... " บนพื้นที่ทำงานทั้งหมดซึ่งก่อนอื่นต้องใช้เวลาสักครู่ในการรันและประการที่สองรวมถึงสิ่งที่ไม่เกี่ยวข้องทั้งหมดเว้นแต่คุณจะตั้งค่ารายการยกเว้นที่ซับซ้อนมาก ซึ่งนำฉันไปสู่จุดต่อไป
B) ใน GIT ฉันพบว่า. gitignore ง่ายมากและง่ายต่อการจัดการอ่านและทำความเข้าใจ อย่างไรก็ตามพื้นที่ทำงานจะละเว้น / ไม่รวมรายการที่กำหนดค่าได้ใน Perforce ดูเหมือนไม่สะดวกและซับซ้อนโดยไม่จำเป็น ฉันไม่สามารถได้รับการยกเว้นใด ๆ ที่ใช้สัญลักษณ์แทนได้ ฉันต้องการทำสิ่งที่ชอบ
-//Server/mainline/.../target/... //Svend_Hansen_Server/.../target/...
เพื่อยกเว้นโฟลเดอร์เป้าหมายทั้งหมดภายในโปรเจ็กต์ทั้งหมดภายในเซิร์ฟเวอร์ / เมนไลน์ อย่างไรก็ตามสิ่งนี้ดูเหมือนจะไม่ได้ผลอย่างที่ฉันคาดไว้และฉันได้เพิ่มบรรทัดสำหรับทุกโครงการเช่น:
-//Server/mainline/projectA/target/... //Svend_Hansen_Server/projectA/target/...
-//Server/mainline/projectB/target/... //Svend_Hansen_Server/projectB/target/...
...
และบรรทัดที่คล้ายกันสำหรับโฟลเดอร์ bin ไฟล์. classpath และ .projet และอื่น ๆ
C) ใน Perforce มีรายการเปลี่ยนแปลงที่ค่อนข้างมีประโยชน์ อย่างไรก็ตามสมมติว่าฉันทำการเปลี่ยนแปลงกลุ่มหนึ่งตรวจสอบทั้งหมดและใส่ไว้ในรายการการเปลี่ยนแปลงเพื่อดำเนินการอย่างอื่นก่อนส่งรายการการเปลี่ยนแปลงนั้น หากฉันทำการเปลี่ยนแปลงไฟล์ใดไฟล์หนึ่งที่รวมอยู่ในรายการการเปลี่ยนแปลงรายการแรกในภายหลังไฟล์นั้นจะยังคงอยู่ในรายการการเปลี่ยนแปลงนั้นและฉันไม่สามารถส่งรายการการเปลี่ยนแปลงได้ในภายหลังโดยสมมติว่ามีเฉพาะการเปลี่ยนแปลงที่ฉันได้เพิ่มไว้ในตอนแรก (แม้ว่าจะเป็น จะเป็นไฟล์เดียวกัน) ใน GIT หากคุณเพิ่มไฟล์และทำการเปลี่ยนแปลงเพิ่มเติมการเปลี่ยนแปลงเหล่านั้นจะไม่ถูกเพิ่ม (และจะยังคงแสดงในgit diffและคุณจะไม่สามารถคอมมิตไฟล์ได้โดยไม่ต้องเพิ่มการเปลี่ยนแปลงใหม่ก่อนเช่นกัน แน่นอนว่านี่ไม่ได้มีประโยชน์ในลักษณะเดียวกับรายการการเปลี่ยนแปลงเนื่องจากคุณมีไฟล์ที่เพิ่มเข้ามาเพียงชุดเดียว แต่ใน GIT คุณสามารถทำการเปลี่ยนแปลงได้เนื่องจากไม่ได้ผลักดันให้เกิดขึ้นจริง คุณสามารถดำเนินการกับการเปลี่ยนแปลงอื่น ๆ ก่อนที่จะผลักดันได้ แต่คุณจะไม่สามารถผลักดันสิ่งอื่นที่คุณเพิ่มเข้ามาในภายหลังได้โดยไม่ต้องผลักดันการเปลี่ยนแปลงในอดีตเช่นกัน
ฉันไม่มีประสบการณ์กับ Git แต่ฉันมี Mercurial ซึ่งเป็น VCS แบบกระจาย ขึ้นอยู่กับโครงการจริงๆ แต่ในกรณีของเรา VCS แบบกระจายเหมาะกับโครงการเนื่องจากโดยทั่วไปแล้วจะกำจัดงานสร้างที่เสียบ่อย
ฉันคิดว่ามันขึ้นอยู่กับโปรเจ็กต์จริง ๆ เนื่องจากบางอันเหมาะกับไคลเอนต์เซิร์ฟเวอร์ VCS มากกว่าและอื่น ๆ ก็ลากแบบกระจาย
นี่คือสิ่งที่ฉันไม่ชอบเกี่ยวกับคอมไพล์:
ก่อนอื่นฉันคิดว่าความคิดแบบกระจายนั้นบินไปมาเมื่อเผชิญกับความเป็นจริง ทุกคนที่ใช้คอมไพล์จริงก็ทำแบบรวมศูนย์แม้แต่ Linus Torvalds หากเคอร์เนลได้รับการจัดการแบบกระจายนั่นหมายความว่าฉันไม่สามารถดาวน์โหลดแหล่งที่มาของเคอร์เนล "อย่างเป็นทางการ" ได้ - ไม่มีเลย - ฉันต้องตัดสินใจว่าฉันต้องการเวอร์ชันของ Linus หรือเวอร์ชันของ Joe หรือเวอร์ชันของบิล เห็นได้ชัดว่ามันไร้สาระและนั่นเป็นเหตุผลว่าทำไมจึงมีคำจำกัดความอย่างเป็นทางการซึ่ง Linus ควบคุมโดยใช้เวิร์กโฟลว์แบบรวมศูนย์
หากคุณยอมรับว่าคุณต้องการคำจำกัดความแบบรวมศูนย์ของเนื้อหาของคุณก็จะเห็นได้ชัดว่าบทบาทเซิร์ฟเวอร์และไคลเอนต์แตกต่างกันอย่างสิ้นเชิงดังนั้นความเชื่อที่ว่าไคลเอนต์และซอฟต์แวร์เซิร์ฟเวอร์ควรจะเหมือนกันจึงกลายเป็นข้อ จำกัด อย่างแท้จริง เชื่อว่าลูกค้าและเซิร์ฟเวอร์ข้อมูลที่ควรจะเหมือนกันจะกลายเป็นไร้สาระยะโดยเฉพาะอย่างยิ่งใน codebase ที่ก็มีสิบห้าปีของประวัติศาสตร์ที่ไม่มีใครใส่ใจเกี่ยวกับ แต่ทุกคนจะต้องมีการโคลน
สิ่งที่เราอยากจะทำจริงๆกับของเก่าทั้งหมดนั้นคือการเก็บมันไว้ในตู้และลืมไปว่ามันอยู่ที่นั่นเหมือนกับที่ VCS ทั่วไปทำ ความจริงที่ว่าคอมไพล์ลากมันไปมาบนเครือข่ายทุกวันนั้นอันตรายมากเพราะมันทำให้คุณต้องตัดมันทิ้ง การตัดแต่งกิ่งนั้นเกี่ยวข้องกับการตัดสินใจที่น่าเบื่อมากมายและอาจผิดพลาดได้ ดังนั้นผู้คนอาจจะเก็บสแน็ปช็อต repos ทั้งชุดจากจุดต่างๆในประวัติศาสตร์ แต่นั่นไม่ใช่ว่าการควบคุมแหล่งที่มาคืออะไรในตอนแรก? ปัญหานี้ไม่เกิดขึ้นจนกว่าจะมีคนคิดค้นแบบจำลองแบบกระจาย
Git กระตุ้นให้ผู้คนเขียนประวัติศาสตร์ซ้ำและข้างต้นอาจเป็นสาเหตุหนึ่งที่ทำให้เกิดสิ่งนั้น VCS ปกติทุกตัวทำให้ประวัติการเขียนใหม่เป็นไปไม่ได้สำหรับทุกคนยกเว้นผู้ดูแลระบบและทำให้แน่ใจว่าผู้ดูแลระบบไม่มีเหตุผลที่จะพิจารณา แก้ไขฉันถ้าฉันผิด แต่เท่าที่ฉันรู้ git ไม่มีทางให้สิทธิ์การเขียนแก่ผู้ใช้ทั่วไป แต่ห้ามไม่ให้เขียนประวัติซ้ำ นั่นหมายความว่านักพัฒนาซอฟต์แวร์ใด ๆ ที่มีความไม่พอใจ (หรือผู้ที่ยังคงดิ้นรนกับช่วงการเรียนรู้) สามารถทิ้งโค้ดเบสทั้งหมดได้ เราจะกระชับอันนั้นได้อย่างไร? ไม่ว่าคุณจะทำการสำรองข้อมูลประวัติทั้งหมดเป็นประจำเช่นคุณเก็บประวัติไว้เป็นกำลังสองหรือคุณห้ามการเข้าถึงการเขียนทั้งหมดยกเว้นคนที่น่าสงสารบางคนที่จะได้รับความแตกต่างทั้งหมดทางอีเมลและรวมเข้าด้วยกัน
ลองดูตัวอย่างโครงการขนาดใหญ่ที่ได้รับการสนับสนุนอย่างดีและดูว่า git ทำงานอย่างไรสำหรับพวกเขา: Android ครั้งหนึ่งฉันตัดสินใจที่จะเล่นกับระบบ Android เอง ฉันพบว่าฉันควรจะใช้สคริปต์จำนวนมากที่เรียกว่า repo เพื่อรับคอมไพล์ของพวกเขา repo บางส่วนทำงานบนไคลเอนต์และบางส่วนบนเซิร์ฟเวอร์ แต่ทั้งสองอย่างนั้นแสดงให้เห็นถึงความจริงที่ว่า git ไม่สมบูรณ์ในความสามารถอย่างใดอย่างหนึ่ง สิ่งที่เกิดขึ้นคือฉันไม่สามารถดึงแหล่งข้อมูลได้ประมาณหนึ่งสัปดาห์จากนั้นก็ล้มเลิกไปทั้งหมด ฉันจะต้องดึงข้อมูลจำนวนมหาศาลจากที่เก็บต่างๆมากมาย แต่เซิร์ฟเวอร์ก็มีคนอย่างฉันมากเกินไป Repo หมดเวลาและไม่สามารถดำเนินการต่อจากจุดที่หมดเวลาได้ ถ้าคอมไพล์กระจายได้มากคุณคงคิดว่า d ได้ทำบางอย่างแบบเพียร์ทูเพียร์เพื่อลดภาระบนเซิร์ฟเวอร์เครื่องหนึ่ง Git สามารถแจกจ่ายได้ แต่ไม่ใช่เซิร์ฟเวอร์ Git + repo เป็นเซิร์ฟเวอร์ แต่ repo ไม่สามารถแจกจ่ายได้เนื่องจากเป็นเพียงชุดแฮ็กเฉพาะกิจ
ภาพประกอบที่คล้ายกันของความไม่เพียงพอของ git คือ gitolite (และบรรพบุรุษของมันซึ่งดูเหมือนจะไม่ได้ผลดีนัก) Gitolite อธิบายถึงงานของมันในการทำให้การปรับใช้เซิร์ฟเวอร์ git ง่ายขึ้น อีกครั้งการมีอยู่ของสิ่งนี้พิสูจน์ให้เห็นว่า git ไม่ใช่เซิร์ฟเวอร์ แต่เป็นไคลเอนต์ ยิ่งไปกว่านั้นมันจะไม่เป็นเช่นนั้นเพราะถ้ามันเติบโตขึ้นมามันจะเป็นการทรยศต่อหลักการก่อตั้ง
แม้ว่าคุณจะเชื่อในสิ่งที่กระจาย แต่คอมไพล์ก็ยังคงเป็นระเบียบ ตัวอย่างเช่นสาขาคืออะไร? พวกเขาบอกว่าคุณสร้างสาขาโดยปริยายทุกครั้งที่คุณโคลนที่เก็บ แต่นั่นไม่สามารถเป็นสิ่งเดียวกับสาขาในที่เก็บเดียวได้ นั่นคืออย่างน้อยสองสิ่งที่แตกต่างกันที่เรียกว่ากิ่งไม้ แต่จากนั้นคุณสามารถกรอกลับใน repo และเริ่มแก้ไขได้ มันเหมือนสาขาประเภทที่สองหรืออะไรที่แตกต่างออกไป อาจขึ้นอยู่กับประเภทของ repo ที่คุณมี - โอ้ใช่ - ดูเหมือนว่า repo ไม่ใช่แนวคิดที่ชัดเจนเช่นกัน มีทั้งตัวปกติและตัวเปล่า คุณไม่สามารถดันเป็นส่วนปกติได้เนื่องจากส่วนที่เปลือยเปล่าอาจไม่ตรงกับโครงสร้างต้นทาง แต่คุณไม่สามารถนำเข้า cvsimport แบบเปลือยได้เพราะพวกเขาไม่ได้คิดถึงสิ่งนั้น ดังนั้นคุณต้อง cvsimport เป็นแบบปกติ โคลนนั้นเป็นไฟล์เปล่าที่นักพัฒนาตีและ cvsexport นั้นไปยังสำเนาที่ใช้งานได้ cvs ซึ่งยังต้องตรวจสอบเป็น cvs ใครจะไปรบกวนได้ ภาวะแทรกซ้อนเหล่านี้มาจากไหน? จากความคิดที่กระจายตัวเอง ในที่สุดฉันก็ทิ้ง gitolite เพราะมันทำให้ฉันมีข้อ จำกัด มากขึ้น
Git กล่าวว่าการแยกสาขาควรมีน้ำหนักเบา แต่หลาย บริษัท มีปัญหาสาขาที่โกงร้ายแรงอยู่แล้วดังนั้นฉันจึงคิดว่าการแยกสาขาควรเป็นการตัดสินใจครั้งสำคัญด้วยการรักษาที่เข้มงวด นี่คือจุดที่ perforce ส่องแสงจริงๆ ...
ในการบังคับใช้คุณแทบไม่จำเป็นต้องมีสาขาเพราะคุณสามารถเล่นกลชุดการเปลี่ยนแปลงได้อย่างคล่องตัว ตัวอย่างเช่นขั้นตอนการทำงานตามปกติคือคุณซิงค์กับเวอร์ชันล่าสุดที่รู้จักบนเมนไลน์จากนั้นเขียนคุณลักษณะของคุณ เมื่อใดก็ตามที่คุณพยายามแก้ไขไฟล์ความแตกต่างของไฟล์นั้นจะถูกเพิ่มเข้าไปใน "ชุดการเปลี่ยนแปลงเริ่มต้น" ของคุณ เมื่อคุณพยายามตรวจสอบในชุดการเปลี่ยนแปลงระบบจะพยายามรวมข่าวสารจากสายหลักเข้ากับชุดการเปลี่ยนแปลงของคุณโดยอัตโนมัติ (เปลี่ยนฐานข้อมูลอย่างมีประสิทธิภาพ) แล้วจึงดำเนินการ เวิร์กโฟลว์นี้บังคับใช้โดยที่คุณไม่จำเป็นต้องเข้าใจด้วยซ้ำ Mainline จึงรวบรวมประวัติของการเปลี่ยนแปลงซึ่งคุณสามารถเลือกทางของคุณได้อย่างง่ายดายในภายหลัง ตัวอย่างเช่นสมมติว่าคุณต้องการเปลี่ยนกลับรายการเก่ากล่าวว่าก่อนหน้าก่อนสุดท้าย คุณซิงค์กับช่วงเวลาก่อนการเปลี่ยนแปลงที่ละเมิดทำเครื่องหมายไฟล์ที่ได้รับผลกระทบเป็นส่วนหนึ่งของชุดการเปลี่ยนแปลง ซิงค์กับช่วงเวลาหลังจากนั้นและรวมเข้ากับ "always mine" (มีบางอย่างที่น่าสนใจมากที่นั่น: การซิงค์ไม่ได้หมายความว่าจะมีสิ่งเดียวกัน - หากไฟล์สามารถแก้ไขได้ (เช่นในชุดการเปลี่ยนแปลงที่ใช้งานอยู่) มันจะไม่ถูกรวมโดยการซิงค์ แต่ทำเครื่องหมายว่าครบกำหนดสำหรับการแก้ไข) ตอนนี้คุณมี รายการการเปลี่ยนแปลงที่ยกเลิกรายการที่กระทำผิด รวมข่าวที่ตามมาและคุณมีรายการการเปลี่ยนแปลงที่คุณสามารถป๋อมแป๋มบนเมนไลน์เพื่อให้ได้เอฟเฟกต์ที่ต้องการ เราไม่ได้เขียนประวัติศาสตร์อะไรเลย รวมข่าวที่ตามมาและคุณมีรายการการเปลี่ยนแปลงที่คุณสามารถป๋อมแป๋มบนเมนไลน์เพื่อให้ได้เอฟเฟกต์ที่ต้องการ เราไม่ได้เขียนประวัติศาสตร์อะไรเลย รวมข่าวที่ตามมาและคุณมีรายการการเปลี่ยนแปลงที่คุณสามารถป๋อมแป๋มบนเมนไลน์เพื่อให้ได้เอฟเฟกต์ที่ต้องการ เราไม่ได้เขียนประวัติศาสตร์อะไรเลย
ตอนนี้สมมติว่าผ่านไปครึ่งทางแล้วจะมีใครบางคนวิ่งมาหาคุณและบอกให้คุณทิ้งทุกอย่างและแก้ไขข้อบกพร่องบางอย่าง คุณเพียงแค่ตั้งชื่อรายการการเปลี่ยนแปลงเริ่มต้นของคุณ (เป็นตัวเลขจริง) จากนั้น "ระงับ" แก้ไขข้อบกพร่องในรายการการเปลี่ยนแปลงเริ่มต้นที่ว่างเปล่าในขณะนี้ยอมรับและดำเนินการรายการการเปลี่ยนแปลงที่ตั้งชื่อต่อ เป็นเรื่องปกติที่จะมีการระงับรายการการเปลี่ยนแปลงหลายรายการในเวลาที่คุณลองทำสิ่งต่างๆ เป็นเรื่องง่ายและเป็นส่วนตัว คุณได้รับสิ่งที่คุณต้องการจริงๆจากระบอบการปกครองแบบสาขาโดยไม่มีสิ่งล่อใจที่จะผัดวันประกันพรุ่งหรือไก่ออกจากการรวมเข้ากับเมนไลน์
ฉันคิดว่ามันเป็นไปได้ในทางทฤษฎีที่จะทำสิ่งที่คล้ายกันในคอมไพล์ แต่คอมไพล์ทำให้ทุกอย่างเป็นไปได้จริงแทนที่จะยืนยันขั้นตอนการทำงานที่เราเห็นด้วย โมเดลแบบรวมศูนย์คือการทำให้เข้าใจง่ายที่ถูกต้องจำนวนมากซึ่งสัมพันธ์กับโมเดลแบบกระจายซึ่งเป็นลักษณะทั่วไปที่ไม่ถูกต้อง มีการใช้งานทั่วไปมากเกินไปโดยทั่วไปคาดว่าคุณจะใช้การควบคุมแหล่งที่มาที่ด้านบนเช่นเดียวกับที่ repo ทำ
สิ่งอื่นคือการจำลองแบบ ในคอมไพล์ทุกอย่างเป็นไปได้ดังนั้นคุณต้องคิดออกด้วยตัวคุณเอง ในการบังคับใช้คุณจะได้รับแคชไร้สถานะที่มีประสิทธิภาพ การกำหนดค่าเดียวที่จำเป็นต้องรู้คือตำแหน่งที่ต้นแบบอยู่และลูกค้าสามารถชี้ไปที่ต้นแบบหรือแคชได้ตามดุลยพินิจของพวกเขา นั่นเป็นงานห้านาทีและไม่ผิดพลาด
นอกจากนี้คุณยังมีทริกเกอร์และแบบฟอร์มที่ปรับแต่งได้สำหรับการยืนยันการตรวจสอบโค้ดการอ้างอิง Bugzilla และอื่น ๆ และแน่นอนคุณมีสาขาสำหรับเมื่อคุณต้องการจริงๆ ไม่ใช่เคสใส แต่อยู่ใกล้และติดตั้งและบำรุงรักษาง่าย
สรุปแล้วฉันคิดว่าถ้าคุณรู้ว่าคุณจะทำงานแบบรวมศูนย์ซึ่งทุกคนทำคุณอาจใช้เครื่องมือที่ออกแบบมาโดยคำนึงถึงสิ่งนั้นด้วย Git ถูก overrated เนื่องจากความฉลาดที่น่ากลัวของ Linus พร้อมกับแนวโน้มของผู้คนที่จะติดตามซึ่งกันและกันเหมือนแกะ แต่ raison d'etre หลักของมันไม่ได้ยืนหยัดกับสามัญสำนึกและด้วยการทำตาม git ผูกมือของตัวเองด้วย ความเชื่อที่ยิ่งใหญ่สองประการที่ (ก) ซอฟต์แวร์และ (ข) ข้อมูลต้องเหมือนกันทั้งในไคลเอนต์และเซิร์ฟเวอร์และนั่นจะทำให้มันซับซ้อนและง่อยอยู่เสมอในงานที่รวมศูนย์
การใช้ GIT แทนการจัดการบรรทัดโค้ดที่ไม่ดีเป็นเรื่องปกติ ข้อเสียหลายประการของ Perforce เป็นผลมาจากกลยุทธ์การแตกแขนงที่ไม่ดี เช่นเดียวกับเครื่องมือจากส่วนกลางอื่น ๆ หากคุณต้องสร้างกิ่งก้านจำนวนมากแสดงว่าคุณกำลังทำอะไรผิดพลาด ทำไมนักพัฒนาถึงต้องสร้างสาขามากมาย?
นอกจากนี้เหตุใดการตัดการเชื่อมต่อจึงมีความสำคัญต่อไป เพื่อให้ใครบางคนสามารถทำงานบนรถไฟ? นั่นเป็นสถานที่เดียวในทุกวันนี้ที่คุณไม่สามารถเชื่อมต่อไร้สายได้ และแม้แต่รถไฟส่วนใหญ่ก็มี WiFi ที่ดี