การใช้งาน Git และ GitHub

บทแทรก 3.5

แปลไปแล้ว

ในบทนี้ คุณจะได้

  • เรียนรู้วิธีการใช้ GitHub เพื่อทำตามหนังสือ
  • GitHub คือ เว็บที่ให้บริการพื้นที่จัดเก็บโครงการโอเพ่นซอร์สด้วยระบบควบคุมเวอร์ชันแบบ Git โดยมีจุดประสงค์หลักคือ ทำให้การแบ่งปันและพัฒนาโครงการต่างๆด้วยกันเป็นไปได้ง่ายๆ ในบทแทรกนี้ เราจะมาดูวิธีการหลายๆอย่างที่คุณสามารถใช้ GitHub เพื่อทำตามที่หนังสือ Discover Meteor บอกได้

    โดยบทแทรกนี้จะสมมุติว่าคุณไม่คุ้นเคยกับการใช้ Git หรือ GitHub มาก่อน แต่ถ้าคุณใช้มันได้คล่องแล้ว ก็ให้ผ่านไปที่บทถัดไปได้เลย

    เมื่อถูกคอมมิท

    การทำงานพื้นฐานของ Git ก็คือการ คอมมิท คุณสามารถมองได้ว่า คอมมิทก็คือภาพถ่ายโค้ดของโปรแกรมคุณในขณะหนึ่ง

    แทนที่เราจะให้คุณเห็นโค้ดสำเร็จของแอพ Microscope ในครั้งเดียว เราก็ถ่ายภาพโค้ดของโปรแกรมไว้ทีละขั้นจนครบทุกขั้น ซึ่งคุณสามารถเข้าไปดูออนไลน์ได้ที่ GitHub

    โดยตัวอย่างที่คุณเห็นนี้ก็คือ คอมมิทตัวสุดท้ายของบทเรียนก่อนหน้านี้

    A Git commit as shown on GitHub.
    A Git commit as shown on GitHub.

    สิ่งที่คุณเห็นคือ “ดิฟ” (มาจาก “difference”) หรือ “ส่วนต่าง” ของไฟล์ post_item.js ซึ่งก็คือ การเปลี่ยนแปลงที่เกิดจากคอมมิทนี้ ในกรณีนี้เกิดจากที่เราสร้างไฟล์ post_item.js ขึ้นมาใหม่ ดังนั้นโค้ดทั้งหมดจึงถูกเน้นด้วยสีเขียว

    ตอนนี้ลองมาเปรียบเทียบกับตัวอย่างจาก โค้ดในหนังสือหลังจากบทนี้

    Modifying code.
    Modifying code.

    จะเห็นว่าตอนนี้ มีแค่เพียงบรรทัดที่ถูกแก้ไขเท่านั้นที่ถูกเน้นด้วยสีเขียว

    และแน่นอนว่าบางครั้งคุณไม่ได้เพิ่มหรือแก้ไขโค้ด แต่ ลบมันออกไป

    Deleting code.
    Deleting code.

    ที่เราได้เห็นก็คือ วิธีการใช้ GitHub อย่างแรก เพื่อตรวจดูว่ามีอะไรเปลี่ยนแปลงในโค้ดบ้าง

    ดูโค้ดตอนที่คอมมิท

    หน้าคอมมิทของ Git แสดงให้เราเห็นการเปลี่ยนแปลงทั้งหมดที่เกิดขึ้นกับคอมมิทนี้ แต่บางครั้งเราอาจต้องการเห็นไฟล์ในตอนที่ยังไม่ถูกแก้ไขเพื่อให้แน่ใจว่าโค้ดมีหน้าตาเป็นอย่างไรในตอนนั้น

    GitHub ก็ยอมให้เราทำแบบนั้นได้ โดยเมื่อคุณอยู่ที่หน้าคอมมิท ให้คลิ๊กที่ปุ่ม Browse code

    The Browse code button.
    The Browse code button.

    คุณก็จะเข้าไปในพื้นที่เก็บไฟล์ ณ ตอนที่คอมมิทนั้นเพิ่งเกิดขึ้น

    The repository at commit 3-2.
    The repository at commit 3-2.

    ถึงแม้ GitHub ไม่ได้แสดงให้เราเห็นว่าเรากำลังดูอยู่ที่คอมมิท แต่คุณก็สามารถที่จะเปรียบเทียบกับหน้า “ปกติ” และเห็นได้ว่าโครงสร้างไฟล์แตกต่างออกไป

    The repository at commit 14-2.
    The repository at commit 14-2.

    เข้าถึงคอมมิทบนเครื่องคุณ

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

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

    git clone https://github.com/DiscoverMeteor/Microscope.git github_microscope
    

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

    ลอง cd เข้าไปในโฟลเดอร์ที่คุณโคลนมา เราจะได้ใช้คำสั่ง git กันดู

    cd github_microscope
    

    เมื่อเราโคลนพื้นที่จัดเก็บจาก GitHub เราก็ได้ดาวน์โหลดโค้ดของแอพ “ทั้งหมด” ลงมา และก็หมายความว่า เราอยู่ที่ตำแหน่งคอมมิทครั้งสุดท้าย

    แต่ยังดีที่เรามีวิธีย้อนเวลากลับไป แล้ว “เช็คเอาท์” โค้ดจากคอมมิทไหนออกมาก็ได้ โดยไม่ส่งผลต่อคอมมิทอื่น ลองดูกันดีกว่า

    git checkout chapter3-1
    Note: checking out 'chapter3-1'.
    
    You are in 'detached HEAD' state. You can look around, make experimental
    changes and commit them, and you can discard any commits you make in this
    state without impacting any branches by performing another checkout.
    
    If you want to create a new branch to retain commits you create, you may
    do so (now or later) by using -b with the checkout command again. Example:
    
      git checkout -b new_branch_name
    
    HEAD is now at a004b56... Added basic posts list template and static data.
    

    Git แจ้งให้เราทราบว่าตอนนี้เราอยู่ที่สถานะ “detached HEAD” ซึ่งหมายความว่า ตราบใดที่เราใช้ Git เราก็สามารถที่จะสำรวจคอมมิทในอดีตได้ แต่ไม่สามารถแก้ไขได้ คุณอาจเทียบมันได้กับ พ่อมดที่กำลังเพ่งสำรวจอดีตผ่านลูกแก้ววิเศษณ์อยู่

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

    เหตุผลที่คุณสามารถพิมพ์แค่ chapter3-1 ได้ ก็เพราะเราได้ติดแท็กที่คอมมิทต่างๆของ Microscope ด้วยหมายเลขตำแหน่งในบทเรียน ถ้าไม่มีตรงนี้ คุณก็ต้องหา hash ของคอมมิท (หรือหมายเลขเฉพาะของคอมมิท) มาใช้แทน

    ซึ่ง GitHub ก็ช่วยให้ชีวิตเราง่ายขึ้นอีกครั้ง คุณจะเห็น hash ของคอมมิทที่มุมขวาล่างของกล่องหัวเรื่องคอมมิท เหมือนที่แสดงในรูป

    Finding a commit hash.
    Finding a commit hash.

    ตอนนี้เรามาลองใช้ hash แทนแท็กดู

    git checkout c7af59e425cd4e17c20cf99e51c8cd78f82c9932
    Previous HEAD position was a004b56... Added basic posts list template and static data.
    HEAD is now at c7af59e... Augmented the postsList route to take a limit
    

    และสุดท้าย ถ้าเราไม่ต้องการมองเข้าไปในลูกแก้ว และต้องการกลับมาปัจจุบัน เราก็แค่บอก Git ว่าเราต้องการเช็คเอาท์จาก master

    git checkout master
    

    สังเกตุด้วยว่าเราสามารถที่จะรันแอพด้วยคำสั่ง meteor ที่ตอนไหนก็ได้ แม้แต่ตอนที่อยู่ในสถานะ “detached HEAD” โดยคุณอาจจำเป็นต้องรัน meteor updateในตอนแรก ถ้า Meteor เตือนว่ามีแพ็คเกจขาดหายไป เพราะว่าโค้ดของแพ็คเกจไม่ได้ถูกรวมไว้ในพื้นที่จัดเก็บของ Git

    ประวัติคอมมิท

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

    ขั้นแรกให้เปิดไฟล์ในพื้นที่จัดเก็บของคุณบน GitHub ซักตัวนึง จากนั้นก็กดที่ปุ่ม “History”

    GitHub's History button.
    GitHub’s History button.

    คุณก็จะเห็นรายการคอมมิททั้งหมดที่เกิดขึ้นกับไฟล์นั้น

    Displaying a file's history.
    Displaying a file’s history.

    รู้นะว่าใครทำ

    ก่อนจะจบ เรามาดูที่ Blame กัน

    GitHub's Blame button.
    GitHub’s Blame button.

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

    GitHub's Blame view.
    GitHub’s Blame view.

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