นี่คือสำเนาของคำตอบที่ฉันทำจากคำถามซ้ำ ๆ ตั้งแต่ลบเกี่ยวกับ Git vs. SVN (กันยายน 2009)
ดีขึ้นหรือไม่ นอกเหนือจากลิงค์ปกติWhyGitIsBetterThanXที่แตกต่างกัน:
หนึ่งคือ VCS กลางตามสำเนาถูกสำหรับสาขาและแท็กอื่น ๆ (Git) เป็น VCS กระจายตามกราฟของการแก้ไข ดูเพิ่มเติมแนวคิดหลักของ VCS
ส่วนแรกนั้นสร้างความคิดเห็นที่ไม่ถูกต้องซึ่งอ้างว่าวัตถุประสงค์พื้นฐานของทั้งสองโปรแกรม (SVN และ Git) เหมือนกัน แต่พวกเขามีการใช้งานที่แตกต่างกันมาก
เพื่อชี้แจงความแตกต่างพื้นฐานระหว่าง SVN และ Gitให้ฉันใช้ถ้อยคำใหม่:
SVN คือการนำการควบคุมการแก้ไขไปใช้ครั้งที่สาม: RCS จากนั้น CVS และสุดท้าย SVN จะจัดการไดเรกทอรีของข้อมูลที่มีเวอร์ชัน SVN เสนอคุณสมบัติ VCS (การติดฉลากและการรวม) แต่แท็กของมันเป็นเพียงการคัดลอกไดเรกทอรี (เช่นสาขายกเว้นคุณไม่ควร "แตะ" เพื่อสัมผัสทุกอย่างในไดเรกทอรีแท็ก) และการผสานยังคงซับซ้อนอยู่ในปัจจุบันโดยใช้เมตา - ข้อมูลถูกเพิ่มเข้ามาเพื่อจดจำสิ่งที่ถูกผสานแล้ว
Git คือการจัดการเนื้อหาไฟล์ (เครื่องมือที่ทำเพื่อผสานไฟล์) ซึ่งพัฒนาเป็นระบบควบคุมเวอร์ชันที่แท้จริงโดยใช้ DAG ( Directed Acyclic Graph ) ของการกระทำซึ่งสาขาเป็นส่วนหนึ่งของประวัติศาสตร์ของข้อมูล (ไม่ใช่ข้อมูลเอง) ) และตำแหน่งที่แท็กเป็นข้อมูลเมตาจริง
จะพูดว่าพวกเขาจะไม่ "พื้นฐาน" ที่แตกต่างกันเพราะคุณสามารถบรรลุสิ่งเดียวกันแก้ไขปัญหาเดียวกันคือ ... เท็จธรรมดาในหลายระดับ
- ถ้าคุณมีการผสานที่ซับซ้อนหลายอย่างการทำด้วย SVN จะนานขึ้นและเกิดข้อผิดพลาดได้ง่ายขึ้น ถ้าคุณต้องสร้างสาขาจำนวนมากคุณจะต้องจัดการและผสานพวกเขาอีกครั้งได้ง่ายขึ้นด้วย Git มากกว่ากับ SVN โดยเฉพาะอย่างยิ่งถ้ามีไฟล์จำนวนมากเข้ามาเกี่ยวข้อง (ความเร็วนั้นสำคัญมาก)
- หากคุณมีการผสานบางส่วนสำหรับงานที่กำลังดำเนินการคุณจะใช้ประโยชน์จากพื้นที่จัดเตรียม Git (ดัชนี) เพื่อกระทำเฉพาะสิ่งที่คุณต้องการสะสมที่เหลือและย้ายไปที่สาขาอื่น
- หากคุณต้องการการพัฒนาออฟไลน์ ... ดีกับ Git คุณจะเป็น "ออนไลน์" อยู่เสมอพร้อมที่เก็บข้อมูลในพื้นที่ของคุณไม่ว่าจะเป็นเวิร์กโฟลว์ใดก็ตามที่คุณต้องการติดตามกับที่เก็บอื่น ๆ
ยังคงความคิดเห็นเกี่ยวกับคำตอบเก่า (ถูกลบ) ยืนยันว่า:
VonC: คุณกำลังสับสนความแตกต่างพื้นฐานในการนำไปใช้ (ความแตกต่างนั้นเป็นพื้นฐานที่สำคัญมากเราทั้งคู่เห็นด้วยอย่างชัดเจนกับเรื่องนี้) ด้วยจุดประสงค์ที่แตกต่างกัน
ทั้งสองเป็นเครื่องมือที่ใช้เพื่อจุดประสงค์เดียวกัน: นี่คือเหตุผลว่าทำไมหลายทีมที่เคยใช้ SVN ก่อนหน้านี้สามารถถ่ายโอนข้อมูลไปยัง Git ได้สำเร็จ
หากพวกเขาไม่ได้แก้ปัญหาเดียวกันความสามารถในการทดแทนนี้จะไม่เกิดขึ้น
ซึ่งฉันตอบว่า:
"substitutability" ... คำที่น่าสนใจ ( ใช้ในการเขียนโปรแกรมคอมพิวเตอร์ )
นอกหลักสูตร Git นั้นแทบจะเป็น SVN ย่อยไม่ได้
คุณอาจได้รับคุณสมบัติทางเทคนิคแบบเดียวกัน (แท็กสาขาการผสาน) กับทั้งคู่ แต่ Git ไม่สามารถเข้าถึงและอนุญาตให้คุณมุ่งเน้นไปที่เนื้อหาของไฟล์โดยไม่ต้องคิดถึงเครื่องมือเอง
แน่นอนคุณไม่สามารถ (เสมอ) แทนที่ SVN ด้วย Git "โดยไม่เปลี่ยนแปลงคุณสมบัติที่ต้องการของโปรแกรมนั้น (ความถูกต้อง, งานที่ดำเนินการ, ... )" (ซึ่งเป็นการอ้างอิงถึงคำจำกัดความการทดแทนที่กล่าวมาข้างต้น):
- หนึ่งคือเครื่องมือการแก้ไขเพิ่มเติมส่วนอีกระบบการควบคุมเวอร์ชันที่แท้จริง
- หนึ่งเหมาะสำหรับโครงการเสาหินขนาดเล็กถึงขนาดกลางที่มีขั้นตอนการรวมที่เรียบง่ายและรุ่นที่ขนานกัน (ไม่มากเกินไป) SVN นั้นเพียงพอสำหรับวัตถุประสงค์ดังกล่าวและคุณอาจไม่ต้องการคุณสมบัติ Git ทั้งหมด
- อีกโครงการหนึ่งอนุญาตให้โครงการขนาดกลางถึงขนาดใหญ่ขึ้นอยู่กับองค์ประกอบหลายส่วน ( หนึ่ง repo ต่อองค์ประกอบ ) ที่มีไฟล์จำนวนมากเพื่อผสานระหว่างหลายสาขาในเวิร์กโฟลว์ผสานที่ซับซ้อนรุ่นขนานในสาขาการรวม retrofit และอื่น ๆ คุณสามารถทำได้ด้วย SVN แต่คุณเก่งกว่า Git มาก
SVN ไม่สามารถจัดการโครงการทุกขนาดด้วยเวิร์กโฟลว์ผสานใด ๆ Git สามารถ
อีกครั้งธรรมชาติของพวกเขานั้นมีความแตกต่างกันโดยพื้นฐาน (ซึ่งนำไปสู่การนำไปปฏิบัติต่างกัน แต่นั่นไม่ใช่ประเด็น)
หนึ่งเห็นการควบคุมการแก้ไขเป็นไดเรกทอรีและไฟล์อื่น ๆ เพียงดูเนื้อหาของไฟล์ (มากดังนั้นไดเรกทอรีที่ว่างเปล่าจะไม่ได้ลงทะเบียนใน Git!)
เป้าหมายทั่วไปทั่วไปอาจเหมือนกัน แต่คุณไม่สามารถใช้ในลักษณะเดียวกันและไม่สามารถแก้ปัญหาระดับเดียวกันได้ (ในขอบเขตหรือความซับซ้อน)