รวมคำศัพท์ที่คนใช้ Git ต้องรู้จัก

Fri, 31 Mar 2023

Three-stages of git

การทำงานกับ Git เบื้องต้นสิ่งที่ต้องเข้าใจคือ git จะกำหนด stage หรือสถานะของไฟล์เราไว้ใน 3 stage นี้คือ

Untracked มีไฟล์อยู่แต่ยังไม่ได้เข้าไปอยู่ในการดูแลของ Git
Staged ไฟล์ถูกเก็บเข้าไปไว้ใน version control ของ git แล้วแต่การเปลี่ยนแปลงล่าสุดยังไม่ถูก commit
Committed การเปลี่ยนแปลงต่างๆ ถูกจัดเก็บไว้ใน repository แล้วเรียบร้อย

หลังจาก commit แล้วการเปลี่ยนแปลงจะถูกเก็บไว้ที่ local เราต้อง git push เพื่อให้การเปลี่ยนแปลงนั้นถูกส่งขึ้นไปเก็บไว้บน server

เราสามารถตรวจสอบ stage ของไฟล์ใน repository ได้ด้วยคำสั่ง

git status

Branch

การแตก branch เป็นสิ่งที่ทำให้ git เป็นมากกว่าการ backup และ restore แต่ branch จะทำเราสามารถแยก line การพัฒนาออกจากกันได้ เช่น version free และ version ที่ขาย subscription แต่ละ branch จะแยก stage และ history ของไฟล์ออกจากกัน ดังนั้นการเปลี่ยน stage และ history ของไฟล์จะเกิดขึ้นที่ branch ปัจจุบันเท่านั้น ตอนที่เราแตก branch ออก เหมือนเรา copy code ออกมาอีก folder

อ่านต่อได้ที่

git command ต่างๆที่ใช้ในการจัดการ branch

Centralized workflow

เป็น workflow หรือขั้นตอนการทำงานของ developer ที่ง่ายและไม่ซับซ้อนเหมาะสำหรับผู้เริ่มต้นใช้งาน git โดยเฉพาะผู้ที่ย้ายมาจาก Subversion หรือ TFVC(Team Foundation Version Control) โดยที่ flow นี้จะยอมให้ทุกคนใน team สามารถ commit เข้ามาใน repository ได้เลย

ในระยะยาวเราจะสามารถ control quality ของ code จาก workflow นี้ได้ยาก

Featured branch workflow

Feature branch คือ การแตก branch ออกไปตาม feature ต่างๆ ซึ่งใน feature branch จะทำให้เกิด pull request ขึ้นตอน merge กลับทำให้เกิดการสื่อสารขึ้นมาในขั้นตอนนี้ เช่นตอน merge feature นี้เข้ามาเราจะสามารถควบคุม quality ของ code ใน feature ใหม่ที่กำลังจะเข้ามานี้ได้

Forking

การ fork คือการแยก server-side repository ออกตาม developer โดยที่แต่ละคนจะมี repository ของตัวเอง(เหมือนใน github) แทนที่จะให้ทุกคนทำงานอยู่บน server-side repository ตัวเดียวกัน

developer ทุกคนจะมีคนละ 2 repositories คือ private local และ public server-side repository

Gitflow

Gitflow เกิดขึ้นมาจากบทความ A successful git branching model ซึ่งถูกเขียนขึ้นมาตั้งแต่ปี 2010 โดย Vincent Driessen ซึ่งใน gitflow จะมีการแบ่ง branch ออกเป็น 2 กลุ่มคือ

Main branches เป็น long-lived branch(อยู่ถาวร) โดยที่ main branch นั้นจะมีอยู่ 2 branches คือ
- dev branch จะเป็น branch หลักในการทำงาน เวลาจะดู history จะดูที่ branch นี้
- master branch เราจะ merge กลับมาที่ master branch เมื่อมีการ release เพราะฉะนั้น HEAD ของ branch นี้ต้องพร้อมสำหรับการ deploy ไปยัง production เมื่อเราต้องการย้อนกลับไปยัง version ก่อนหน้าเราจะมาดูที่ branch นี้
Supporting branches เป็น short-lived branch(อยู่ชั่วคราว) ซึ่งจะประกอบไปด้วย

feature branches เป็นกลุ่มของ branch ที่แตกออกมาเพื่อสร้าง feature ใหม่หลังจากนั้นเมื่อทำเสร็จแล้วจะทำการ merge กลับไปที่ dev branch
release branches เราจะแตก branch ออกมาตาม release เป็นการเตรียมก่อนที่จะ merge กลับเข้าไปที่ master เมื่อเราแตก release branch ออกมาเราจะไม่เพิ่ม feature ใดๆเข้าไปใน release branch อีกแล้ว เราจะแก้ bug หรือ defect ให้เรียบร้อยแล้วเท่านั้น หลังจากนั้นเมื่อพร้อมแล้วเราก็จะ merge กลับไปที่ master branch
hotfix branches เราจะแตก branch ออกมาเพื่อทำการแก้ไข bug หรือ defect ต่างๆ

Supporting branch จะมีได้มากกว่า 1 branch เช่น feature branch จะแตกออกมาตาม feature ที่กำลังพัฒนา ซึ่งอาจมีมากกว่า 1 feature ก็ได้

ใน gitflow จะมี main branches อยู่ 2 branches คือ dev branch และ master branch ซึ่งเป็น long-lived branch(อยู่ตลอดไป) ซึ่งจะผิดไปจากหลักการ เพราะเมื่อเรามี continuous integration เราควรจะต้องมี long-lived branch เพียง branch เดียวเท่านั้น

Githubflow

Githubflow น่าจะเป็น git workflow ที่นิยมใช้มากที่สุดเพราะเป็น workflow ที่เหมาะกับการทำงานที่มีหลายๆทีมมาทำงานร่วมกัน

ขั้นตอนของ githubflow นั้นจะประกอบไปด้วย

Create branch สร้าง branch ออกมาซึ่งอาจเป็น feature branches หรือ hotfix ก็ได้

ในกรณีที่ไม่ได้อยู่ในทีมเดียวกันเราจะใช้การ fork repository ออกมาแทน
Make changes หลังจากสร้าง branch ขึ้นมาแล้วเราก็ทำการเพิ่ม feature หรือแก้ไข defect ให้เรียบร้อย
Create pull request เราจะไม่ให้ developer merge code กลับเข้าไปใน master branch ตรงๆ ต้องบังคับให้ส่ง pull request มาเท่านั้น developer ต้องไม่มีสิทธิ merge code เข้าไปใน master branch ได้
Reviewing changes ส่วนนี้จะสร้างความแตกต่างให้กับ githubflow เพราะในเครื่องมือสมัยใหม่ทั้ง github, gitlab หรือ azure devops ล้วนแล้วแต่จะช่วยให้เราสื่อสารกับเพื่ิอนร่วมทีมได้ง่ายขึ้นทั้งการ comment และการ mention เพื่อนร่วมทีม(เหมือนใน social media ต่างๆ) ควรจะมีการ review code หรือตรวจสอบคุณภาพของ source code ในขั้นตอนนี้

ควรจะมี maintainer ที่คอยดูแล code ชุดนี้โดยเฉพาะ
Merge pull request เมื่อทุกอย่างพร้อมแล้วเราก็จะทำการ merge กลับไปที่ master branch ซึ่งเราควรจะมี build pipline และ release pipeline สำหรับการ merge pull request โดยเฉพาะ

githubflow นั้นค่อนข้างเรียบง่ายไม่ซับซ้อน แถมยังช่วยกระตุ้นให้เกิดการสื่อสารกันภายในทีมมีมากขึ้นด้วย

Gitlabflow

gitlab workflow นั้นอาจไม่ได้รับความนิยมเท่ากับ githubflow แต่เป็นอีกหนึ่งแนวคิดที่น่าสนใจ เพราะมีการแตก branch ออกไปตาม environment ต่างๆ ซึ่งจุดนี้ทั้่ง githubflow และ gitflow ก็ไม่ได้พูดถึง

จากรูปจะเห็นว่า gitlab flow ทำการแตก branch ออกมาตาม environment ต่างๆ จาก staging -> pre-prod -> production ซึ่งถ้าเราอยากรู้ว่า code ชุดไหนที่อยู่บน production ล่าสุด ก็สามารถไปดูที่ production branch ได้เลย ซึ่งจริงๆแล้วเราอาจไม่ต้องมีครบทุก environment แบบนี้ก็ได้

สิ่งที่ทำให้ gitlabflow ต่างๆจาก githubflow คือ gitlabflow จะสามารถประยุกต์ได้กับ application ที่ไม่ได้มี continuous deployment คือไม่ได้ deploy ตลอดเวลา เช่น mobile application หรือ windows application ได้ด้วย

HEAD

HEAD เป็นเหมือน pointer ที่ทำการชี้ว่า version ปัจจุบันอยู่ที่ branch หรือ commit ไหน ทุกครั้งที่เรา checkout git จะทำการ update HEAD ให้ชี้ไปยัง commit ล่าสุดของ branch ที่เราเลือก แต่ถ้าเรา checkout commit ที่ไม่ใช่ commit ล่าสุด git จะทำการเปลี่ยน state เป็น “detached HEAD” ทันที

Detached HEAD

เป็นสถานะที่ HEAD ชี้อยู่ที่ commit ที่ไม่ใช่ commit ล่าสุดซึ่งการเปลี่ยนแปลงที่เกิดขึ้นหลังจาก commit นี้จะถูกแยกออกเป็นอีก branch หนึ่งไม่ได้อยู่ที่ branch เดิมอีกแล้ว

อ่านต่อได้ที่

Detached HEAD คืออะไรและแก้ยังไง

Hook

Hook มีไว้สำหรับการทำงานแบบอัตโนมัติต่างๆ เมื่อมีเหตุการณ์ต่างๆ เกิดขึ้น เช่นเมื่อมีการ commit code เข้ามาใน repository จะให้ trigger build pipeline ใน Jenkins โดยอัตโนมัติ

Hook มีไว้สำหรับการสร้าง action ต่างๆที่เกิดขึ้นในระหว่างการ develop

Pull Request (Merge Request)

Pull request หรือ Merge request คือการบังคับให้ผู้ที่ต้องการนำ code ที่เขียนขึ้นมาใหม่เข้ามารวมกับ code ของเก่านั้นต้องทำการส่งคำร้องมาก่อน ซึ่งในการทำงานของ pull request model นั้นจะต้องมี maintainer ที่คอยดูแลคุณภาพของ code ใน repository เพียงคนเดียว(หรือมีให้น้อยที่สุดเท่าที่จะมีได้ แต่ต้องมี) หลังจากนั้นผู้ร่วมทีมทั้งหมดจะเป็นเพียง developer ที่มีสิทธิแค่แตก branch ออกไปสร้าง feature ใหม่ หรือ hotfix เท่านั้น และเมื่อ developer ต้องการ merge code กลับเข้า main branch ก็ต้องส่ง pull request ไปยัง maintainer เพื่อให้ maintainer ตรวจสอบลคุณภาพของ source code ก่อน

Pull request ถือว่าเป็น feature ที่ต้องมีในผู้ให้บริการ server-side repository ทุกๆยี่ห้อ เพราะ pull request ถือว่าเป็น best practices ที่ต้องทำในปัจจุบัน

Rebase

Rebase คือการนำ commit ที่อยู่ใน branch นึงไปใส่ในอีก branch นึง จะคล้ายๆกับการ merge แต่การ merge จะเป็นการสร้าง commit ขึ้นมาใหม่เพื่อรวม coded ของทั้ง 2 branches เข้าด้วยกัน แต่ rebase จะเป็นการ copy เอา commit จาก branch ต้นทางไปำไว้ยัง branch ปลายทาง(การ rebase จะไม่เกิด commit ใหม่)

นอกจากการ rebase ระหว่าง branch แล้วเรายังสามารถใช้ git rebase ในการรวม commit เข้าด้วยกันได้ด้วย เวลา push ขึ้นไปบน server commit จะได้ไม่เยอะมากเกินไป

Tag

เป็น reference ที่ระบุว่าใน commit นี้ เป็น version อะไร ซึ่งการระบุ tag จะทำให้เราระบุ version ตอน restore กลับมาได้ง่าย และใน build pipeline เราสามารถเลือก job หรือ task สำหรับ tag โดยเฉพาะได้ เช่น เราจะ scan source code ด้วย sonarqube เฉพาะตอนที่มี tag เท่านั้น ซึ่งจะช่วยประหยัดเวลาในการ build ได้

Version Control

ระบบที่ทำการบันทึกการเปลี่ยนแปลงของ file และ folder ต่างๆ เมื่อเวลาผ่านไปเราสามารถที่จะย้อนกลับไปใน version ก่อนหน้าได้

Working tree

เป็น files หรือ folders ที่ถูก checkput ลงมาทำงานอยู่ ณ ปัจจุบัน ซึ่งการเปลี่ยนแปลงที่เกิดขึ้นจะยังไม่ถูก commit

อ่านต่อเพิ่มเติมได้ที่นี่