บทนี้เป็นบทแห่งการเริ่มต้นที่จะบอกเล่าเรื่องราวที่มาที่ไปของสิ่งที่เรียกว่า version contol tools จากนั้นเราก็จะถูกดึง มาเข้าเรื่อง Git ว่าเราจะไปทำยังไงให้ Git มาอยู่ในเครื่องเราได้ ทำไงให้มันทำงานได้และเมื่อจบบทนี้เราจะได้รู้ว่า ทำไมต้อง Git นั่นสิทำไม?
อะไรคือ version control แล้วทำไมต้องใช้ด้วย บางคนอาจบอกว่า “ก็จำได้ว่าทำอะไรไปมีไรป่ะ” แต่สุดท้ายผ่านไปสองเดือนก็ลืมหมด version control คือระบบที่บันทึกการเปลี่ยนแปลงทั้งหมดที่เกิดขึ้นกับไฟล์หรือชุดของไฟล์ที่เรากำลัง ทำงานกับมันอยู่และเมื่อมีการบันทึกการเปลี่ยนแปลง ทุกครั้งที่เกิดปัญหาแก้ไฟล์มั่วจำไม่ได้ เราก็สามารถย้อนกลับ ไปหาเวอร์ชั่นใดๆก่อนหน้าได้เสมอ โดยที่ตัวอย่างที่จะใช้ในหนังสือเล่มนี้จะเป็นไฟล์ที่ทรัพย์สินอันสำคัญเช่น source code จะถูกควบคุมโดย version control แต่อย่างไรก็ตามสำหรับการนำไปใช้งานจริงนั้นเราสามารถประยุกต์ใช้กับ ไฟล์ประเภทไหนก็ได้ เช่นถ้าคุณเป็น graphic designer และอยากจะเก็บเวอร์ชั่นของภาพที่เราทำไปให้หมดทุกอัน สิ่งที่ช่วยเรื่องเหล่านี้ ได้คือ Version Control System (VCS) มันคือสิ่งที่คุณ “ต้อง” ใช้เพราะมันจะช่วยให้เราถอยไปถอยมาได้ไม่ว่าจะเป็น ระดับไฟล์หรือระดับโปรเจค ถ้ามันเละมากแก้มั่วไปหมดก็สามารถถอยกลับไปได้ วื๊บๆ ดังนั้นไอ้พวกข้ออ้างไฟล์หาย ไฟล์พังเพื่อขอเลื่อนโปรเจคหรือส่งงานข้าจะใช้ไม่ได้อีกต่อไป -/-
ย่อหน้าที่แล้วมีคำว่า VCS เยอะมากเอ๊ะแล้วจริงๆเขาทำด้วยอะไรกัน? คำตอบเริ่มจากทำกันบ้านๆก็ได้ไม่ต้องคิดมาก copy file ที่ต้องการไว้บ่อยๆจะแก้ก็ copy ทิ้งไว้ก่อนแล้วตั้งชื่อ directory ให้สอดคล้องกัน ทำไปเรื่อยๆนี่ไง VCS กราบส์ OTL ทำแบบนี้ก็ไม่ผิดแต่มันเยอะส์บางทีลืมบ้างอะไรบ้างก็บ้าบอกันได้เลยทีเดียวเพราะไม่รู้อันไหนแน่ที่ต้อง เอากลับมาใช้และเพื่อแก้ไขปัญหาเรื่องนี้โปรแกรมเมอร์ (อีกแล้วไม่ใช่ tester) ได้สร้าง VCS ที่มี database แปะมาด้วยสำหรับการเก็บประวัติการเปลี่ยนแปลงทั้งหลายทั้งปวง ดังรูป(ดู Figure 1-1).
Insert 18333fig0101.png Figure 1-1. Local version control diagram.
หนึ่งใน VCS ในตำนานที่ยังคงอยู่ค้ำฟ้ามาจนถึงปัจจุบันคือ rcs ยกตัวอย่างเช่นใน Mac OS X เองก็ยังคงมีคำสั่ง rcs ให้เราใช้งานได้หลังจากที่เราติดตั้ง Developer Tools ลงในเครื่องโดยที่เจ้า rcs นี้จะทำหน้าที่เก็บความแตกต่างของไฟล์หรือที่เรียกว่า patch sets เพื่อใช้สำหรับการสร้างไฟล์ขึ้นมาใหม่ในกรณีที่เกิด file lock หลังจากที่เราลง patch ใหม่ลงไปในเครื่องดังนั้น rcs ก็จะเป็นตัวอย่างที่ดีของการทำ local repository แต่ของแบบนี้ก็ดีถ้าเราทำอะไรคนเดียว
ในกรณีที่เราต้องการทำงานร่วมกับคนอื่นๆแล้วเราจะแบ่งปันโค้ดเทพของกันและกันได้อย่างไรนี่ไอ้ของแบบ Local Repo คงไม่เหมาะเท่าไหร่ ดังนั้นของใหม่ที่เกิดถัดมาคือ Centralized Version Control System (CVCSs) และตัวอย่างของระบบแบบนี้คือ CVS, Subversion และ Perforce นั่นเองซึ่งหัวใจหลักของการทำงานแบบนี้คือจะต้องมี server หนึ่งตัวที่รับหน้าที่เก็บของให้ทั้งหมด ทั้งไฟล์ที่เกิดการเปลี่ยนแปลงและจำนวน user ที่ check out ไฟล์จาก server และอย่างที่เรารู้ว่า Centralize Repo เป็นมาตรฐานของ VCS มานานหลายปี (ดู Figure 1-2).
Insert 18333fig0102.png Figure 1-2. Centralized version control diagram.
สำหรับการ setup ระบบแบบ Centralize เองก็มีข้อดีหลายอย่างมากที่ดีกว่า local VCSs ยกตัวอย่างเช่นทุกๆคนในทีมจะรู้ว่าคนอื่นๆในทีมที่เหลือกำลังทำอะไรอยู่ ส่วนผู้ที่ดูแลระบบก็สามารถจัดการกับสิทธิ์การทำงานของ user ทุกคนได้ซึ่งนี้ก็เป็นข้อดีที่เหนือกว่าการมานั่งกำหนดอะไรอะไรที่ local database ทีละเครื่องมากมายนัก
แต่อย่างไรก็ตามการทำงานในลักษณะนี้เองก็มีข้อเสียที่น่าสนใจอยู่หนึ่งอย่างและดูเหมือนว่าจะร้ายแรงมากคือในกรณีที่ server พังไปสักชั่วโมงจะทำให้คนที่ทำงานอยู่ไม่สามารถส่งอะไรเข้ามา update ได้เลยและถ้าเอาให้หนักหน่อยในกรณีที่ไม่มีการสำรองข้อมูลไว้เราจะพบกับฝันร้ายขั้นร้ายแรงคือ เราจะเสีย history ทั้งหมดของระบบไปหมดเลย (แรงดีเนอะ) ดังนั้นนี่คือด้านมืดของ Centrlaized Repo
หลังจากที่เราเห็นด้านมืดของ Centralize Rep ไปแล้วเราก็จะได้รู้จักกับสิ่งที่เรียกว่า Distributed Version Control system (DVCSs) ตัวอย่างของระบบแบบนี้คือ (Git, Mercurial, Bazaar หรือ Darcs) โดยที่ความแปลกของระบบแบบนี้คือแทนที่เครื่อง client จะทำการ check out เอา snapshot ล่าสุดไปไว้บนเครื่องมันจะทำสิ่งที่ยิ่งใหญ่กว่านั้นคือมันทำ full mirror ข้อมูลทั้งหมดของโปรเจคที่กำลังทำงานลงมาไว้ที่เครื่องเลยดังนั้นการทำงานแบบนี้จะแก้ปัญหาเรื่อง Server พังแล้วไม่สามารถย้อนกลับไปเอา history กลับคืนมาได้เพราะข้อมูลที่อยู่บนเครื่อง client ก็สามารถถูกส่งกลับขึ้นไปเพื่อ restore ระบบได้ทั้งหมดเหมือนกันดังนั้นการ check out ของ DVCS ก็คือการทำ Full Backup นั่นเองดังรูป (see Figure 1-3)
Insert 18333fig0103.png Figure 1-3. Distributed version control diagram.
นอกจากนี้แล้วระบบแบบนี้ยังถูกออกแบบให้มีความสามารถในการทำงานกับ remote repository ได้มากกว่าหนึ่งที่ด้วยนั่นหมายความว่าเราสามารถทำงานแจมกับพรรคพวกได้มากกว่าหนึงที่ในโปรเจคเดียวกัน ดังนั้นเราจะสามารถ setup workflow ได้หลายประเภทเพื่อให้รองรับการทำงานของเราและสิ่งนี้ทำไม่ได้ใน Centralize Repository นะจ๊ะย้ำ
เฉกเช่นสิ่งมหัศจรรย์ทั้งหลายแหล่ในโลก, Git เริ่มต้นมาจากดราม่าส์เล็กๆ ณ ชุมชนหนึ่งในดาวนี้ Linux kernel เป็น open source โปรเจคอันนึงที่มีขนาดใหญ่พอสมควร เกือบทั้งชีวิตของการ maintenance kernel ของ Linux นี้ (ช่วงปี 1991–2002) การเปลี่ยนแปลงต่างๆถูกส่งไปส่งมาในรูปแบบ patch และ zip files จนกระทั่งปี 2002 Linux kernel project ก็เริ่มใช้ DVCS ที่เรียกว่า BitKeeper
ในปี 2005 ความสัมพันธ์ระหว่าง community ที่พัฒนา Linux kernel กับบริษัท commercial ที่พัฒนา BitKeeper ก็สะบั้นลง ไอ้ tool ที่เคยใช้ได้ฟรีมาตลอดก็จุ๊งไป ทำให้ community ที่พัฒนา Linux (โดยเฉพาะท่านเทพ Linus Torvalds ที่เป็นบิดาแห่ง Linux) ต้องพัฒนา tool ขึ้นมาใช้เอง โดยอิงจากประสบการณ์ที่ได้เรียนรู้ระหว่างใช้งาน BitKeeper ระบบใหม่มีเป้าหมายบางประการ ดังนี้:
- ความเร็วส์
- design ที่ simple
- ต้องพัฒนาไปพร้อมๆกันที่ละหลายๆคนได้ (ประมาณ 1000 branches)
- distributed สุดๆ
- ใช้กับโปรเจคใหญ่ๆอย่าง Linux kernel ได้ดี (ทั้งเรื่องความเร็วส์และขนาดของข้อมูล)
ตั้งแต่ถูกคลอดมาในปี 2005, Git ก็พัฒนาและเติบโตจนเป็นของที่ใช้ง่าย แต่ก็ยังคงไว้ซึ่งข้อดีข้างต้นนี้ นั่นเร็วส์สุดยิด, เหมาะกับโปรเจคขนาดยักษ์ และพัฒนาไปพร้อมๆกันทีละหลายๆ branch อย่างน่าอัศจรรย์ (ดูได้ใน Chapter 3).
เอาล่ะ มาดูกันว่า Git in a nutshell เป็นยังไง? ส่วนนี้เป็นส่วนสำคัญที่ท่านจะต้องดูดไป เพราะเมื่อไหร่ที่ท่านเข้าใจแก่นแท้ของ Git และเข้าใจว่ามันทำงานยังไง เมื่อนั้น การใช้ Git อย่างมีประสิทธิภาพสูงสุดก็ไม่ยากละ ขณะที่เรียนรู้ Git พยายามลืม VCSs ตัวที่ผ่านๆมาให้หมด (เช่น Subversion และพวกพ้อง) เพราะมันจะป้องกันความงงที่จะเกิดขึ้นระหว่างใช้ Git ได้ Git มองและจำข้อมูลต่างกับระบบอื่นๆค่อนข้างเยอะ แม้ว่า UI มันจะดูคล้ายๆตัวอื่นก็ตาม ทำความเข้าใจความแตกต่าง แล้วเวลาใช้จะไม่งง
หลักๆเลย Git ต่างกับ VCS อื่นๆ (Subversion และเพื่อนๆ) ตรงที่วิธีที่ Git มองข้อมูลที่มันเก็บ โดยคอนเซปแล้ว ระบบอื่นๆจะเก็บข้อมูลในรูปของ listของความเปลี่ยนแปลง ระบบเหล่านี้ (CVS, Subversion, Perforce, Bazaar ฯลฯ) คิดว่าข้อมูลที่มันเก็บคือ set ของ files และความเปลี่ยนแปลงที่เกิดขึ้นกับแต่ละ file ในเวลาที่ดำเนินไป ดังเช่นตัวอย่างในรูป Figure 1-4.
Insert 18333fig0104.png Figure 1-4. Other systems tend to store data as changes to a base version of each file.
Git ไม่ได้มองหรือจำข้อมูลที่มันเก็บอย่างนั้น ในทางกลับกัน Git มองข้อมูลมันเหมือนกับเป็น set ของ snapshots ของ filesystem ขนาดจิ๋ว ทุกๆครั้งที่คุณ commit หรือ save project ใน Git มันจะถ่ายรูปว่า files ของเราหน้าตาเป็นไง ณ บัดนั้น และเก็บ reference ไปยัง snapshot (รูปถ่าย) นั้น และเพื่อให้มีประสิทธิภาพ ถ้า file ไม่ถูกแก้ไข Git จะไม่จำ file นั้นๆซ้ำ แค่เก็บ link ไปยัง file เก่าที่เหมือนกันเป๊ะๆ ที่มันเคยจำไว้แล้วเฉยๆ Git มองข้อมูลท่มันเก็บเหมือนดังภาพ Figure 1-5.
Insert 18333fig0105.png Figure 1-5. Git stores data as snapshots of the project over time.
นี่ความความแตกต่างที่สำคัญระหว่าง Git และ VCSs อื่นๆเกือบทั่วโลก มันทำให้ Git ต้องคิดใหม่ ทำใหม่เกือบทุกๆอย่าง ขณะที่ระบบอื่นๆแค่ copy มาจากรุ่นก่อนๆ มันทำให้ Git เหมือนเป็น filesystem ขนาดจิ๋วที่มากับ tools อันทรงพลังที่สร้างขึ้นมาครอบมันมากกว่าที่จะเป็นแค่ VCS ธรรมดา เด๋วเราค่อยมาโชว์ของดีที่ได้จากการมองข้อมูลในลักษณะนี้ในหัวข้อ branching ใน Chapter 3
ส่วนใหญ่แล้ว operation ใน Git ต้องการแค่ file และทรัพยากรบนเครื่องในการทำงาน ไม่จำเป็นต้องมีข้อมูลอื่นใดจากเครื่องอื่นๆใน network ถ้าคุณคุ้นเคยกับ CVCS ที่ operation ส่วนใหญ่ต้องทนกับความช้าของ network แล้วละก็ คุณจะรู้สึกราวกับว่าเทพแห่งความเร็วนั้นอวยพร Git ด้วยความเร็วส์ที่ไม่อายบรรยาย เพราะว่าคุณมี history ทั้งหมดของ project เก็บอยู่ที่นี่ในเครื่องของตัวเอง operation ทั้งหลายแหล่จึงรวดเร็วทันใจ
ยกตัวอย่างเช่นการค้นหา history ของ project Git ไม่จำเป็นต้องวิ่งไป server เพื่อดึง history แล้วหิ้วกลับมาแสดงผลให้คุณ มันแค่อ่านจาก database บนเครื่องก็ได้แล้ว นั่นหมายความว่าคุณสามารถเห็น project history ได้ในอึดใจเดียว ถ้าอยากดูความเปลี่ยนแปลงที่เกิดขึ้นบน file ซักอันระหว่าง version ปัจจุบันกับเมื่อเดือนที่แล้ว Git สามารถค้นหา file เมื่อเดือนที่แล้วบนเครื่องแล้วคำนวนหาสิ่งที่เปลี่ยนแปลงไปให้ได้ทันที แทนที่จะต้องไปอ้อน server ที่อยู่ไกลๆให้คำนวนให้หรือไปขอ file เดือนก่อนจาก server แล้วค่อยเอามาคำนวน
นั่นหมายความว่าคุณแทบจะไม่มีอะไรที่ทำไม่ได้ในกรณีที่ไม่ได้ต่อเนตหรือต่อ VPN ไม่ว่าจะกำลังนั่งรถ นั่งเรือ นั่งเครื่องบินอยู่ ถ้ามีอะไรกระจุ๊กกระจิ๊กอยากทำก็สามารถทำแล้ว commit เก็บไว้ได้อย่างสบายอารมณ์ ไว้ต่อเนตได้เมื่อไหร่ก็ค่อย upload ถ้าสมมติอยู่บ้านแล้วไม่สามารถ set VPN ได้ ก็ยังจะทำงานได้อยู่ ถ้าเป็นระบบอื่นๆ จะทำให้ได้แบบนี้แทบจะเป็นไปไม่ได้ ถึงได้ก็เลือดตาแทบกระเด็นหล่ะ เช่นสมมติใช้ Perforce คุณแทบจะทำอะไรไม่ได้เลยถ้าไม่ต่ออยู่กับ server หรือกรณี Subversion และ CVS ถึงจะแก้ file ได้ ก็ commit ใส่ database ไม่ได้ (เพราะไม่ได้ต่อกับ database) ถึงเรื่องแค่นี้จะดูเป็นเรื่องเล็ก แต่ถ้าลองได้ใช้จริงจะรู้ว่าชีวิตมันรู้สึกแตกต่างกันขนาดไหน
ทุกอย่างใน Git ถูก checksum ก่อนจะถูก save และจะถูกอ้างอิงถึงด้วย checksum นั้นๆ นั่นหมายความว่าไม่มีทางที่จะมีข้อมูลใน file หรือ directory เปลี่ยนไปโดยที่ Git จะไม่รู้เรื่อง ความสามารถนี้ถูกฝังไว้ในแก่นลึกสุดใจของ Git และหล่อหลอมเข้ากับจิตวิญญาณของมัน คุณไม่มีวันเจอ file เสียหรือพังไประหว่างถ่ายโอนข้อมูลโดยที่ Git ตรวจจับไม่เจอแน่นอน
กลไกที่ Git ใช้ในการทำ checksum เรียกว่า SHA-1 hash ซึ่งเป็นเลขฐาน 16 ยาว 40 ตัวอักษรที่ถูกคำนวนมาจากเนื้อหาภายใน file หรือโครงสร้าง directory ภายใน Git SHA-1 hash มีหน้าตาประมาณนี้:
24b9da6552252987aa493b52f8696cd6d3b00373
คุณจะเห็นค่า hash เหล่านี้กระจายตัวอยู่ทั่ว Git มันถูกใช้เยอะมว้ากก เอาจริงๆแล้ว Git ไม่ได้เก็บข้อมูลเป็น file แต่เก็บลง database ซึ่งสามารถเข้าถึงข้อมูลได้ด้วยค่า hash ของเนื้อหาใน file
เมื่อคุณทำ action ใดๆใน Git เกือบทุกอย่างจะเป็นการเพิ่มข้อมูลลงไปใน Git database มันยากมากที่จะทำอะไรลงไปแล้ว undo ไม่ได้ คล้ายกับ VCS อื่นๆคือคุณยังสามรถทำ file หาย หรือว่าทำของเละเทะได้ ถ้าคุณยังไม่ได้ commit แต่เมื่อไหร่ที่คุณ commit ไปใน Git ซัก snapshot นึงแล้ว มันแทบจะไม่มีวันหายเลย โดยเฉพาะอย่างยิ่งเวลาคุณคอย push database ของคุณไปใส่ repository อื่นอย่างสม่ำเสมอ
การใช้ Git จึงกลายเป็นความบันเทิงเพราะเรารู้ว่าเราสามารถทำการทดลองอะไรก็ได้โดยไม่กลัวว่าจะทำอะไรพัง ไว้ค่อยมาเจาะลึกว่า Git เก็บข้อมูลยังไง และเวลาทำอะไรเละเทะไปแล้วจะกู้กลับมายังไงในบท “Under the Covers” ใน Chapter 9.
เอาล่ะ! ตั้งสมาธิให้ดี นี่คือแก่นของวรยุทธ์ที่จะต้องจำให้ขึ้นใจถ้าอยากให้การศึกษา Git เป็นไปอย่างราบรื่น Git มีสาม state หลักสำหรับ file ทุก file: committed, modified และ staged
Committed แปลว่าข้อมูลถูกจัดเก็บอย่างปลอดภัยใน database บนเครื่อง, Modified แปลว่าคุณได้แก้ file ไปแต่ยังไม่ได้ commit มันใส่ database, Staged แปลว่าคุณได้ mark file ที่ถูก modify ใน version นี้ให้มันถูก commit ใน snapshot หน้า
3 state นี้ชักนำให้เกิด 3 ก๊กใน Git project นั่นคือ Git directory, working directory, และ staging area
Insert 18333fig0106.png Figure 1-6. Working directory, staging area, and git directory.
Git directory คือที่ที่ Git เก็บ metadata และ object database สำหรับ project ของคุณ นี่คือส่วนที่สำคัญที่สุดของ Git และมันคือสิ่งที่ถูก copy มาเวลาที่คุณ clone repository มาจาก computer เครื่องอื่น
working directory คือ checkout อันหนึ่งๆของซัก version นึงของ project ซึ่ง file เหล่านี้จะถูกดึงออกมาจาก compressed database ใน Git directory และเอามาวางบน disk ให้คุณใช้หรือว่าแก้ไขมัน
staging area คือ file ธรรมดาไม่ซับซ้อน ซึ่งจะอยู่ใน Git directory ของคุณ มันจะเก็บข้อมูลว่าอะไรบ้างที่จะถูกรวมไปใน commit ถัดไป บางคนก็เรียกมันว่า index แต่คนส่วนใหญ่จะเรียกมันว่า staging area
โดยเบสิคแล้ว flow ของ Git จะดำเนินไปดังนี้:
- คุณแก้ไข file ใน working directory
- คุณ stage file เหล่านั้น (เพิ่ม snapshot ของ file เหล่านั้นใน staging area ของคุณ)
- คุณ commit ซึ่งเป็นการเอา snapshot ของ file นั้นๆใน staging area มา save เก็บไว้ Git directory ตลอดกาล
ถ้า file ซัก version นึงถูกเก็บลง git directory แล้ว file นั้นจะมีสถานะ committed ถ้ามันโดนแก้และถูก add เข้าไปใน staging area มันจะมีสถานะ staged ถ้ามันถูกแก้ไขเฉยๆไปจากตอนที่ถูก check out แต่ยังไม่เคยถูก stage มันจะมีสถานะ modified ใน Chapter 2 คุณจะเข้าใจ state ทั้ง 3 นี้เพิ่มขึ้น และได้เรียนรู้วิธีที่จะใช้ประโยชน์จากพวกมันและวิธีการลัดข้ามส่วน staged ไปเลย
มาเริ่มใช้ Git กันเหอะ อันดับแรกเลยคือต้องติดตั้งมันก่อนซึ่งสามารถทำได้หลายหลาย แต่สองทางหลักๆคือ ติดตั้งจาก source เลยหรือไม่ก็ติดตั้ง package ที่เตรียมไว้สำหรับ platform ของคุณ
ถ้าทำได้ ติดตั้งจาก source เลยก็ดี เพราะจะได้ version ล่าสุดซิงๆ แต่ละ version ที่ใหม่ขึ้นของ Git ชอบมี UI ใหม่ๆ เจ๋งๆมาให้ใช้ ฉะนั้นการใช้ version ล่าสุดมักจะเป็นหนทางที่แหล่มที่สุดถ้าสะดวกใจที่จะ compile จาก source อีกเหตุผลนึงคือ Linux distribution หลายๆอันมักจะมี package ที่ดึกดำบรรพ์ ฉะนั้น ถ้าคุณไม่ได้ใช้ distro ที่มันซิงมากๆหรือใช้ backports การ install จาก source น่าจะเป็นการเดิมพันที่คุ้มสุด
จะ install Git ได้ คุณต้องมี library ต่างเหล่านี้ที่ Git depends on: curl, zlib, openssl, expat และ libiconv ยกตัวอย่างเช่น ถ้าคุณใช้ OS ที่มี yum (เช่น Fedora) หรือ apt-get (เช่นพวกตระกูล Debian ทั้งหลาย) คุณสามารถใช้ command ข้างล่างนี้เพื่อ install พวก dependencies ทั้งหลายได้:
$ yum install curl-devel expat-devel gettext-devel \
openssl-devel zlib-devel
$ apt-get install libcurl4-gnutls-dev libexpat1-dev gettext \
libz-dev libssl-dev
เมื่อคุณมี dependencies ที่จำเป็นครบแล้ว ก็เดินหน้าลุยไปเอา snapshot ล่าสุดจาก Git web site ได้เลย:
http://git-scm.com/download
หลังจากนั้นก็ compile และ install:
$ tar -zxf git-1.7.2.2.tar.gz
$ cd git-1.7.2.2
$ make prefix=/usr/local all
$ sudo make prefix=/usr/local install
หลังจากขั้นนี้ คุณสามารถ download Git ผ่าน Git เองได้ด้วยเวลาอยาก update:
$ git clone git://git.kernel.org/pub/scm/git/git.git
ถ้าอยากติดตั้ง Git บน Linux ผ่าน installer คุณก็ทำได้ง่ายๆผ่าน package-management tool ที่มากับ distribution ของคุณ เช่นถ้าใช้ Fedora ก็ yum เอาตามนี้:
$ yum install git-core
หรือถ้าใช้ตระกูล Debian อย่าง Ubuntu ก็ apt-get เอา:
$ apt-get install git-core
มีทางง่ายๆ 2 ทางที่จะติดตั้ง Git บน Mac ที่ง่ายสุดคือใช้ graphical Git installer ซึ่งสามารถ download ได้จาก Google Code page (ตามรูป Figure 1-7):
http://code.google.com/p/git-osx-installer
Insert 18333fig0107.png Figure 1-7. Git OS X installer.
อีกทางคือติดตั้ง Git ผ่าน MacPorts (http://www.macports.org) ถ้าลง MacPorts ไว้อยู่แล้ว ก็ติดตั้ง Git ตามนี้
$ sudo port install git-core +svn +doc +bash_completion +gitweb
ไม่จำเป็นต้องลง extras ทั้งหมดก็ได้ แต่อย่างน้อยน่าจะลง +svn ไว้ในกรณีที่ต้องใช้ Git ร่วมกับ Subversion repository (ดูได้ใน Chapter 8).
ติดตั้ง Git บน Windows นี่โคตรง่าย msysGit project ทำวิธีติดตั้งง่ายๆไว้ แค่ download file installer (exe) จาก Google Code page แล้วก็ run มัน:
http://code.google.com/p/msysgit
หลังจากติดตั้งแล้ว คุณจะมีทั้ง version command-line (รวมทั้ง SSH client ที่จะได้ใช้ภายหลัง) และ GUI
หลังจากมี Git บนเครื่องแล้ว ต้อง customize Git environment ซักนิดก่อน ขั้นตอนนี้ทำแค่ครั้งเดียวพอ ถึง upgrade version ก็ไม่ต้องมานั่ง set ใหม่ ถ้าวันหลังอยากจะเปลี่ยนมันก็เปลี่ยนได้ตลอดเวลา แค่ run command ซ้ำแค่นั้นเอง
Git มากับ tool ที่เรียกว่า git config เปิดช่องให้ get หรือ set ตัวแปร configuration ที่ควบคุมการหน้าตา, คำสั่ง และทำงานของ Git ได้ ตัวแปรเหล่านี้ถูกแบ่งเก็บใน 3 ที่ดังนี้:
- file
/etc/gitconfig: เก็บข้อมูล user ทุกคนในระบบรวมถึง repository ทั้งหลาย ถ้าคุณส่ง option--systemให้git configมันจะอ่านหรือเขียนใน file นี้ตรงๆ - file
~/.gitconfig: เป็น file เฉพาะของ user คุณเท่านั้น สามารถเจาะจงให้ Git เขียนหรืออ่าน file นี้ได้โดยการส่ง--globaloption ให้มัน - config file ใน git directory (ซึ่งอยู่ที่
.git/config) ของ repository ใดๆที่คุณใช้งาน: เฉพาะเจาะจงกับ repository นั้นๆ แต่ละ level คอยบังค่าที่ set ใน level ก่อนๆ ฉะนั้น ค่าที่ set ไว้ใน.git/configก็จะบังค่าใน/etc/gitconfig
บน Windows นั้น Git อ่านค่าใน file .gitconfig ใน $HOME directory (ส่วนใหญ่จะอยู่ที่ C:\Documents and Settings\$USER) มันดูค่าใน /etc/gitconfig ด้วยเหมือนกัน แต่ต้องอ้างอิงกับ MSys root ซึ่งจะอยู่ที่ที่คุณ ลง Git ไว้ตอนที่ run installer
อย่างแรกที่ควรทำหลังจากลง Git คือการ set user name และ e-mail address ของคุณ ที่มันจำเป็นเพราะทุกๆ commit ใน Git จะใช้ข้อมูลนี้และมันจะถูกสลักลงไปในแต่ละ commit ที่คุณส่ง:
$ git config --global user.name "John Doe"
$ git config --global user.email johndoe@example.com
ย้ำอีกครั้ง คุณจำเป็นต้อง set ค่าเหล่านี้แค่ครั้งเดียวถ้าคุณใช้ option --global เพราะ Git จะใช้ข้อมูลนั้นสำหรับทุกๆ action ที่คุณใช้บน system นั้น ถ้าอยากทับค่านั้นด้วชื่อหรือ e-mail address อื่น สำหรับบาง project คุณก็ทำได้โดยการ run command แล้วไม่ต้องส่ง option --global เข้าไปเวลาคนทำ project นั้น
หลังจาก setup Identity ของคุณแล้ว คุณก็สามารถเลือก default text editor ที่จะถูกเลือกใช้เวลา Git ต้องการให้คุณพิมพ์ message ได้ โดยปรกติแล้ว Git จะใช้ default editor ของระบบคุณ ซึ่งส่วนใหญ่จะเป็น Vi หรือ Vim ถ้าคุณอยากใช้ตัวอื่นเช่น Emacs ก็ทำได้ตังนี้:
$ git config --global core.editor emacs
อีก option นึงที่คุณน่าจะอยาก config คือ default diff tool เพื่อใช้ในการแก้ conflict ตอน merge สมมติว่าคุณอยากใช้ vimdiff:
$ git config --global merge.tool vimdiff
Git รองรับ kdiff3, tkdiff, meld, xxdiff, emerge, vimdiff, gvimdiff, ecmerge และ opendiff คุณสามารถ setup custom tool อื่นๆได้ด้วย ไปตามอ่านใน Chapter 7 ละกันว่าทำยังไง
ถ้าอยาก check settings ของคุณ คุณสามารถใช้คำสั่ง git config --list เพื่อจะ list settings ทั้งหลายแหล่ที่ Git มี ณ ตอนนั้นมาให้ดูได้:
$ git config --list
user.name=Scott Chacon
user.email=schacon@gmail.com
color.status=auto
color.branch=auto
color.interactive=auto
color.diff=auto
...
บาง key อาจจะซ้ำเพราะ Git อ่านค่า key เดียวกันจาก file ต่างๆ (เช่นจาก /etc/gitconfig และ ~/.gitconfig เป็นต้น) ในกรณีนั้น Git จะใช้ค่าสุดท้ายที่มันเห็น
คุณตรวจสอบได้ด้วยว่า Git มันกำลังคิดว่าค่าของ key นั้นๆเป็นอะไรโดยพิมพ์ว่า git config {key}:
$ git config user.name
Scott Chacon
ถ้าต้องการความช่วยเหลือขณะใช้ Git มี 3 ทางที่จะดู help สำหรับ command ใดๆของ Git ใน manual page (manpage):
$ git help <verb>
$ git <verb> --help
$ man git-<verb>
เช่นถ้าอยากดู help สำหรับคำสั่ง config ใน manpage ก็แค่
$ git help config
command แบบนี้มันเจ๋งตรงที่เรียกจากตรงไหนก็ได้แม้ว่าจะไม่ได้ต่อเนตก็ตาม
ถ้า manpage ทั้งหลายและหนังสือเล่มนี้ยังเอาไม่อยู่และคุณต้องการคนช่วย ให้ลองไปที่ Freenode IRC (irc.freenode.net) ที่ห้อง #git หรือ #github ดู ห้องเหล่านี้โดยปรกติจะมีคนเป็นร้อยๆที่มีความรู้เรื่อง Git และชอบช่วยเหลือ
น่าจะพอเห็นภาพคร่าวๆว่า Git คืออะไรและมันต่างกับ CVCS ที่คุณเคยใช้ๆมายังไง และตอนนี้คุณน่าจะมี Git version ที่พร้อมใช้งานและมีข้อมูลส่วนตัว setup เรียบร้อยอยู่บนเครื่องแล้ว ถึงเวลาตะลุย basic ของ Git ซะที!