บทความ IT เจ๋งๆ

วิธีใช้ Git ให้มีประสิทธิภาพมากที่สุด

05-ก.ย.-18

คัมภีร์เทพ IT

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

Git Workflows

เมื่อใดก็ตามที่มี Developer หลายคนที่มีส่วนร่วมใน Project มันจำเป็นอย่างยิ่งที่ต้องใช้ workflow ที่เหมาะสมสำหรับ Git โดยจากรูปด้านล่างจะเป็นตัวอย่างที่แสดงให้เห็นถึง Workflow ที่มีประสิทธิภาพในหนึ่ง Project ที่ประกอบด้วย Developer หลายคน

สมมติสถานการณ์:

หากคุณได้เป็นหัวหน้า Project โดยที่คุณกำลังวางแผนที่จะสร้าง Facebook โดยมีทีมงานที่เป็น Developer 3 คน:

Alice: นักศึกษาฝึกงานที่ยังใหม่กับการเขียน Program

Bob: มีประสบการณ์ 1 ปีและมีความรู้เกี่ยวกับการเขียน Program

John: มีประสบการณ์ 3 ปีและมีความรู้เกี่ยวกับการเขียน Program เป็นอย่างดี

คุณ: ได้รับมอบหมายให้เป็นหัวหน้า Project นี้

Development Process ใน Git

Master branch

  1. Master Branch ควรมี Copy ของ Code ใน Production อยู่เสมอ
  2. ไม่ควรมีใคร รวมทั้งหัวหน้า Project ที่มีสิทธิ์ Code ลงไปโดยตรงใน Master branch เนื่องจากเป็นตัว Copy ของ Production Code
  3. Code จริง ควรถูกเขียนอยู่ใน branch อื่นๆ

Release branch

  1. เมื่อเริ่มต้น Project สิ่งแรกที่ต้องทำ คือการสร้าง Release branch สำหรับ Project ซึ่ง Release branch นี้ถูกสร้างขึ้นจาก Master Branch
  2. Code ทั้งหมดที่เกี่ยวข้องกับ Project นี้จะอยู่ใน Release branch ซึ่ง Release branch จะเป็น branch ที่ขึ้นต้นด้วย release/
  3. Release branch สำหรับตัวอย่างนี้ คือ release/fb
  4. เป็นไปได้ว่ามีหลาย Project ที่กำลัง Running อยู่บน Code base เดียวกัน ดังนั้น สำหรับแต่ละ Project จะมีการสร้าง Release branch แยกกันออกไป สมมติว่ามีอีกหนึ่ง Project ที่กำลัง Running อยู่พร้อมกัน จากนั้น Project ดังกล่าวอาจมี Release branch ที่แยกออกมา เช่น release/messenger
  5. สาเหตุที่มี Release branch ก็เพื่อให้ Code base เดียวกัน สามารถมีหลาย Project ที่ Running ไปพร้อมๆ กันได้ แต่ก็ไม่ควรมี Conflict กันในแต่ละ Project

Feature branch

  1. สำหรับทุก Feature ที่สร้างขึ้นใน Application จะมีการสร้าง Feature branch แยกไว้ เพื่อให้มั่นใจว่า Feature สามารถถูกสร้างได้อย่างเป็นอิสระต่อกัน
  2. Feature branch ก็คล้ายกับ branch อื่นๆ แต่ขึ้นต้นด้วย feature/
  3. ในฐานะที่คุณซึ่งเป็นหัวหน้า Project ได้ขอให้ Alice สร้าง Login Screen สำหรับ Facebook ดังนั้น Alice จึงสร้าง Feature branch ใหม่ขึ้นมา โดยเรียก Feature branch นี้ว่า feature/login และ Alice จะเขียน Code สำหรับ Login ทั้งหมดไว้เฉพาะใน Feature branch นี้เท่านั้น
  4. สำหรับ Feature branch แล้ว โดยทั่วไปจะถูกสร้างขึ้นจาก Release branch
  5. ต่อไป Bob ได้รับมอบหมายให้สร้าง “Friend” request page ดังนั้น Bob จึงสร้าง Feature branch ที่ถูกเรียกว่า feature/friendrequest
  6. หน้าที่ของ John คือสร้าง News Feed ดังนั้น John จึงสร้าง Feature branch ที่เรียกว่า feature/newsfeed
  7. Developer ทุกคน จะทำการเขียน Code ลงไปใน Feature branch ของแต่ละคน
  8. ตอนนี้ สมมติว่า Alice ทำงานเสร็จแล้วและ Code ในส่วนของการ Login ก็พร้อมแล้ว ซึ่ง Alice จำเป็นต้องส่ง Code ของเธอไปยัง Release branch ที่ชื่อ release/fb จาก Feature branch ของเธอที่ชื่อ feature/login ซึ่งนี่เป็นการทำผ่านการ Pull request

Pull request

สิ่งแรกและสำคัญที่สุดคือ Pull request จะต้องไม่สร้างความสับสนกับ git pull โดย Developer จะไม่สามารถวาง Code ลงใน Release branch ได้โดยตรง หัวหน้า Project จำเป็นต้อง Review ตัว Feature code ก่อนที่จะส่งไปยัง Release branch ซึ่งเป็นการทำผ่าน Pull request อย่าง Alice เอง สามารถทำ Pull request ได้ดังนี้ใน GitHub

จากรูปด้านบน ทางด้านขวาถัดจาก Branch name จะมี Option ที่ชื่อว่า “New pull request” เมื่อคลิกปุ่มนี้ จะเปิด Screen ใหม่ ดังรูปด้านล่าง

จากรูปด้านบน

  • ใน Compare branch ควรจะเป็น Feature branch ของ Alice ซึ่งคือ feature/login
  • ใน Base branch ควรจะเป็น Release branch คือ release/fb

เมื่อทำเสร็จแล้ว Alice จำเป็นต้องใส่ Title และ Description สำหรับการ Pull request และจากนั้นก็คลิกที่ “Create Pull Request” โดย Alice จะต้อง Assign คนที่จะเป็นผู้ตรวจสอบ หรือ “Reviewer” สำหรับการ Pull request ครั้งนี้ด้วย ซึ่งเธอจะใส่ชื่อของคุณลงไปเป็น Reviewer (เนื่องจากคุณเป็นหัวหน้า Project นั่นเอง) จากนั้น หัวหน้า Project จะเป็นผู้ Review Code ในการ Pull request และต้องทำการ Merge Code จาก Feature branch ลงใน Release branch และตอนนี้คุณได้ Merge Code จาก feature/login branch ไปใน release/fb branch เรียบร้อยแล้ว ทำให้ Alice รู้สึก Happy ที่ Code ของเธอได้ถูก Merge เรียบร้อยเข้าสู่ Project

Code Conflicts

  1. Bob เขียน Code เรียบร้อยแล้วและทำการ Pull request จาก feature/friendrequest ไปยัง release/fb
  2. แต่เนื่องจาก Release branch มี Login code อยู่ ทำให้เกิด Code Conflict สำหรับกรณีนี้ จะเป็นหน้าที่ของคุณ ซึ่งเป็น Reviewer ที่จะต้องแก้ปัญหาเรื่อง Code Conflict และต้องทำการ Merger Code
  3. ขณะเดียวกัน John ก็เขียน Code เรียบร้อยแล้วและต้องการจะเพิ่ม Code ของเขาลงไปใน Release branch แต่เนื่องจาก John มีการจัดการที่ดีในเรื่อง Code Conflict ทำให้เขาใส่ Code ล่าสุดจาก release/fb branch ลงใน Feature branch ของเขาเอง คือ feature/newsfeed (ไม่ว่าจะผ่าน git pull หรือ git merge ก็ตาม) ซึ่ง John ได้ทำการแก้ไขปัญหา Conflict ทั้งหมดที่มีอยู่เรียบร้อยแล้ว ขณะนี้ feature/newsfeed branch ได้มี Code ล่าสุดทั้งหมดเหมือนใน release/fb แล้ว
  4. ในที่สุด John ก็ทำการ Pull request ซึ่งในขั้นตอนนี้ไม่เกิดปัญหา Code Conflict แต่อย่างใด เนื่องจากเขาแก้ปัญหาไปแล้วตั้งแต่ต้น

มี 2 วิธีในการแก้ปัญหา Code Conflict:

  1. ผู้ที่เป็น Reviewer ของการ Pull request จะต้องเป็นผู้แก้ปัญหา Code Conflict
  2. Developer เองต้องแน่ใจก่อนว่า Code ล่าสุดจาก Release branch ถูก Merge ลงไปใน Feature branch และทำการแก้ปัญหา Conflict ก่อนเสียตั้งแต่แรก

กลับมาสู่ Master branch

เมื่อ Project เสร็จแล้ว Code จาก Release branch ถูก Merge กลับเข้าไปใน Master branch จากนั้น Code จะถูก Deploy สู่ Production โดย Code ใน Production และ Code ใน Master branch จะมีการ Sync กันอยู่เสมอ ซึ่งช่วยทำให้แน่ใจว่า Code ที่ Update ล่าสุดจะอยู่ใน Master ด้วยเสมอ

Reference

หากคุณอยากทราบข้อมูลเพิ่มเติมเกี่ยวกับการ Pull request คลิกอ่านได้ ที่นี่

ที่มา:  https://medium.freecodecamp.org/

 

 

รับตำแหน่งงานไอทีใหม่ๆ ด้วยบริการ IT Job Alert

 

อัพเดทบทความจากคนวงในสายไอทีทาง LINE ก่อนใคร
อย่าลืมแอดไลน์ @techstarth เป็นเพื่อนนะคะ

เพิ่มเพื่อน

 

บทความที่เกี่ยวข้อง

ประเภทบทความ