github

Version Control ใช้ไปทำไม ใช้ไปเพื่ออะไร แล้วทำไมคุณยังไม่ใช้

Version Control ทีมคุณใช้งาน กันแล้วรึยัง? ในแต่ละวัน คุณคงจะเขียน Code เป็นร้อย เป็นพันบรรทัด บางครั้งทั้งวันก็ทำแค่ Project เดียว บางวันยุ่งๆ มีหลาย Project อีกต่างหาก คุณจัดการกับ Code เหล่านั้นกันอย่างไร

Version Control ใช้ไปทำไม ใช้ไปเพื่ออะไร แล้วทำไมคุณยังไม่ใช้

สมัยก่อน ตอนเริ่มต้น เขียน Code ใหม่ๆ ยังไม่มีใครมาไกด์ มาแนะนำ ว่าต้องทำอย่างไร ก็เขียนไปแต่ละครั้ง แต่ละวัน อยู่ดีๆคอมพังซะงั้น งานทั้ง Project หายไปหมดเลย ได้แต่แอบนั่งร้องไห้เงียบๆ จะส่งยังไงทัน

หลังจากนั้น เริ่มอ่านเยอะขึ้น เห็นคนอื่น เค้าเก็บบนอินเตอร์เน็ต ก็ไม่เข้าใจ คิดว่าคงแค่เก็บไฟล์ ทำงานเสร็จทีหนึ่งก็ save แล้วทำการ zip อัพขึ้นไปบนเมล์ แป๊บเดี๋ยวเต็ม

แถมพอ อยากจะลอง อะไรใหม่ๆ ต้องเอา code เดิมมานั่งแก้ พอจะ save ก็ตั้งชื่อใหม่จนปวดหัว

พอเอางานขึ้น ใช้จริงบน server ลูกค้า จำเป็นต้องแก้ไข เมื่อไหร่ ก็ต้องเบรคทั้งหมด แล้ว up ไฟล์งานใหม่ขึ้นไป

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

พอมีทีม เราจะต้องทำงานกัน หลายคนแล้ว จะมานั่ง ทำแบบเดิมๆไม่ได้ ระบบมันเดินไม่ได้ มันไม่โต ทำงานไม่สะดวก เห็นใครๆก็ใช้ Version Control กัน เลยเอาละ มาลองกันซักตั้ง

สมัยนั้น มีคนเริ่มเขียน Blog แชร์กันมากขึ้น น่าจะเป็นผลจากที่ WordPress เริ่มตั้งตัวได้ ก็เลยมีเรื่อง Version Control ให้อ่านกันเยอะ

แต่ต้องบอกตามตรง ผมมันคน Learning curve ยาวกว่าคนอื่นเยอะ ไอ้เรื่องที่คนอื่น เค้าเข้าใจกันง่ายๆในสองสามนาที นี่ผมนั่งทำเป็นเดือน กว่าจะเข้าใจ

Git คือชื่อของ Version Control ที่เราทำงานกัน ผ่านทาง bit bucket ไม่ได้ใช้ git hub เพราะว่าถ้าจะใช้เป็น private มันเสียเงิน แต่ตัว bit bucket ฟรี และเป็น private เหมาะสำหรับทีมขนาดเล็กอย่างเรา

Git ทำอะไรได้บ้าง?

การเข้ามาของ git ทำให้เราในทีม สามารถทำงานพร้อมๆกันได้ งานเดียวกัน Project เดียวกัน ที่สำคัญ ทำงานมันไฟล์เดียวกันยังได้

เวลาเราแบ่งงานกัน คนหนึ่งทำ HTML, CSS ฝั่ง frontent ไป อีกึนเข้ามาจบ Javascript ส่งข้อมูล ดึงข้อมูล เสร็จแล้วก็ up งานมารวมกัน

คนอื่นๆก็สามารถ ดึงลงไปใช้งานได้ เราสร้างระบบ login อีกคนก็ไปเขียน การนำเข้าสินค้า อีกคนก็ไปเขียนจัดชั้นวางสินค้า สุดท้ายเอามารวมกัน

เราสามารถแตก branch ออกไป ตามกิจกรรมของแต่ละคน ตามแต่ส่วนงานของแต่ละคน เสร็จแล้ว merge เข้าไปในส่วนของการเทส มีคนเทสเสร็จ เราก็ merge เข้าไปที่ develop branch รอเวลารวมร่างกับ master เพื่อ deploy ส่งลูกค้า

เมื่อลูกค้า ต้องการเพิ่มเติม feature ใหม่ๆเข้ามา แต่ไม่อยากให้ส่งผลกระทบ กับระบบเดิมที่ run อยู่ เราก็แค่แตก version ออกมาทำ แล้วให้เทสแยกไป เมื่อทุกอย่างลงตัว ค่อย merge รวมไปกับ master

เวลาจะส่งงานลูกค้า ในแต่ละครั้ง เราจะทำการ tag version ก่อนนำไปให้ลูกค้าดูเพื่อบอกว่า อันนี้นะ อันที่เท่าไหร่แล้ว ไม่เอาของตัว master ไปส่ง จะได้ตาม version ถูก

แบบนี้เป็นเรื่องพื้นฐาน ที่ git สามารถทำได้อยู่แล้ว ที่เหลือก็แค่ว่า เราจะเอามันออกไปใช้งานจริงๆรึเปล่า

หลายๆทีมงาน เลือกที่จะใช้ git ในการทำงานจริงๆ แต่ละเลย การรวม code ของแต่ละคนเข้าด้วยกัน แบบว่าทำไปที 5-6 วันค่อยรวมซักรอม เพราะรวมแล้วมันชอบพัง

อันที่จริงต้องบอกเลย ไม่มีหรอก ไอ้คำว่างานพังนะ อย่ามาหลอกตัวเอง มันเป็นข้ออ้าง คุณลองคิดดูง่ายๆนะ

ตัวอย่างนะ เช่น เมื่อคุณทำงาน อยู่กับ route file คุณสร้างเส้นทางใหม่ๆในการเข้าถึงระบบ อยู่ในเครื่องคุณคนเดียว ทำงานได้หมด ไม่มีปัญหา อยู่ดีๆ คุณอัพงานไป merge code รวมกับคนอื่นๆ ที่เค้าทำงานเหมือนกัน เค้าก็ใช้ไฟล์กลางๆ แบบนี้เหมือนกัน

ไฟล์ route หรือไฟล์กลางๆแบบนี้ จึงกลายเป็นไฟล์ที่ มีปัญหาบ่อยๆ เพราะทุกคน ทำงานพร้อมกัน ไฟล์เดียวกัน แต่มันไม่ได้พัง ระบบมันจะแค่ งง!! ว่าคุณ กับเพื่อนของคุณ เพิ่ม code เข้ามาในบรรทัดเดียวกัน แต่มันไม่เหมือนกัน คุณต้องตัดสินใจ ว่าจะตัดของใครออก หรือจะเก็บเธอไว้…ทั้งสองคน!!

ไอ้เรื่องแบบนี้ เค้าเรียกว่า การ conflict คือมันเกิดได้ง่ายๆและโคตรบ่อย สำหรับไฟล์ที่ ใครๆก็ใช้กันตลอด แต่มันไม่ได้ใหญ่โตอะไร แค่รู้จักมัน ทำความเข้าใจมัน

วันนี้มาแชร์เรื่อง version control เพราะอยากให้ คนที่ยังใช้งานไม่เป็น หรือกลัว ไม่กล้าเข้ามาตรงนี้ ได้ลองใช้งานดู มันจะช่วยคุณได้เยอะ ไม่ว่าคุณจะทำงานเป็นทีม หรือทำงานคนเดียวก็ตาม

วันเสาร์นี่ ยาวตลอดเลย… หวังว่าจะสนุก กับการเขียน code ทุกวัน และอย่าลืม commit แล้ว push ทุกครั้งนะครับ

ขอบคุณที่ติดตามกันมาตลอดครับ

อ้างอิง

Version Control github

github

bitbucket

bitbucket