"SVN & Git" ความแตกต่างระหว่าง Version Control ตัวเก่ง

Version Control System คือ ระบบที่คอยจัดการ backup source code ของเรา โดยเก็บเป็นลักษณะ version ต่างๆ เช่นในกรณีเกิดปัญหาขึ้น ก็สามารถหยิบเอา source code ตัวเก่าที่เคยใช้งานได้มาแทน พูดง่ายๆ ก็คล้ายๆ กับ Undo ที่เราทำกันนั่นแหละ แต่ว่า Version Control ยังเป็นตัวกลางที่ทำให้ source code ของแต่ละเครื่อง (แต่ละ programmer) มี source code ที่ตรงกันด้วย ซึ่งโดยปกติทั่วไปแล้ว programmer มักจะทำโปรแกรมให้เสร็จสมบูรณ์ และใช้งานได้ก่อน จึงค่อยโยนขึ้นไปที่ repository เพื่อให้คนอื่นดึงไปใช้ต่อไป

Version Control ตัวที่เด่นดังอยู่ตอนนี้ก็มีอยู่ 2 ตัว คือ Subversion(SVN) และ Git ซึ่งผมเองก็ได้ใช้มาแล้วทั้ง 2 ตัว แต่จะเต็มรูปแบบกับ SVN ซะมากกว่า

Repository เป็นคำศัพท์ที่เจอได้บ่อยใน version control หมายถึง ที่เก็บ source code ของเรา ถ้าไม่มีก็ลองไปใช้บริการของGoogle Code หรือ GitHub ก็ได้ครับ **ใครรู้จักตัวอื่นอีกก็ช่วยแนะนำด้วยนะครับ ^^

local / remote เป็นคำที่มักใช้เรียกแทน repository ในเครื่องเรา(local) และ repository บน server(remote) ซึ่ง remote จะเป็นตัวกลางระหว่างทีม


มาถึงเรื่องของ SVN กับ Git

การ pull โปรเจคลงมาจาก repository
SVN จะเป็นการ checkout โปรเจคลงมา ซึ่งหมายถึงว่า source code ที่เป็นเวอร์ชั่นล่าสุดจะถูกดึงลงมาไว้ที่เครื่องเรา
Git จะเป็นการ clone คือ การดึงมาทั้ง repository ไม่ว่าจะมีกิ่งก้านสาขาอะไรก็ตาม ทุกอย่างที่อยู่บน repository จะถูกเอาลงมาทั้งหมด

การ upload file สู่ repository
สำหรับ SVN นั้น จะเรียกว่าการ commit และหลังจากที่ commit ไปแล้วไฟล์เหล่านั้นก็จะอยู่ใน repository ทันที แต่ถ้าเป็น Git การ commit จะเป็นการเก็บอยู่ใน local ก่อน ซึ่งเราสามารถ commit แต่ละส่วนของโปรแกรมทีละนิดๆ แล้วค่อย push ขึ้นสู่ remote repository ทีเดียวก็ได้

ลำดับของ revision
SVN จะใช้เลขจำนวนเต็ม(Integer) รันไปเรื่อยๆ ซึ่งแน่นอนว่า ยิ่งเรา commit บ่อยเท่าไร ก็จะทำให้เลข revision มีเยอะขึ้นๆ
Git จะใช้ hash ด้วย SHA-1 hash algorithm เนื่องจาก git จะมีการ commit สู่ local repo. ก่อน เพราะถ้าใช้เป็นเลขรันไปเรื่อยๆเหมือน SVN ก็จะทำให้เกิดเลข revision ซ้ำกันได้


การทำงาน Online / Offline
SVN เป็น version control แบบ centralized หมายความว่า ทุกอย่างจะถูกเก็บในตัวกลาง ซึ่งก็คือ remote repo. ทั้งหมด ทำใช้งานจำเป็นต้องเชื่อมต่อ network ไปยัง repo. ไม่เช่นนั้นก็จะ commit หรือ check revision ก่อนๆ ไม่ได้เลย
Git เป็น version control แบบ distributed คือ หลังจากที่ clone remote repo. มาแล้ว ก็เท่ากับว่าเรามี local repo. ที่เหมือนกันกับ remote repo. ด้วย จะ commit ก็สามารถทำได้แบบ offline เลยเพราะเป็นการ commit ไปที่ local repo. แต่ถ้าเราจะ push ไปไว้ที่ remote repo. แน่นอนว่าต้องเชื่อมต่อ network เช่นเดียวกันครับ


เท่าที่ผมได้ลองใช้มาก็ประมาณนี้ครับ ประเด็นหลักๆ ผมว่าอยู่ที่การออกแบบที่แตกต่างกันระหว่าง Centralized กับ Distributed ซึ่งผมว่าแต่ละประเด็นมันก็แตกมาจากตรงนี้ ตัวไหนดีกว่า ตัวไหนเจ๋งกว่า ผมว่าอยู่ที่ปัจจัยหลายอย่าง วิธีการนำไปใช้ จำนวนคนในทีม ปริมาณงานที่ต้องแก้ไขร่วมกัน และอื่นๆ แต่ตอนนี้ผมใช้อยู่ทั้ง 2 ตัว SVN ใช้ที่ทำงาน ส่วน Git ใช้กับงานที่ตัวเองทำเล่นๆ เป็นการลอง Git ไปในตัวครับ ^^

ลองอ่านข้อมูลจากแหล่งอื่นๆ เพิ่มเติมนะครับ (แนะนำ link แรก ละเอียดมาก)
http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/
http://www.slideshare.net/technicalpickles/git-as-a-subversion-replacement
http://armno.in.th/2012/02/26/ความแตกต่างระหว่าง-git-กับ-svn/
http://boxysystems.com/index.php/5-fundamental-differences-between-git-svn/
วิธีใช้ GitHub กับ Eclipse ฉบับอ่านง่ายๆ

รู้จักกับ Git

นี้เราจะเริ่มเรียนรู้เกี่ยวกับการใช้งาน Git โดยจะเริ่มตั้งแต่จุดแรกสุดตั้งแต่อะไรคือเครื่องมือจัดการ version control จากนั้นจึงจะเริ่มอธิบายวิธีการติดตั้ง Git และสุดท้ายคือวิธีการตั้งค่าและเริ่มใช้งาน Git ในช่วงท้ายบทคุณจะเข้าใจว่าทำไม Git ถึงถูกสร้างขึ้นมาและคุณจะได้ประโยชน์อะไรจากมันบ้าง

เกี่ยวกับ Version Control

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

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

Version Control Systems แบบ Local

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

เพื่อที่จะลดปัญหาเหล่านี้ เมื่อนานมาแล้วโปรแกรมเมอร์ได้พัฒนาระบบ VCS ที่ใช้ในเครื่องของตัวเองโดยใช้ฐานข้อมูลง่าย ๆ เพื่อเก็บการแก้ไขทั้งหมดที่เกิดขึ้นกับไฟล์ที่อยู่ภายใต้ revision control (ดูรูป 1-1)

Insert 18333fig0101.png รูป 1-1. ระบบ version control แบบ local

หนึ่งในเครื่องมือ VCS ที่ใช้กันมากทั้งในอดีตและปัจจุบันคือระบบที่เรียกว่า rcs แม้แต่ระบบปฏิบัติการ Mac OS X ก็ยังติดตั้ง rcs ให้เมื่อคุณติดตั้ง Developer Tools เครื่องมือนี้ทำงานโดยเก็บสิ่งที่เรียกว่า patch set (ซึ่งก็คือผลต่างของไฟล์แต่ละไฟล์) สำหรับการแก้ไขแต่ละครั้งในรูปแบบพิเศษในเครื่อง ทำให้มันสามารถเรียกคืนไฟล์ ณ ช่วงเวลาใดขึ้นมาดูก็ได้โดยการไล่เรียงไปตาม patch ที่มี

ระบบ Version Control Systems แบบรวมศูนย์

ปัญหาถัดไปที่คนใช้พบก็คือการร่วมมือกันกับนักพัฒนาคนอื่น ๆ เพื่อที่จะแก้ปัญหานี้เครื่องมือใหม่จีงได้ถูกพัฒนาขึ้นมา เรียกว่าระบบ Centralized Version Control Systems (CVCSs) หรือระบบ Version Control Systems แบบรวมศูนย์ ระบบเหล่านี้ เช่น CVS, Subversion และ Perforce มีเซิร์ฟเวอร์กลางที่เก็บไฟล์ทั้งหมดไว้ในที่เดียวและผู้ใช้หลาย ๆ คนสามารถต่อเข้ามาเพื่อดึงไฟล์จากศูนย์กลางนี้ไปแก้ไขได้ ระบบการทำงานแบบรวมศูนย์นี้ได้ถูกนำมาใช้เป็นเวลานานหลายปี (ดูรูป 1-2)

Insert 18333fig0102.png รูป 1-2. ระบบ version control แบบรวมศูนย์

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

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

ระบบ Version Control Systems แบบกระจายศูนย์

นี่คือที่มาของ Distributed Version Control Systems (DVCSs) หรือระบบ VCS แบบกระจายศูนย์ ในระบบแบบนี้ (เช่น Git, Mercurial, Bazaar หรือ Darcs) แต่ละคนไม่เพียงได้ก๊อปปี้ล่าสุดของไฟล์เท่านั้น แต่ได้ทั้งก๊อปปี้ของ repository เลย หมายความว่าถึงแม้ว่าเซิร์ฟเวอร์จะเสีย client ก็ยังสามารถทำงานร่วมกันได้ต่อไป และ repository เหล่านี้ของ client ยังสามารถถูกก๊อปปี้กลับไปที่เซิร์ฟเวอร์เพื่อกูข้อมูลกลับคืนก็ได้ การ checkout แต่ละครั้งคือการทำสำรองข้อมูลทั้งหมดแบบเต็ม ๆ นั่นเอง (ดูรูป 1-3)

Insert 18333fig0103.png รูป 1-3. ระบบ version control แบบกระจายศูนย์

นอกจากนั้นระบบเหล่านี้ยังทำงานกับหลาย ๆ repository ได้อย่างดี ทำให้คุณสามารถทำงานกับคนหลายกลุ่มซึ่งทำงานในรูปแบบต่างกันในโปรเจคเดียวกันได้อย่างง่ายดาย เนื่องจากระบบเหล่านี้สนับสนุนการทำงานได้หลากหลายรูปแบบ ซึ่งอาจทำได้ยากในระบบแบบรวมศูนย์