ฉันใช้Subversionมาสองสามปีแล้วหลังจากใช้SourceSafeฉันก็รัก Subversion เมื่อรวมกับTortoiseSVNฉันไม่สามารถจินตนาการได้ว่ามันจะดีขึ้นได้อย่างไร
แต่มีจำนวนที่เพิ่มขึ้นของนักพัฒนาอ้างว่าการโค่นล้มมีปัญหาและที่เราควรจะย้ายไปอยู่ที่สายพันธุ์ใหม่ของระบบการควบคุมการกระจายรุ่นเช่นGit
Git ปรับปรุงให้ดีขึ้นอย่างไรเมื่อการโค่นล้ม
คำตอบ:
Git นั้นไม่ดีไปกว่าการโค่นล้ม แต่ก็ไม่ได้เลวร้ายยิ่งกว่า มันแตกต่าง.
ความแตกต่างที่สำคัญคือมันมีการกระจายอำนาจ ลองนึกภาพคุณเป็นนักพัฒนาบนท้องถนนคุณพัฒนาบนแล็ปท็อปของคุณและคุณต้องการควบคุมแหล่งที่มาเพื่อให้คุณสามารถย้อนกลับไปได้ 3 ชั่วโมง
ด้วยการโค่นล้มคุณมีปัญหา: ที่เก็บ SVN อาจอยู่ในตำแหน่งที่คุณไม่สามารถเข้าถึงได้ (ใน บริษัท ของคุณและคุณไม่มีอินเทอร์เน็ตในขณะนี้) คุณไม่สามารถกระทำได้ หากคุณต้องการทำสำเนารหัสคุณต้องคัดลอก / วางอย่างแท้จริง
ด้วย Git คุณไม่มีปัญหานี้ สำเนาโลคัลของคุณเป็นที่เก็บและคุณสามารถคอมมิตและรับประโยชน์ทั้งหมดของการควบคุมซอร์ส เมื่อคุณได้รับการเชื่อมต่อไปยังแหล่งเก็บข้อมูลหลักคุณสามารถยืนยันได้
สิ่งนี้ดูดีในตอนแรก แต่โปรดคำนึงถึงความซับซ้อนที่เพิ่มขึ้นของวิธีการนี้
ดูเหมือนว่า Git จะเป็น "สิ่งใหม่เงางาม" มันไม่ได้เลวร้ายอะไร (มีเหตุผลที่ไลนัสเขียนไว้สำหรับการพัฒนาเคอร์เนลลินุกซ์) แต่ฉันรู้สึกว่าหลาย ๆ คนกระโดดขึ้นรถไฟ "Distributed Source Control" เพียงเพราะมันใหม่และเขียนโดย Linus Torvalds โดยที่จริงแล้ว รู้ว่าทำไม / ถ้ามันจะดีกว่า
การโค่นล้มมีปัญหา แต่ Git, Mercurial, CVS, TFS หรืออะไรก็ตาม
แก้ไข:ดังนั้นคำตอบนี้มีอายุหนึ่งปีและยังสร้าง upvotes จำนวนมากดังนั้นฉันคิดว่าฉันจะเพิ่มคำอธิบายเพิ่มเติม ในปีที่แล้วนับตั้งแต่เขียนสิ่งนี้ Git ได้รับแรงผลักดันและการสนับสนุนเป็นจำนวนมากโดยเฉพาะอย่างยิ่งเมื่อไซต์ต่างๆอย่าง GitHub ถูกถอดออกจริงๆ ฉันใช้ Git และ Subversion ทุกวันนี้และฉันต้องการแบ่งปันข้อมูลเชิงลึกส่วนตัว
ก่อนอื่น Git อาจสร้างความสับสนในตอนแรกเมื่อมีการกระจายอำนาจการทำงาน รีโมตคืออะไร และวิธีการตั้งค่าพื้นที่เก็บข้อมูลเริ่มต้นอย่างถูกต้อง? เป็นคำถามสองข้อที่เกิดขึ้นที่จุดเริ่มต้นโดยเฉพาะอย่างยิ่งเมื่อเทียบกับ "svnadmin create" แบบง่าย ๆ ของ SVN, "git init" ของ Git สามารถใช้พารามิเตอร์ได้ - การแบ่งปันและ - แชร์ซึ่งดูเหมือนจะเป็นวิธีที่ "เหมาะสม" ในการตั้งค่าส่วนกลาง กรุ มีเหตุผลสำหรับสิ่งนี้ แต่เพิ่มความซับซ้อน เอกสารของคำสั่ง "checkout" นั้นสร้างความสับสนให้กับผู้คนที่เปลี่ยนไปมาก - วิธีที่ "เหมาะสม" ดูเหมือนจะเป็น "git clone" ในขณะที่ "checkout git" ดูเหมือนจะเปลี่ยนสาขา
Git ส่องแสงเมื่อคุณกระจายอำนาจ ฉันมีเซิร์ฟเวอร์ที่บ้านและแล็ปท็อปบนท้องถนนและ SVN ก็ทำงานได้ไม่ดีที่นี่ ด้วย SVN ฉันไม่สามารถควบคุมแหล่งข้อมูลท้องถิ่นได้หากฉันไม่ได้เชื่อมต่อกับที่เก็บข้อมูล (ใช่ฉันรู้เกี่ยวกับ SVK หรือวิธีคัดลอก repo) ด้วย Git นั่นคือโหมดเริ่มต้น มันเป็นคำสั่งพิเศษแม้ว่า (คอมไพล์คอมมิทกระทำการโลคัลในขณะที่ git push origin origin พุชสาขาหลักไปยังรีโมตชื่อ "origin")
ดังที่ได้กล่าวไว้ข้างต้น: Git เพิ่มความซับซ้อน สองวิธีในการสร้างที่เก็บข้อมูล, เช็กเอาต์กับโคลน, คอมมิชชันและพุช ... คุณต้องรู้ว่าคำสั่งใดที่ทำงานในพื้นที่และทำงานกับ "เซิร์ฟเวอร์" (ฉันสมมติว่าคนส่วนใหญ่ยังคงเหมือนศูนย์กลาง "master-repository") )
นอกจากนี้เครื่องมือยังไม่เพียงพออย่างน้อยใน Windows ใช่มี Visual Studio AddIn แต่ฉันยังใช้ git bash กับ msysgit
SVN มีข้อได้เปรียบที่ง่ายต่อการเรียนรู้มาก: มีพื้นที่เก็บข้อมูลของคุณการเปลี่ยนแปลงทั้งหมดที่มีต่อหากคุณรู้วิธีสร้างคอมมิทและชำระเงินและคุณพร้อมที่จะไป บน.
Git มีข้อได้เปรียบที่ว่าจะเหมาะกว่าหากนักพัฒนาบางคนไม่ได้เชื่อมต่อกับที่เก็บข้อมูลหลักเสมอไป นอกจากนี้มันเร็วกว่า SVN มาก และจากสิ่งที่ฉันได้ยินการสนับสนุนจากการรวมสาขาและการรวมกันนั้นดีกว่ามาก (ซึ่งคาดว่าจะเป็นเพราะนี่คือเหตุผลหลักที่เขียน)
สิ่งนี้อธิบายได้ด้วยว่าทำไมมันจึงได้รับความนิยมอย่างมากบนอินเทอร์เน็ตเนื่องจาก Git เหมาะอย่างยิ่งสำหรับโครงการโอเพ่นซอร์ส: เพียงแค่แยกมันกระทำการเปลี่ยนแปลงของคุณกับทางแยกของคุณแล้วขอให้ผู้ดูแลโครงการดั้งเดิมดึงการเปลี่ยนแปลงของคุณ ด้วย Git นี่ใช้งานได้ ลองใช้ Github จริง ๆ มันเป็นเวทย์มนตร์
สิ่งที่ฉันเห็นก็คือ Git-SVN Bridges: ที่เก็บส่วนกลางเป็น repo ที่ถูกโค่นล้ม แต่นักพัฒนาทำงานกับ Git และบริดจ์จากนั้นจึงผลักการเปลี่ยนแปลงของพวกเขาไปยัง SVN
แต่ถึงแม้จะมีการเพิ่มความยาวนี้ฉันยังคงยืนหยัดอยู่กับข้อความหลักของฉัน: Git ไม่ดีขึ้นหรือแย่ลงมันแตกต่างกัน หากคุณมีความต้องการ "การควบคุมแหล่งออฟไลน์" และความเต็มใจที่จะใช้เวลาเรียนรู้เพิ่มเติมมันยอดเยี่ยมมาก แต่ถ้าคุณมีการควบคุมแหล่งที่มาจากศูนย์กลางอย่างเคร่งครัดและ / หรือกำลังดิ้นรนที่จะแนะนำการควบคุมแหล่งที่มาตั้งแต่แรกเพราะเพื่อนร่วมงานของคุณไม่สนใจดังนั้นความเรียบง่ายและเครื่องมือที่ยอดเยี่ยม (อย่างน้อยใน Windows) ของ SVN
ด้วย Git คุณสามารถทำอะไรที่ออฟไลน์ได้เพราะทุกคนมีที่เก็บของตนเอง
การทำให้สาขาและการรวมระหว่างสาขาเป็นเรื่องง่าย
แม้ว่าคุณจะไม่มีสิทธิ์ในการทำโปรเจค แต่คุณยังสามารถมีที่เก็บข้อมูลของคุณทางออนไลน์และเผยแพร่ "คำขอพุช" สำหรับแพตช์ของคุณ ทุกคนที่ชอบแพทช์ของคุณสามารถดึงพวกเขาเข้าสู่โครงการรวมถึงผู้ดูแลอย่างเป็นทางการ
มันเป็นเรื่องง่ายที่จะแยกโครงการแก้ไขและยังคงรวมอยู่ในการแก้ไขข้อบกพร่องจากสาขา HEAD
Git ใช้ได้กับนักพัฒนาเคอร์เนล Linux ซึ่งหมายความว่ามันเร็วมาก (ต้องเป็น) และปรับให้เข้ากับผู้มีส่วนร่วมนับพัน Git ยังใช้พื้นที่น้อยกว่า (พื้นที่น้อยกว่าถึง 30 เท่าสำหรับที่เก็บ Mozilla)
Git นั้นมีความยืดหยุ่นมาก TIMTOWTDI (มีมากกว่าหนึ่งวิธีในการทำ) คุณสามารถใช้เวิร์กโฟลว์ใดก็ได้ที่คุณต้องการและ Git จะให้การสนับสนุน
ในที่สุดก็มีGitHubซึ่งเป็นเว็บไซต์ที่ยอดเยี่ยมสำหรับการโฮสต์ที่เก็บ Git ของคุณ
ข้อเสียของ Git:
คำตอบอื่น ๆ ทำได้ดีในการอธิบายคุณสมบัติหลักของ Git (ซึ่งยอดเยี่ยม) แต่ก็มีวิธีเล็ก ๆ น้อย ๆมากมายที่ Git ทำงานได้ดีขึ้นและช่วยให้ชีวิตฉันมีสติมากขึ้น นี่คือบางสิ่งเล็ก ๆ น้อย ๆ :
git mv git rm
" ทำไม Git ดีกว่า X " แสดงข้อดีและข้อเสียต่าง ๆ ของ Git เทียบกับ SCM อื่น ๆ
สั้น ๆ :
มีข้อเสียบางประการ:
ในการใช้งานที่ง่ายที่สุดการโค่นล้มและ Git ก็เหมือนกันมาก ไม่มีความแตกต่างระหว่าง:
svn checkout svn://foo.com/bar bar
cd bar
# edit
svn commit -m "foo"
และ
git clone git@github.com:foo/bar.git
cd bar
# edit
git commit -a -m "foo"
git push
สถานที่ที่ Git เปล่งประกายนั้นแตกแขนงและทำงานร่วมกับผู้อื่น
Google Tech Talk: Linus Torvalds บนคอมไพล์
http://www.youtube.com/watch?v=4XpnKHJAok8
หน้าเปรียบเทียบของ Git Wiki
มันกระจายกันอยู่ เกณฑ์มาตรฐานบ่งชี้ว่ามันเร็วกว่ามาก (เนื่องจากลักษณะการกระจายของมันการดำเนินการต่าง ๆ และบันทึกต่างก็เป็นแบบโลคัลดังนั้นแน่นอนว่ามันจะเร็วกว่าอย่างเห็นได้ชัดในกรณีนี้) และโฟลเดอร์การทำงานมีขนาดเล็กกว่า
เมื่อคุณทำงานเกี่ยวกับการโค่นล้มหรือระบบควบคุมการแก้ไขไคลเอ็นต์ / เซิร์ฟเวอร์อื่น ๆ คุณจะต้องสร้างสำเนาการทำงานบนเครื่องของคุณโดยการตรวจสอบการแก้ไข สิ่งนี้แสดงภาพรวมในเวลาที่ที่เก็บดูเหมือน คุณอัปเดตสำเนาการทำงานของคุณผ่านการอัปเดตและคุณอัปเดตที่เก็บข้อมูลผ่านทางคอมมิท
ด้วยการควบคุมเวอร์ชันแบบกระจายคุณไม่มีสแนปชอต แต่เป็นรหัสฐานทั้งหมด อยากจะแตกต่างกับเวอร์ชั่นเก่า 3 เดือนหรือไม่? ไม่มีปัญหาเวอร์ชันเก่า 3 เดือนยังคงอยู่ในคอมพิวเตอร์ของคุณ นี่ไม่ได้หมายความว่าสิ่งต่าง ๆ จะเร็วขึ้น แต่หากคุณตัดการเชื่อมต่อจากเซิร์ฟเวอร์กลางของคุณคุณยังสามารถดำเนินการต่างๆที่คุณคุ้นเคยได้ คุณไม่เพียง แต่มีสแนปชอตของการแก้ไขที่กำหนด แต่เป็น codebase ทั้งหมด
คุณคิดว่า Git จะใช้พื้นที่บนฮาร์ดไดรฟ์เป็นจำนวนมาก แต่จากการวัดประสิทธิภาพที่ฉันเคยเห็นมันใช้เวลาน้อยลง อย่าถามฉันได้อย่างไร ฉันหมายถึงมันถูกสร้างโดย Linus เขารู้เรื่องหนึ่งหรือสองเรื่องเกี่ยวกับระบบไฟล์ที่ฉันเดา
ประเด็นหลักที่ฉันชอบเกี่ยวกับ DVCS คือ:
เหตุผลหลักสำหรับโครงการที่ค่อนข้างใหญ่คือการสื่อสารที่พัฒนาขึ้นโดยจุดที่ 3 อื่น ๆ เป็นโบนัสที่ดี
สิ่งที่ตลกคือ: ฉันโฮสต์โครงการใน Subversion Repos แต่เข้าถึงได้ผ่านคำสั่ง Git Clone
โปรดอ่านพัฒนาด้วย Git ในโครงการ Google Code
ถึงแม้ว่า Google Code จะพูดถึงการโค่นล้ม แต่คุณสามารถใช้ Git ระหว่างการพัฒนาได้อย่างง่ายดาย การค้นหา "git svn" แสดงให้เห็นการปฏิบัตินี้แพร่หลายและเราก็สนับสนุนให้คุณทดลองด้วยเช่นกัน
การใช้ Git บน Svn Repository ให้ประโยชน์แก่ฉัน:
backup/publicให้ผู้อื่นลองดูคำตอบทั้งหมดที่นี่เป็นไปตามที่คาดไว้โปรแกรมเมอร์เป็นศูนย์กลาง แต่จะเกิดอะไรขึ้นหาก บริษัท ของคุณใช้การควบคุมการแก้ไขนอกซอร์สโค้ด มีเอกสารจำนวนมากที่ไม่ได้ซอร์สโค้ดซึ่งได้รับประโยชน์จากการควบคุมเวอร์ชันและควรอยู่ใกล้กับโค้ดไม่ใช่ใน CMS อื่น โปรแกรมเมอร์ส่วนใหญ่ไม่ทำงานอย่างโดดเดี่ยว - เราทำงานให้กับ บริษัท ในฐานะส่วนหนึ่งของทีม
เปรียบเทียบกับความง่ายในการใช้เครื่องมือและการฝึกอบรมของลูกค้าระหว่างการโค่นล้มและ git ฉันไม่เห็นสถานการณ์ที่ระบบควบคุมการแก้ไขแบบกระจายใด ๆจะใช้งานได้ง่ายขึ้นหรืออธิบายให้ผู้ที่ไม่ใช่โปรแกรมเมอร์ ฉันชอบที่จะพิสูจน์ว่าผิดเพราะจากนั้นฉันสามารถประเมินคอมไพล์และจริง ๆ แล้วมีความหวังว่าจะได้รับการยอมรับจากผู้ที่ต้องการการควบคุมเวอร์ชันที่ไม่ใช่โปรแกรมเมอร์
ถึงแม้ว่าถ้าผู้บริหารถามว่าทำไมเราควรย้ายจากส่วนกลางเป็นระบบควบคุมการแก้ไขแบบกระจายฉันก็ยากที่จะให้คำตอบที่ตรงไปตรงมาเพราะเราไม่ต้องการมัน
ข้อจำกัดความรับผิดชอบ: ฉันเริ่มสนใจการโค่นล้มในช่วงต้น (ประมาณ v0.29) ดังนั้นเห็นได้ชัดว่าฉันลำเอียง แต่ บริษัท ที่ฉันทำงานมาตั้งแต่ครั้งนั้นได้รับประโยชน์จากความกระตือรือร้นของฉันเพราะฉันได้รับการสนับสนุนและสนับสนุนการใช้งาน ฉันสงสัยว่านี่เป็นสิ่งที่เกิดขึ้นกับ บริษัท ซอฟต์แวร์ส่วนใหญ่ ด้วยโปรแกรมเมอร์จำนวนมากกระโดดบน bandwagon git ฉันสงสัยว่ามีกี่ บริษัท ที่จะพลาดประโยชน์ของการใช้การควบคุมเวอร์ชันนอกซอร์สโค้ด? แม้ว่าคุณจะมีระบบแยกต่างหากสำหรับทีมที่แตกต่างกันคุณก็พลาดประโยชน์บางประการเช่นการรวมการติดตามปัญหา (รวม) ในขณะที่เพิ่มการบำรุงรักษาฮาร์ดแวร์และข้อกำหนดการฝึกอบรม
การโค่นล้มยังคงเป็นระบบควบคุมเวอร์ชันที่ใช้กันอย่างแพร่หลายซึ่งหมายความว่ามีการสนับสนุนเครื่องมือที่ดีกว่า คุณจะพบปลั๊กอิน SVN ที่เป็นผู้ใหญ่สำหรับเกือบทุกIDEและมีส่วนขยาย explorer ที่ดี (เช่น TurtoiseSVN) นอกจากนั้นฉันจะต้องเห็นด้วยกับไมเคิล : Git ไม่ได้ดีไปกว่าการโค่นล้มหรือแตกต่าง
หนึ่งในสิ่งที่เกี่ยวกับ SubVersion ที่ทำให้ฉันรู้สึกแย่คือมันใส่โฟลเดอร์ของตัวเองในแต่ละไดเรกทอรีของโครงการในขณะที่ git ใส่เพียงหนึ่งในไดเรกทอรีราก มันไม่ได้ว่าใหญ่ของการจัดการ แต่สิ่งเล็ก ๆ น้อยที่ต้องการที่เพิ่มขึ้น
แน่นอนว่า SubVersion มี Tortoise ซึ่งดีมาก [ปกติ]
David Richards WANdisco Blog เกี่ยวกับการโค่นล้ม / GIT
การเกิดขึ้นของ GIT ได้นำสายพันธุ์พื้นฐานของ DVCS ซึ่งเรียกว่า 'Gitterons' ซึ่งคิดว่าสิ่งอื่นใดนอกจาก GIT นั้นเป็นเรื่องไร้สาระ The Gitterons ดูเหมือนจะคิดว่าวิศวกรรมซอฟต์แวร์เกิดขึ้นบนเกาะของตนเองและมักจะลืมว่าองค์กรส่วนใหญ่ไม่ได้ว่าจ้างวิศวกรซอฟต์แวร์อาวุโส ไม่เป็นไร แต่ตลาดส่วนที่เหลือคิดว่าและฉันยินดีที่จะพิสูจน์: GIT ที่ดูล่าสุดมีน้อยกว่าร้อยละสามของตลาดในขณะที่การโค่นล้มมีผู้ใช้ห้าล้านคนและประมาณครึ่งหนึ่งของ ตลาดโดยรวม
ปัญหาที่เราเห็นคือ Gitterons ถูกยิง (ราคาถูก) ที่ Subversion ทวีตเช่น“ การโค่นล้มเป็นอย่างนั้น [ช้า / เส็งเคร็ง / จำกัด / ไม่ได้กลิ่นดี / มองฉันด้วยวิธีที่ตลก] และตอนนี้ฉันมี GIT และ [ทุกอย่างทำงานในชีวิตของฉัน / ภรรยาของฉันท้อง / ฉันมีแฟนหลังจาก 30 ปีแห่งความพยายาม / ฉันชนะการวิ่งบนโต๊ะแบล็คแจ็คถึงหกครั้ง] คุณได้รับรูปภาพ
Git ยังทำให้การแยกและรวมเข้าด้วยกันเป็นเรื่องง่าย การโค่นล้ม 1.5 เพิ่งเพิ่มการติดตามการผสาน แต่ Git ยังดีกว่า ด้วยการแยก Git รวดเร็วและราคาถูกมาก มันทำให้การสร้างสาขาสำหรับคุณสมบัติใหม่แต่ละรายการเป็นไปได้มากขึ้น พื้นที่เก็บข้อมูลของ Oh และ Git นั้นมีประสิทธิภาพมากพร้อมพื้นที่เก็บข้อมูลเมื่อเทียบกับ Subversion
ทุกอย่างเกี่ยวกับความง่ายในการใช้งาน / ขั้นตอนที่จำเป็นในการทำบางสิ่ง
ถ้าฉันกำลังพัฒนาโครงการเดียวบนพีซี / แล็ปท็อปของฉันคอมไพล์จะดีกว่าเพราะง่ายต่อการติดตั้งและใช้งาน คุณไม่จำเป็นต้องใช้เซิร์ฟเวอร์และคุณไม่จำเป็นต้องพิมพ์ URL ที่เก็บไว้ในเมื่อคุณทำการผสาน
ถ้าเป็นแค่ 2 คนฉันจะบอกว่าคอมไพล์ก็ง่ายขึ้นเพราะคุณสามารถผลักและดึงจากคนอื่นได้
เมื่อคุณได้รับมากกว่านั้นฉันจะไปโค่นล้มเพราะ ณ จุดนั้นคุณต้องตั้งค่าเซิร์ฟเวอร์หรือสถานที่ 'โดยเฉพาะ'
คุณสามารถทำสิ่งนี้ได้เช่นกันกับ git เช่นเดียวกับ SVN แต่ประโยชน์ของ git นั้นเกินดุลโดยจำเป็นต้องทำตามขั้นตอนเพิ่มเติมเพื่อซิงค์กับเซิร์ฟเวอร์กลาง ใน SVN คุณเพิ่งจะคอมมิท ในคอมไพล์คุณต้องคอมไพล์คอมมิตแล้วกดคอมไพล์ ขั้นตอนเพิ่มเติมที่น่ารำคาญเพียงเพราะคุณทำมันมาก
SVN ยังได้ประโยชน์จากเครื่องมือ GUI ที่ดีกว่า แต่ระบบนิเวศ git ดูเหมือนว่าจะเร็วขึ้นดังนั้นฉันจะไม่กังวลเกี่ยวกับเรื่องนี้ในระยะยาว
Easy Gitมีหน้าเว็บที่ดีเมื่อเปรียบเทียบการใช้งานจริงของGit และ SVNซึ่งจะทำให้คุณทราบว่า Git สามารถทำอะไรได้บ้าง (หรือทำได้ง่ายขึ้น) เมื่อเทียบกับ SVN (โดยทางเทคนิคแล้วนี่เป็นพื้นฐานของ Easy Git ซึ่งเป็นเสื้อคลุมน้ำหนักเบาที่ด้านบนของ Git)
โดยทั่วไป Git และ DVCS นั้นยอดเยี่ยมสำหรับนักพัฒนาที่ทำโค้ดจำนวนมากเป็นอิสระจากกันเพราะทุกคนมีสาขาของตัวเอง แต่ถ้าคุณต้องการการเปลี่ยนแปลงจากคนอื่นเธอจะต้องมอบความไว้วางใจให้กับ repo ในพื้นที่ของเธอจากนั้นเธอจะต้องผลักดันเซ็ตการแก้ไขนั้นให้คุณหรือคุณต้องดึงมันจากเธอ
เหตุผลของฉันเองก็ทำให้ฉันคิดว่า DVCS ทำให้สิ่งที่ยากขึ้นสำหรับการประกันคุณภาพและการจัดการการปล่อยถ้าคุณทำสิ่งต่าง ๆ เช่นการเผยแพร่จากส่วนกลาง ใครบางคนจะต้องรับผิดชอบในการทำแบบผลัก / ดึงจากพื้นที่เก็บข้อมูลของคนอื่นแก้ไขความขัดแย้งใด ๆ ที่จะได้รับการแก้ไขในช่วงต้นกระทำก่อนหน้านี้จากนั้นทำการสร้างและจากนั้นให้นักพัฒนาคนอื่น ๆ
ทั้งหมดนี้สามารถแก้ไขได้ด้วยกระบวนการของมนุษย์แน่นอน DVCS เพิ่งทำลายสิ่งที่ได้รับการแก้ไขโดยการควบคุมเวอร์ชันรวมศูนย์เพื่อให้สิ่งอำนวยความสะดวกใหม่ ๆ
ฉันชอบ Git เพราะจริง ๆ แล้วมันช่วยให้นักพัฒนาการสื่อสารกับนักพัฒนาในทีมขนาดกลางถึงใหญ่ ในฐานะที่เป็นระบบควบคุมเวอร์ชันแบบกระจายผ่านระบบ push / pull มันช่วยให้นักพัฒนาสามารถสร้างซอร์สโค้ดระบบนิเวศซึ่งช่วยในการจัดการกลุ่มนักพัฒนาขนาดใหญ่ที่ทำงานในโครงการเดียว
ตัวอย่างเช่นสมมติว่าคุณไว้วางใจนักพัฒนา 5 คนและดึงรหัสจากที่เก็บของพวกเขาเท่านั้น นักพัฒนาแต่ละคนนั้นมีเครือข่ายที่ไว้ใจได้จากที่ที่พวกเขาดึงรหัส ดังนั้นการพัฒนาจึงขึ้นอยู่กับโครงสร้างความน่าเชื่อถือของนักพัฒนาที่มีการแบ่งปันความรับผิดชอบของรหัสในชุมชนการพัฒนา
แน่นอนมีประโยชน์อื่น ๆ ที่กล่าวถึงในคำตอบอื่น ๆ ที่นี่
คำตอบสองสามข้อได้พาดพิงถึงสิ่งเหล่านี้ แต่ฉันต้องการทำให้ 2 ประเด็นชัดเจน:
1) ความสามารถในการเลือกกระทำ (ตัวอย่างเช่น git add --patch ) หากไดเรกทอรีการทำงานของคุณมีการเปลี่ยนแปลงหลายอย่างที่ไม่ได้เป็นส่วนหนึ่งของการเปลี่ยนแปลงเชิงตรรกะที่เหมือนกัน Git ทำให้การคอมมิตเป็นเรื่องง่ายมากที่รวมการเปลี่ยนแปลงเพียงส่วนหนึ่ง ด้วยการโค่นล้มมันเป็นเรื่องยาก
2) ความสามารถในการกระทำโดยไม่ต้องทำการเปลี่ยนแปลงสู่สาธารณะ ในการโค่นล้มการกระทำใด ๆ จะเปิดเผยต่อสาธารณชนในทันทีและไม่สามารถเพิกถอนได้ สิ่งนี้จำกัดความสามารถของผู้พัฒนาในการ "กระทำก่อนกำหนดส่งบ่อย"
Git เป็นมากกว่า VCS มันยังเป็นเครื่องมือสำหรับการพัฒนาแพตช์ การโค่นล้มเป็นเพียง VCS
ฉันคิดว่าการโค่นล้มเป็นเรื่องปกติ .. จนกว่าคุณจะเริ่มผสาน .. หรือทำสิ่งที่ซับซ้อน .. หรือทำสิ่งใดก็ตามการโค่นล้มคิดว่ามีความซับซ้อน (เช่นการทำแบบสอบถามเพื่อค้นหาว่าสาขาใดยุ่งกับไฟล์โดยเฉพาะซึ่งการเปลี่ยนแปลงนั้นมาจาก ฯลฯ ) ...
ฉันไม่เห็นด้วยกับคำตอบที่ชนะโดยบอกว่าประโยชน์หลักของ GIT คือการทำงานแบบออฟไลน์ - มันมีประโยชน์อย่างแน่นอน แต่มันก็เป็นสิ่งที่พิเศษสำหรับกรณีการใช้งานของฉัน SVK สามารถทำงานออฟไลน์ได้เช่นกัน แต่ก็ไม่มีคำถามใดสำหรับฉันที่จะใช้เวลาในการเรียนรู้ของฉัน)
มันเป็นเพียงแค่ว่ามันทรงพลังและรวดเร็วอย่างไม่น่าเชื่อและหลังจากนั้นทำความคุ้นเคยกับแนวคิด - มีประโยชน์มาก (ใช่ในแง่นั้น: ใช้งานง่าย)
สำหรับรายละเอียดเพิ่มเติมเกี่ยวกับเรื่องราวการรวมดูที่: ใช้ git-svn (หรือคล้ายกัน) * เพียง * เพื่อช่วยในการรวม svn?
ด้วยความจริงที่ว่ามันไม่จำเป็นต้องสื่อสารกับเซิร์ฟเวอร์กลางอย่างต่อเนื่องทำให้ทุกคำสั่งทำงานในเวลาไม่ถึงหนึ่งวินาที (เห็นได้ชัดว่า push / pull / fetch git นั้นช้าลงเพียงเพราะพวกเขาต้องเชื่อมต่อกับ SSH) การแตกแขนงนั้นง่ายกว่ามาก (คำสั่งง่าย ๆ ในการแยกสาขาคำสั่งง่าย ๆ สำหรับการรวม)
ฉันชอบที่จะสามารถจัดการสาขาในท้องถิ่นของซอร์สโค้ดของฉันใน Git ได้โดยไม่ต้องยุ่งกับน้ำในพื้นที่เก็บข้อมูลส่วนกลาง ในหลายกรณีฉันจะเช็คเอาต์รหัสจากเซิร์ฟเวอร์การโค่นล้มและเรียกใช้พื้นที่เก็บข้อมูล Git ท้องถิ่นเพื่อให้สามารถทำสิ่งนี้ได้ นอกจากนี้ยังเป็นเรื่องดีที่การเริ่มต้นพื้นที่เก็บข้อมูล Git ไม่ก่อให้เกิดมลพิษกับระบบไฟล์ด้วยโฟลเดอร์. svn ที่น่ารำคาญทุกที่
และเท่าที่การสนับสนุนเครื่องมือของ Windows TortoiseGit จัดการพื้นฐานได้เป็นอย่างดี แต่ฉันยังคงต้องการบรรทัดคำสั่งยกเว้นว่าฉันต้องการดูบันทึก ฉันชอบวิธีที่ Tortoise {Git | SVN} ช่วยเมื่ออ่านการส่งบันทึก
นี่เป็นคำถามที่ผิดที่ต้องถาม ทุกอย่างง่ายเกินไปที่จะมุ่งเน้นไปที่หูดของ git และกำหนดข้อโต้แย้งเกี่ยวกับสาเหตุที่การโค่นล้มนั้นดีกว่าอย่างเห็นได้ชัดอย่างน้อยในบางกรณีการใช้งาน ความจริงที่ว่าคอมไพล์ได้รับการออกแบบมาเป็นชุดโครงสร้างการควบคุมเวอร์ชันต่ำและมีอินเทอร์เฟซที่มุ่งเน้นนักพัฒนาลินุกซ์พิสดารทำให้มันง่ายขึ้นสำหรับสงครามศักดิ์สิทธิ์ที่จะได้รับแรงฉุดและรับรู้ถึงความชอบธรรม ผู้เสนอ Git ตีกลองด้วยข้อได้เปรียบเวิร์กโฟลว์หลายล้านครั้งซึ่งผู้คนอ้างว่าไม่จำเป็น ในไม่ช้าการอภิปรายทั้งหมดจะถูกวางกรอบเป็นแบบรวมศูนย์และแบบกระจายซึ่งทำหน้าที่ประโยชน์ของชุมชนเครื่องมือระดับองค์กร บริษัท เหล่านี้ซึ่งมักจะเขียนบทความที่น่าเชื่อถือที่สุดเกี่ยวกับความเหนือกว่าของการโค่นล้มในองค์กร
แต่นี่คือปัญหา: การโค่นล้มเป็นสถาปัตยกรรมตายสิ้น
ในขณะที่คุณสามารถใช้คอมไพล์และสร้างการโค่นล้มการแทนที่แบบรวมศูนย์ได้อย่างง่ายดายแม้จะอยู่นานกว่าสองเท่า svn ที่ยาวนานไม่เคยได้รับการติดตามการผสานขั้นพื้นฐานที่ทำงานได้ทุกที่ที่อยู่ใกล้เคียงเช่นเดียวกับคอมไพล์ เหตุผลพื้นฐานข้อหนึ่งสำหรับเรื่องนี้คือการตัดสินใจออกแบบเพื่อทำให้สาขาเหมือนกับไดเรกทอรี ฉันไม่รู้ว่าทำไมพวกเขาถึงทำแบบนี้ แต่แรกเริ่มทำให้การชำระเงินบางส่วนง่ายมากอย่างแน่นอน น่าเสียดายที่มันยังทำให้ไม่สามารถติดตามประวัติได้อย่างถูกต้อง ตอนนี้เห็นได้ชัดว่าคุณควรจะใช้แบบแผนการจัดเก็บ subversion เพื่อแยกสาขาจากไดเรกทอรีปกติและ svn ใช้การวิเคราะห์พฤติกรรมบางอย่างเพื่อให้สิ่งต่าง ๆ ทำงานในกรณีการใช้ชีวิตประจำวัน แต่ทั้งหมดนี้เป็นเพียงแค่กระดาษผ่านการตัดสินใจที่ไม่ดีและ จำกัด การออกแบบระดับต่ำ ความสามารถในการทำ repository-wise diff (แทนที่จะเป็น directory-wise diff) เป็นฟังก์ชั่นพื้นฐานและที่สำคัญสำหรับระบบควบคุมเวอร์ชันและทำให้ internals ง่ายขึ้นมากทำให้สามารถสร้างคุณสมบัติที่ชาญฉลาดและมีประโยชน์อยู่ด้านบน คุณสามารถเห็นจำนวนของความพยายามที่ถูกนำมาใช้เพื่อขยายการโค่นล้มและยังห่างจากมันไปไกลแค่ไหนจากการปลูกพืชปัจจุบันของ VCSes ที่ทันสมัยในแง่ของการดำเนินงานขั้นพื้นฐานเช่นการรวมการแก้ไข
ตอนนี้นี่คือคำแนะนำจากใจและไม่เชื่อเรื่องพระเจ้าของฉันสำหรับใครก็ตามที่ยังเชื่อว่าการโค่นล้มนั้นดีพอสำหรับอนาคตอันใกล้:
การโค่นล้มจะไม่ไล่ตามสายพันธุ์ใหม่ของ VCSes ที่เรียนรู้จากความผิดพลาดของ RCS และ CVS มันเป็นไปไม่ได้ทางเทคนิคเว้นแต่ว่าพวกเขาจะดัดแปลงรูปแบบพื้นที่เก็บข้อมูลจากพื้นดินขึ้นมา แต่แล้วมันจะไม่เป็นจริงหรือไม่ ไม่ว่าคุณจะคิดว่าคุณไม่มีความสามารถของ VCS ที่ทันสมัยมากแค่ไหนความไม่รู้ของคุณจะไม่ปกป้องคุณจากข้อผิดพลาดของการโค่นล้มซึ่งส่วนใหญ่เป็นสถานการณ์ที่เป็นไปไม่ได้หรือแก้ไขได้ง่ายในระบบอื่น
มันหายากอย่างยิ่งที่ความด้อยกว่าทางเทคนิคของการแก้ปัญหานั้นชัดเจนเช่นเดียวกับ svn แน่นอนฉันจะไม่พูดถึงความคิดเห็นเกี่ยวกับ win-vs-linux หรือ emacs-vs-vi แต่ในกรณีนี้มันเป็นเช่นนั้น clearcut และการควบคุมแหล่งข้อมูลเป็นเครื่องมือพื้นฐานในคลังแสงของผู้พัฒนาซึ่งฉันรู้สึกว่ามันต้องมีการกล่าวถึงอย่างชัดเจน ไม่คำนึงถึงความต้องการที่จะใช้ svn ด้วยเหตุผลด้านองค์กรฉันขอร้องให้ผู้ใช้ svn ทุกคนไม่ให้เหตุผลเชิงตรรกะของพวกเขาสร้างความเชื่อที่ผิด ๆ ว่า VCSes ที่ทันสมัยกว่ามีประโยชน์สำหรับโครงการโอเพ่นซอร์สขนาดใหญ่เท่านั้น ถ้าคุณเป็นโปรแกรมเมอร์คุณจะเป็นโปรแกรมเมอร์ที่มีประสิทธิภาพมากขึ้นถ้าคุณเรียนรู้วิธีใช้ VCSes ที่ออกแบบมาดีกว่าไม่ว่าจะเป็น Git, Mercurial, Darcs หรืออื่น ๆ
การโค่นล้มนั้นใช้งานง่ายมาก ฉันไม่เคยพบปัญหาในปีที่ผ่านมาหรือบางสิ่งบางอย่างไม่ทำงานตามที่คาดไว้ นอกจากนี้ยังมีเครื่องมือ GUI ที่ยอดเยี่ยมมากมายและการรองรับการรวม SVN นั้นยิ่งใหญ่
ด้วย Git คุณจะได้รับ VCS ที่ยืดหยุ่นมากขึ้น คุณสามารถใช้วิธีเดียวกันกับ SVN กับที่เก็บระยะไกลที่คุณยืนยันการเปลี่ยนแปลงทั้งหมด แต่คุณยังสามารถใช้เป็นส่วนใหญ่แบบออฟไลน์และผลักดันการเปลี่ยนแปลงเป็นครั้งคราวไปยังที่เก็บระยะไกล แต่ Git นั้นซับซ้อนกว่าและมีช่วงการเรียนรู้ที่ชันกว่า ฉันพบตัวเองเป็นครั้งแรกที่กระทำผิดกับสาขาสร้างสาขาโดยอ้อมหรือรับข้อความแสดงข้อผิดพลาดโดยมีข้อมูลไม่มากนักเกี่ยวกับความผิดพลาดและตำแหน่งที่ฉันต้องค้นหากับ Google เพื่อรับข้อมูลที่ดีกว่า บางสิ่งง่าย ๆ เช่นการทดแทนเครื่องหมาย ($ Id $) ไม่ทำงาน แต่ GIT มีการกรองและเบ็ดกลไกที่ยืดหยุ่นมากในการผสานสคริปต์ของตัวเองและเพื่อให้คุณได้ทุกสิ่งที่คุณต้องการและอื่น ๆ แต่ต้องการเวลามากขึ้นและอ่านเอกสาร ;)
หากคุณทำงานแบบออฟไลน์เป็นส่วนใหญ่กับที่เก็บในเครื่องของคุณคุณจะไม่มีการสำรองข้อมูลหากมีสิ่งใดหายไปในเครื่องของคุณ ด้วย SVN คุณส่วนใหญ่ทำงานกับพื้นที่เก็บข้อมูลระยะไกลซึ่งเป็นเวลาเดียวกันกับการสำรองข้อมูลของคุณบนเซิร์ฟเวอร์อื่น ... Git สามารถทำงานได้ในลักษณะเดียวกัน แต่นี่ไม่ใช่เป้าหมายหลักของ Linus ที่จะมี SVN2 เหมือนกัน มันถูกออกแบบมาสำหรับนักพัฒนาเคอร์เนล Linux และความต้องการของระบบควบคุมเวอร์ชันแบบกระจาย
Git นั้นดีกว่า SVN ไหม นักพัฒนาที่ต้องการเพียงประวัติรุ่นและกลไกการสำรองข้อมูลมีชีวิตที่ดีและง่ายด้วย SVN นักพัฒนาซอฟต์แวร์มักทำงานกับสาขาการทดสอบเวอร์ชันเพิ่มเติมในเวลาเดียวกันหรือการทำงานแบบออฟไลน์ส่วนใหญ่จะได้รับประโยชน์จากคุณสมบัติของ Git มีคุณสมบัติที่มีประโยชน์บางอย่างเช่นการหยุดทำงานไม่พบกับ SVN ซึ่งสามารถทำให้ชีวิตง่ายขึ้น แต่ในอีกด้านหนึ่งไม่ใช่ว่าทุกคนจะต้องการคุณสมบัติทั้งหมด ดังนั้นฉันไม่สามารถเห็นความตายของ SVN
Git ต้องการเอกสารที่ดีกว่าและการรายงานข้อผิดพลาดจะต้องมีประโยชน์มากกว่า GUIs ที่มีประโยชน์ที่มีอยู่ก็ไม่ค่อยมีเช่นกัน ครั้งนี้ฉันได้พบเพียง 1 GUI สำหรับ Linux ด้วยการสนับสนุนคุณสมบัติส่วนใหญ่ของ Git (git-cola) การรวมเข้าด้วยกันของ Eclipse ทำงานได้ แต่ไม่ได้เปิดตัวเป็นทางการและไม่มีเว็บไซต์อัปเดตอย่างเป็นทางการ (เฉพาะบางไซต์อัปเดตภายนอกที่มีการสร้างเป็นระยะจากลำต้นhttp://www.jgit.org/updates ) ดังนั้นวิธีที่นิยมที่สุดในการใช้ Git ในวันนี้ เป็นบรรทัดคำสั่ง
Eric Sinkจาก SourceGear เขียนบทความเกี่ยวกับความแตกต่างระหว่างระบบควบคุมรุ่นแบบกระจายและแบบไม่กระจาย เขาเปรียบเทียบข้อดีข้อเสียของระบบควบคุมเวอร์ชันยอดนิยม การอ่านที่น่าสนใจมาก
บทความสามารถพบได้ในบล็อกของเขาwww.ericsink.com :
สำหรับผู้ที่มองหา Git GUI ที่ดีSyntevo SmartGitอาจเป็นทางออกที่ดี มันเป็นกรรมสิทธิ์ แต่ฟรีสำหรับการใช้ที่ไม่ใช่เชิงพาณิชย์ทำงานบน Windows / Mac / Linux และยังรองรับ SVN โดยใช้ git-svn bridge บางชนิด
http://subversion.wandisco.com/component/content/article/1/40.html
ฉันคิดว่ามันค่อนข้างปลอดภัยที่จะบอกว่าในหมู่นักพัฒนา SVN กับ ขณะนี้ทุกคนมีมุมมองเป็นของตัวเองซึ่งดีกว่า สิ่งนี้เกิดขึ้นได้จากคำถามในระหว่างการสัมมนาผ่านเว็บเรื่องการโค่นล้มในปี 2010 และปีต่อ ๆ ไป
Hyrum Wright ผู้อำนวยการ Open Source และประธาน Subversion Corporation พูดถึงความแตกต่างระหว่างการโค่นล้มและ Git พร้อมกับ Distributed Version Control Systems (DVCS) อื่น ๆ
นอกจากนี้เขายังพูดถึงการเปลี่ยนแปลงที่จะเกิดขึ้นใน Subversion เช่น Working Copy Next Generation (WC-NG) ซึ่งเขาเชื่อว่าจะทำให้ผู้ใช้ Git จำนวนมากเปลี่ยนกลับไปเป็น Subversion
รับชมวิดีโอของเขาและแจ้งให้เราทราบว่าคุณคิดอย่างไรโดยแสดงความคิดเห็นในบล็อกนี้หรือโพสต์ในฟอรัมของเรา การลงทะเบียนนั้นง่ายและใช้เวลาเพียงชั่วครู่!
รองรับ Git ใน Windows ได้เป็นอย่างดี
ตรวจสอบ GitExtensions = http://code.google.com/p/gitextensions/
และคู่มือสำหรับประสบการณ์ Windows Git ที่ดีกว่า
ฉันอาศัยอยู่ในที่ดิน Git เมื่อเร็ว ๆ นี้และฉันชอบมันสำหรับโครงการส่วนบุคคล แต่ฉันไม่สามารถเปลี่ยนโครงการทำงานเป็นจากการโค่นล้มเนื่องจากการเปลี่ยนความคิดของพนักงานที่ต้องการโดยไม่มีผลประโยชน์เร่งด่วน ยิ่งไปกว่านั้นโครงการที่ใหญ่ที่สุดที่เราดำเนินการอยู่ในบ้านนั้นขึ้นอยู่กับsvn: externalsซึ่งจากสิ่งที่ฉันได้เห็นจนถึงตอนนี้ไม่สามารถใช้งานได้ดีและราบรื่นใน Git
ประการแรกการควบคุมเวอร์ชันที่ทำงานพร้อมกันดูเหมือนจะเป็นปัญหาง่าย ๆ ในการแก้ไข มันไม่ได้ทั้งหมด อย่างไรก็ตาม...
SVN ค่อนข้างใช้งานง่าย Git ยิ่งแย่ลงไปอีก [การประชดประชัน] อาจเป็นเพราะนักพัฒนาซอฟต์แวร์ที่ชอบปัญหาที่ยากลำบากเช่นการควบคุมเวอร์ชันพร้อมกันไม่สนใจสร้าง UI ที่ดี [/ เหน็บแนมเก็งกำไร]
ผู้สนับสนุน SVN คิดว่าพวกเขาไม่ต้องการระบบควบคุมเวอร์ชันแบบกระจาย ฉันก็คิดเช่นกัน แต่ตอนนี้เราใช้ Git โดยเฉพาะฉันเป็นผู้เชื่อ ตอนนี้การควบคุมเวอร์ชันใช้งานได้สำหรับฉันและทีม / โครงการแทนที่จะทำงานให้กับโครงการ เมื่อฉันต้องการสาขาฉันก็สาขา บางครั้งมันเป็นสาขาที่มีสาขาที่เกี่ยวข้องบนเซิร์ฟเวอร์และบางครั้งก็ไม่ ไม่พูดถึงข้อดีอื่น ๆ ทั้งหมดที่ฉันจะต้องศึกษาต่อไป (ขอบคุณในส่วนของการขาดความลึกลับและ UI ที่เป็นระบบควบคุมรุ่นที่ทันสมัย)
ทำไมฉันคิดว่าการโค่นล้มนั้นดีกว่า Git (อย่างน้อยสำหรับโครงการที่ฉันทำงาน) ส่วนใหญ่เป็นเพราะการใช้งานและขั้นตอนการทำงานที่ง่ายขึ้น:
http://www.databasesandlife.com/why-subversion-is-better-than-git/