ฉันทำงานในแผนกที่ไม่มีใครเคยใช้การควบคุมซอร์สมาก่อนรวมถึงตัวฉันด้วย

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

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

มีข้อดีข้อเสียของทั้งสองวิธีหรือไม่?

ไม่

Git นั้นแตกต่างจาก SVN อย่างสิ้นเชิงมันจะไม่ช่วยคุณ หากมีสิ่งใดที่คุณกำลังมองหาคำสั่ง "update" และ "commit" และสงสัยว่าทำไมทุกอย่างจึงแตกต่างกัน

เริ่มต้นด้วยGit จากล่างขึ้นบนและไปจากที่นั่น

การเปรียบเทียบความแตกต่างของมาตรฐานแบบรวมศูนย์การปรับปรุง / คอมมิชชันรูปแบบระบบกับ Git เปรียบเสมือนการเปรียบเทียบรถบัสกับการขนส่งมวลชน รถบัสจะพาคุณ (และคนอื่น ๆ ) จากจุด A ไปยังจุด B โดยใช้เส้นทางเดียวกัน การขนส่งมวลชนจะพาคุณจากจุด A ไปยังจุด B โดยใช้เส้นทางใดก็ได้ที่คุณต้องการ

กระจายตัวเองมีข้อเสียที่คุณควรระวัง การทำงานมากขึ้นเพื่อให้ทุกคนอยู่ในหน้าเดียวกัน มันมีความยืดหยุ่นเพิ่มขึ้นอย่างมาก

แฮชการแก้ไขเทียบกับตัวเลข

มีคนพูดถึง Git โดยใช้แฮช SHA1 ในขณะที่ Hg ใช้ตัวเลข

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

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

ไม่ได้โปรดอย่ารำคาญ

เริ่มจาก DVCS อย่างจริงจัง ความจริงที่ว่า SVN นั้นเป็นที่นิยมนั้นไม่ได้ทำให้เป็นมาตรฐาน Linus Torvalds จะบอกคุณว่ามันอาจจะเน่าสมองของคุณ

อ่านบทความนี้ดี / แนะนำโดยโจ Spolsky เรียกว่าการโค่นล้มเรื่องการศึกษา

คุณอาจสนใจอ่านคำถามอื่น: ฉันเป็นผู้ที่ถูกโค่นล้มเพราะเหตุใดฉันจึงควรพิจารณาหรือไม่พิจารณา Mercurial หรือ Git หรือ DVCS อื่น ๆ

การเลือกระหว่าง DVCS

โดยส่วนตัวแล้วฉันใช้ทั้ง Mercurial และ Git และฉันคิดว่ามันสำคัญที่จะต้องรู้ทั้งสองอย่าง การอ่านที่แนะนำเกี่ยวกับเรื่องนี้คือGit vs. Mercurial: โปรดผ่อนคลาย (ดูตัวอย่าง git-addremove) คำพูดสองข้อจากบทความนั้นที่ฉันคิดว่ารวมไว้

เกี่ยวกับคอมไพล์:

ปรัชญาการออกแบบของ Git นั้นไม่แตกต่างจาก Unix: ซึ่งแตกต่างจาก Subversion, CVS หรือ Mercurial, git ไม่ใช่หนึ่ง monolithic binary แต่มีเครื่องมือมากมายที่หลากหลายตั้งแต่คำสั่ง“ Porcelain” ระดับสูงเช่น git-pull, git-merge และ git-checkout ไปยังคำสั่ง“ plumbing” ระดับต่ำเช่น git-apply, git-hash-object และ git-merge-file ดังนั้นเช่น MacGyver คุณสามารถทำอะไรก็ได้ที่คุณต้องการด้วย Git - ซึ่งรวมถึงเอ็นจิ้น Wiki ที่ยอดเยี่ยมตัวติดตามปัญหาระบบไฟล์เครื่องมือดูแลระบบ - ทุกอย่างที่ขาดการซ่อมแซมฟิวส์

เกี่ยวกับ Mercurial:

นักพัฒนาที่ต้องการรักษาความสะอาดระบบของพวกเขาอาจจะชื่นชมความจริงที่ว่า hg ติดตั้งหนึ่งไบนารีในทางตรงกันข้ามกับ 144 ที่ทำขึ้นคอมไพล์และนักพัฒนาที่คิดว่าความสามารถของ git ในการแก้ไขคอมมิชชันก่อนหน้านั้น ความเรียบง่าย hg จัดทำโดยการละเว้นคุณสมบัติเฉพาะนั้น

โครงการจำนวนมากสามารถพบได้ใน gitHub และ git นั้นมีประสิทธิภาพมากขึ้น แต่ก็อาจเป็นการข่มขู่ผู้ใช้รายใหม่โดยเฉพาะผู้ใช้ windows นอกจากนี้ยังมีbitbucket (เทียบเท่า github สำหรับ mercurial)

คำแนะนำของฉัน: เริ่มต้นด้วย mercurial และทันทีที่คุณรู้สึกสะดวกสบายรับ git; มันไม่ได้เกี่ยวกับเครื่องมือที่มันเป็นเรื่องเกี่ยวกับคนที่คุณทำงานด้วย

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

• ปัจจุบัน svn เกือบติดตั้งในผู้ให้บริการโฮสติ้งส่วนใหญ่
• มีการสนับสนุนโครงการย่อยที่ดี (สามารถจัดการได้ใน git และ hg ในขณะนี้) svn upและโครงการของคุณและการอ้างอิงได้รับการปรับปรุง

การอ้างถึงThorbjørnในหัวข้ออื่นนี้ :

DVCS คือการโค่นล้ม Bittorrent คือ ftp

แก้ไข : หากมี VCS ที่คุณควรรู้ก่อน Git นั่นอาจเป็น Mercurial (วิธีที่เป็นมิตรกับอินเตอร์เฟซ CLI ที่เป็นมิตรมากขึ้นและเป็นเรื่องดีที่จะได้รับการแนะนำให้รู้จักกับแนวคิดแบบกระจาย) คำแนะนำนี้ใช้เป็นพิเศษกับผู้ที่มาจากการโค่นล้มเนื่องจาก CLI ก็คล้ายกันในระดับหนึ่ง กระจายการควบคุมเวอร์ชันที่สามารถทำได้ง่ายกว่าที่จะเรียนรู้จากส่วนกลางควบคุมเวอร์ชันตั้งแต่คุณเพียงแค่ต้องกังวลเกี่ยวกับอินสแตนซ์พื้นที่เก็บข้อมูลของคุณและไม่ได้เป็นลูกค้าและเซิร์ฟเวอร์ชิ้นส่วนแยก

คุณควรเรียนรู้สิ่งที่คุณตั้งใจจะใช้ Git ได้รับความนิยมเช่นเดียวกับ Mercurial และยังได้รับความนิยม Git / Mercurial เป็นทั้งระบบกระจายแหล่งควบคุม

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

• จุดประสงค์ของการควบคุมเวอร์ชันในทีมของเราคืออะไร ใช่ระบบควบคุมเวอร์ชันทั้งหมดมีค่าอะไรที่จะทำให้คุณย้อนกลับไปในประวัติศาสตร์และดูว่ามีอะไรเปลี่ยนแปลงในไฟล์ใดก็ตาม อย่างไรก็ตามคุณจะใช้มันเป็นพื้นฐานในการวางตลาดใหม่หรือไม่? (พยักหน้าคุณต้องการสิ่งนี้) นี่คือแถลงการณ์การมองเห็น 2-3 บรรทัดสำหรับสิ่งที่คุณต้องการทำให้สำเร็จ
• ทีมของคุณเคยมีสภาพแวดล้อมการทำงานในท้องถิ่นของตัวเองเพื่อรวมสิ่งต่าง ๆ อย่างระมัดระวังในภายหลังหรือไม่? ถ้าเป็นเช่นนั้นเส้นทาง DVCS อาจเหมาะสมที่สุด
• ในทางกลับกันทีมของคุณคุ้นเคยกับการทำงานจากไดรฟ์ที่ใช้ร่วมกันเพียงไดรฟ์เดียว ถ้าเป็นเช่นนั้น VCS ดั้งเดิมมากขึ้นอาจทำให้รู้สึกมากที่สุด

เมื่อประเมินทางเลือกของคุณคุณต้องพิจารณาสิ่งสำคัญที่ VCS จำเป็นต้องทำทั้งหมด:

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

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

ในที่สุดเรียนรู้สิ่งที่คุณตั้งใจจะใช้

ฉันคิดว่าผู้คนจำนวนมากพบคอมไพล์ที่ซับซ้อนกว่า svn เพราะมันแตกต่างกัน หลังจากใช้การโค่นล้ม (หรือ cvs เป็นต้น) ชั่วครู่หนึ่งมันอาจเป็นการยากที่จะเปลี่ยนโหมดจิตใจเป็นรูปแบบ DVCS จากนั้นฉันจะบอกว่ามันอาจทำให้คุณต้องค้นคว้า VCS แบบดั้งเดิมเช่นการโค่นล้มควบคู่กับการวิจัย DVCS เช่นคอมไพล์

แม้ว่า git เป็น VCS ที่ฉันต้องการ แต่ฉันก็บอกว่ามันอาจจะดีที่สุดในการเรียนรู้การโค่นล้มเช่นกัน สำหรับหนึ่งยังคงมีการโค่นล้มและที่เก็บ CV จำนวนมากที่คุณอาจต้องโต้ตอบกับหนึ่งวันและคุณจะมีความเข้าใจที่ดีขึ้นเกี่ยวกับข้อดีและข้อเสียของ DVCS ที่แม่นยำกว่า VCS ดั้งเดิม

มันจะต่อต้านการผลิตเพื่อเรียนรู้ svn และ git

นี่คือสาเหตุบางประการ:

• คอมไพล์แตกต่างอย่างสิ้นเชิงจาก svn Distrubted ของ Git และ svn คือไคลเอนต์ / เซิร์ฟเวอร์
• ความหมายที่แตกต่างกันจะแนบไปกับคำเดียวกัน ตัวอย่างเช่น 'git checkout ... ' มีความหมายแตกต่างจาก 'svn checkout ... '
• การแตกแขนงนั้นแตกต่างกัน Git มีแนวคิดเกี่ยวกับสาขา 'topic' ซึ่งเป็นสาขาท้องถิ่นราคาถูกที่ svn ไม่สนับสนุน
• Git มีสถานที่พิเศษที่เรียกว่าดัชนีซึ่งอยู่ระหว่างแผนผังการทำงานกับที่เก็บของคุณ Svn ไม่มีดัชนี การใช้คอมไพล์การเปลี่ยนแปลงของคุณย้ายจากแผนผังการทำงานไปยังดัชนีไปยังที่เก็บ

คำแนะนำของฉันคือการเรียนรู้คอมไพล์

มีบางสิ่งในวงกว้างเหมือนกันใน GIT และ SVN และบางอย่างไม่ได้

สร้าง / ปรับปรุง / ชำระเงิน / commit

ในวงกว้างคุณควรหยิบมันขึ้นมาอย่างง่ายดาย

วิธีติดแท็กและสาขา แต่ยังสับสนมากเกี่ยวกับความขัดแย้งระหว่างกิ่งและลำตัว ฯลฯ

แตกต่างกันระหว่างคนทั้งสอง

ไม่ได้บอกว่าคุณควรหรือไม่ควรเปลี่ยนตอนนี้ (ฉันคิดว่านั่นคือการโทรของคุณ) เพียงแค่ต้องการชี้ให้เห็นว่าเป็นสิ่งที่ต้องคำนึงถึง หากคุณแน่ใจว่าคุณต้องการลอง Git คุณอาจตัดสินใจเปลี่ยนทันทีเพื่อช่วยตัวเองให้เรียนรู้บางสิ่งใน SVN ที่แตกต่างใน Git

ว้าว; 12 คำตอบและทุกคนยังคงขอทานคำถาม ...

ไม่การโค่นล้มไม่ใช่ข้อกำหนดเบื้องต้นสำหรับ Git

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

• svn commitgit commitเป็นสิ่งที่แตกต่างกว่า
• สาขาใน svn และ git นั้นแตกต่างกันมาก
• ที่เก็บ svn นั้นเหมือน git remote มากกว่า (แต่ไม่ใช่จริงๆ)
• พื้นที่เก็บข้อมูล git เป็นเหมือนสำเนาทำงาน svn (แต่ไม่จริง)

เครื่องมือสองชนิดนี้หารด้วยภาษาทั่วไป

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

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

(ไม่ว่าจะด้วยวิธีใดให้แน่ใจว่าคุณมีระบบดูแลระบบสำรองที่เก็บข้อมูลหลัก - การสูญเสียการควบคุมแหล่งที่มาของคุณอาจเป็นความหายนะ)

อาจไม่ - มีความแตกต่างเพียงพอระหว่างเซิร์ฟเวอร์ที่ใช้และเผยแพร่ว่าคุณอาจสับสนตัวเองต่อไปเท่านั้น

ออกเดินทางตั้งแต่เริ่มต้นเพื่อปฏิบัติตามแนวทางปฏิบัติที่ดีกับ DVCS ที่คุณเลือกราวกับว่าเป็นศูนย์และคุณอาจจะมีความสุขมากขึ้น

ไปดู Mercurial (ถ้าคุณไม่อยากจม)

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

มันคุ้มค่าที่จะเรียนรู้ Git ในขณะที่คุณมีโอกาสที่จะทำให้จิตใจของคุณไม่ถูกทำลายโดยการโค่นล้ม

ฉันไม่คิดว่าการเข้าใจการโค่นล้มจำเป็นต้องเข้าใจ Git

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

ฉันชอบคอมไพล์ในสภาพแวดล้อม Unix (Linux, MacOS X) ใน windows มันค่อนข้างแฮ็คเล็กน้อย ฉันจะพิจารณา Mercurial ถ้าฉันมี Windows ในสมการ

ฉันชอบคลาสประวัติศาสตร์ของคุณลอง SCCS, RCS, CVS, การโค่นล้มแล้วใช้สิ่งที่มีประโยชน์เช่น Git หรือ Mercurial

Git และ Mercurial มี equipotent โบนัสใหญ่ของ Git เป็นGitHub แต่ถ้าคุณไม่ต้องการที่จะ outsource การควบคุมเวอร์ชันของคุณ GitHub ไม่ได้อยู่ในสมการอีกต่อไป

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

คุณสามารถเรียนรู้ Git ได้และใช้เวลาในการเรียนรู้ Suvbersion ในภายหลังหากคุณต้องการ

Nope ดาวน์โหลด Git, สร้างบัญชี GitHub และยุ่ง ๆ ไปกับการซื้อ repos มาสองสามวันเป็นต้น Git นั้นค่อนข้างง่ายที่จะเร่งความเร็ว เรียนรู้คำสั่ง bash 5 หรือ 6 คำสั่งและคุณสามารถทำงานที่จำเป็นทั้งหมดได้ โดยทั่วไปฉันชอบ "การพิสูจน์ความโง่" ของ GUI แต่ Git Bash นั้นง่ายพอ ๆ กับที่ได้รับ นอกจากนี้ Git Gui ก็ค่อนข้างดีถ้าคุณชอบเส้นทางนั้น ฉันไม่เห็นประโยชน์ที่คุณจะได้รับจากการเรียนรู้ SVN ฉันผ่านช่วงเวลาหนึ่งกลับไปที่ฉันกำลังประเมินระบบควบคุมเวอร์ชันต่าง ๆ สำหรับโครงการโอเพนซอร์สใหม่ ฉันลองใช้ SVN, Bazaar, Git และอีกสองสามคนและเรียนรู้พื้นฐานของแต่ละคน YMMV แต่ Git เป็นโดยไกลที่ง่ายที่สุด ไม่มีอะไรผิดปกติกับการเรียนรู้ SVN เช่นกัน แต่จริงๆแล้วมันจะไม่ช่วยให้คุณเรียนรู้ Git