จากตอนที่แล้วผมบุ่มบ่ามมาพูดถึง Workflow ทั้งๆ ที่คนอ่านนั้นอาจจะไม่รู้เลยด้วยซ้ำว่าการแตก Branching หรือการรวม Merging และจากประสบการณ์ไปสอนกลุ่มย่อยๆ 2 กลุ่มทำให้รู้ว่า เรื่อง Branching/Merging เป็นเรื่องที่สอนให้คนเข้าใจจริงๆ ยากที่สุด และมีเวลาสอนน้อยสุดเพราะเป็นเรื่องหลังๆ เลยงั้นคราวนี้ ผมจะไล่ใหม่ทีละหัวข้อ รวมถึงเอาประสบการณ์มาสอดแทรกไว้ด้วยถ้ามีโอกาส (การใช้งานผมใช้ SourceTree เป็นหลักนะครับ ถ้ามีใครเป็นสิงห์ Git Command มาก็ขอนับถือในความสามารถมา ณ ที่นี้ครับ)

Clone/New

สิ่งนี้เป็นสิ่งแรกที่ต้องทำเมื่อเราจะใช้งาน Git กับ Project ใดๆ ก็ตามไม่ว่าจะทำเองหรือทำกับทีม สิ่งสำคัญ 2 สิ่งสำหรับการ Clone ก็คือ Source Path กับ Destination Path โดย Source Path จะเป็น link ของ Remote repository ไว้สำหรับเก็บ Source code นอกเครื่องเรา (ที่เราเรียกว่า Local repository) โดยส่วนใหญ่มักจะอยู่ในรูป http url หรือ ssh url เช่น https://github.com/user/project.gitพอเราได้ลิงค์มาแล้วแปะไว้โปรแกรมจะสร้าง Destination Path ซึ่งเป็นโฟลเดอร์ที่เราจะใช้ในการเก็บไฟล์ที่เรา Clone มานี้และเป็นโฟลเดอร์หลักที่เราจะใช้ในการทำงานในโปรเจ็คนี้นะครับ โดยถ้าไม่พอใจก็เปลี่ยนได้ซึ่งส่วนใหญ่ก็จะเปลี่ยนอยู่แล้วเพราะคงไม่มีใครไปนั่งพัฒนาเว็บอยู่ใน My Document หรอกจริงมั้ยครับ

ส่วนในกรณีมี Project อยู่ในเครื่องหรือกำลังจะเริ่มสร้าง Project ในเครื่องเราก็จะมายุ่งในแท็บที่ 2 และ 3 แทนโดยในแท็บที่ 2 จะเป็นกรณีที่เรามีไฟล์ Project อยู่ในเครื่องอยู่แล้ว แล้วต้องการเอา Git ไปใช้งานเราก็เพียงแค่เพิ่ม Working copy path เข้าไปซึ่งก็คือ Destination Path ของกรณีที่แล้วนั่นเองครับ กรณีเราจะเริ่มสร้าง Project จากศูนย์เลยเราก็จะมายุ่งในแท็บที่ 3 ซึ่งก็คือการเพิ่ม Destination Path เข้าไปให้โปรแกรมมันจับแค่นั้นเองครับ

Fetch/Pull

ในการทำงานประจำวันของผมกับ Git คำสั่ง 2 คำสั่งนี้จะเป็นสิ่งแรกที่ผมทำในทุกวันหลังจากเปิดโปรแกรมครับ โดยคำสั่งแรกก็คือ Fetch จุดประสงค์ของมันก็เพื่อเช็คว่ามีการกระทำอะไรใดๆ ใน remote repository ที่เราใช้อยู่รึเปล่า ซึ่งถ้ามีตัวโปรแกรมก็จะแจ้งเตือนเป็นตัวเลขจำนวน Commit พร้อมกับลูกศรลงอยู่ข้างหลัง Branch นั้นๆ หรือถ้าเราอยู่ใน Branch นั้นแล้วมันจะแสดงเป็นตัวเลขแดงๆ อยู่ตรงปุ่ม Pull กลายๆ ว่าเมิงกดกูซักทีเหอะนะซึ่งถ้าเรากดปุ่ม Pull ก็จะเป็นการดาวน์โหลดการเปลี่ยนแปลงใดๆ ที่เกิดใน Branch นั้นที่อยู่บน Remote repo ลงมายัง Branch เดียวกันที่อยู่เครื่องเราเป็นการทำให้แน่ใจว่าเครื่องเรามี Source code ล่าสุดพร้อมสำหรับการพัฒนาต่อเสมอ

Commit

คำสั่งนี้เป็นคำสั่งพื้นฐานที่สุดและใช้บ่อยที่สุดสำหรับ Git โดยการ Commit คือการเก็บบันทึกการเปลี่ยนแปลงใดๆ ที่เราทำใน Working Folder หรือโฟลเดอร์ Project ของเราเองไว้ ซึ่งก็จะแบ่งเป็น 2 Mode หลักๆ คือ Stage changes และ Working copy change โดย Stage change คือการเปลี่ยนแปลงที่เรากระทำกับไฟล์ในโฟลเดอร์นั้นๆ เช่น การสร้างไฟล์, การลบไฟล์ รวมถึงการ Merge Branch หลายๆ ครั้งเราก็จะใช้ Mode นี้ด้วย ส่วน Mode Working copy change คือการเปลี่ยนแปลงใดๆ ที่เรากระทำกับไฟล์ใดๆ ที่มีอยู่แล้วในโฟลเดอร์นั้น (ซึ่งอันนี้ใช้บ่อยที่สุดละ) ข้อควรระวังก็คือ ถ้าเราต้องการเปลี่ยนไป Branch อื่นๆ เช่นจาก Feature หนึ่งไปอีก Feature หนึ่งถ้ามีการเปลี่ยนแปลงใดๆ ที่ทำไปแล้วก็ควรจะ Commit ก่อนเปลี่ยน Branch (ซึ่งโดยปกติแล้วโปรแกรมจะเตือนไม่ให้เปลี่ยน แต่ก็จะมีตัวเลือก discard all change ไว้ในกรณีขี้เกียจด้วย)

Push

หลังจากเรากด commit ไปแล้วการเปลี่ยนแปลงนั้นก็เพียงแค่บันทึกไว้ใน Local repository ซึ่งถ้าเครื่องเรา HDD พัง OS เจ๊งก็ยังมีโอกาสที่เราจะสูญเสีย Source code ที่เราอุตส่าห์พร่ำเขียนมา ซึ่งการที่เรามี Remote repository ก็เพื่อป้องกันเหตุร้ายดังกล่าว (แต่ก็ใช้ว่ามันจะไม่มีโอกาสเสียเลย) รวมถึงเป็นการ Synchronous ตัวงานหรือโมดูลที่เราทำเข้ากับส่วนกลางเพื่อให้คนอื่นในทีมได้ใช้งานร่วมกันรวมถึงรวมเข้าด้วยกันในภายหลังโดยการ Push เราสามารถเลือกได้ว่าจะ Push ทุก Branch ที่มีอยู่ในเครื่องหรือเพียงแค่ Branch ที่เราได้ทำการเปลี่ยนแปลงไปในข้างต้น ข้อควรระวังคือโปรแกรมจะไม่ให้เรากด Push ถ้ามีการค้าง Pull ไว้ใน Branch ที่เราเลือก วิธีแก้ก็คือ Pull มันลงมาซะแล้วค่อยกด Push ใหม่อีกรอบหนึ่ง

Branch/Merge/Checkout

อย่างที่ผมได้กล่าวไปแล้วในตอนที่ 1 เรื่องแนวทางการแตก Branch จากประสบการณ์ผมเคยแตก Branch เองจริงๆ น้อยมากครับ ส่วนใหญ่จะใช้ฟีเจอร์ Git Flow ให้เป็นประโยชน์โดยหลังจากที่เราสร้าง Project มาแล้วการกด Git Flow ครั้งแรกจะเป็นการ Initial ตัว Local repository เราว่า เราจะทำงานแบบ Git Flow นะโดยตัวโปรแกรมก็จะแยก Branch ใหม่ให้เองเป็น Master กับ Develop ก่อนโดยเราจะถูกสลับ (Checkout) มาไว้ที่ Branch นี้โดยอัตโนมัติ หลังจากนั้นแล้วเมื่อเราต้องการพัฒนาฟีเจอร์ใหม่ใดๆ ก็กดตรง Git Flow แล้วเลือก Start New Feature ซึ่งส่วนใหญ่แตกแล้วแตกยาว เพราะหลายงานที่ทำอยู่ปัจจุบันก็ยังทำไม่เสร็จจน Finish Feature ซึ่งตัวโปรแกรมจะทำการรวม (Merge) ตัว Branch Feature นั้นๆ เข้า Develop ให้โดยอัตโนมัติ วิธีแก้ปัญหาในปัจจุบันส่วนใหญ่ผมยังใช้การ Merge เองด้วยมือในตอนวันท้ายๆ ของสัปดาห์ซึ่งเป็นการ Release ตัว Project ออกมาเป็นเวอร์ชั่นย่อยๆ รวมถึงเป็นการรวม Source Code จากคนอื่นๆ ในทีมมาอัพเดทไว้ที่ Branch Develop ด้วยซึ่งถ้าคนในทีมเริ่มแก้ไฟล์เดียวกันเมื่อไร สิ่งที่ตามมาอยู่ในย่อหน้าถัดไปครับ

Merge Conflict เป็นปัญหาที่เกิดขึ้นจากการแก้ไขไฟล์เดียวกันในบรรทัดเดียวกันจากต่าง Branch กันซึ่งพอเราจะกด Merge ตัวโปรแกรมก็จะงงว่าตกลงเราจะเอาอันไหน ซึ่งมีตัวเลือกในการแก้ (resolve conflict) อยู่ 2 ทางคือใช้ไฟล์ของเรา หรือใช้ไฟล์จากอีก Branch หนึ่งที่กำลังจะรวมเข้าไป ซึ่งอันนี้ก็ขึ้นอยู่กับสถานการณ์ว่าจะใช้แบบไหนในการแก้

สิ่งที่เกิดขึ้นหลังจากแตก Branch อย่างเมามันส์… นรกของการ Merge Code

Tag

ตอนผมเริ่มใช้ Git ใหม่ๆ ผมยอมรับเลยว่าผมไม่เคยเห็นความสำคัญของ Tag เลย จนกระทั่งผมกับทีมเริ่มแตก Branch มากกว่า 5 สายผมถึงเริ่มเข้าใจทันที่ว่าเรามี Tag ไว้เพื่ออะไร การติด Tag ก็เหมือนการติดป้ายบอกว่าเราทำอะไรอยู่ในตรงนั้นนอกจาก Commit message โดยส่วนใหญ่จะติดตอน Finish Feature หรือ Release เป็นการอ้างอิงถึงที่หาง่ายกว่า Commit Message มากโดยตัว Git Flow จะมีตัวเลือกให้เราใส่ Tag โดยอัตโนมัติเมื่อเข้าสู่เงื่อนไขดังกล่าวข้างต้น

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

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

Original post at: https://yothinix.blogspot.com/2013/12/tde-2-git-basix-command.html

จุดประสงค์ที่ผมเขียนเอนทรี่ในชุด Team Development Environment & Workflow (ตอนต่อๆ ไปจะเรียกมันว่า TDE&W นะครับ) ก็เพื่อที่จะรวบรวมคำถามและวิธีการที่ผมเคยสงสัยมาตลอดในการสร้าง Software ออกมาตัวนึง เพื่อเก็บไว้ใช้อ่านทวนทีหลัง และที่สำคัญไว้เผยแพร่ความรู้ให้กับคนที่ยังไม่รู้เหมือนผมก่อนหน้านี้ จริงอยู่ถ้าในโลกการทำงานแล้วเรื่องแบบนี้บางครั้งเป็นเรื่องที่ Basic มากแต่ถ้ามองย้อนกลับมาในระดับการศึกษาผมค้นพบว่า น้อยคนที่จะเรียนรู้ลำดับการทำงานแบบนี้ซึ่งสามารถช่วยให้ทำงานได้อย่างเป็นระบบและมีประสิทธิภาพสูงขึ้นมาก

Git Workflow

คำถามแรกที่ผมถามตัวเองอย่างที่ผมได้บอกไปแล้วผมคิดถึง Git ก่อนเลยครับเนื่องจากมีประสบการณ์การทำงานกับมันมาบ้างใน Project ที่ใช้ Rails แต่สิ่งสำคัญอย่างนึงที่ผมยังไม่รู้คือ Git Workflow ครับโชคดีที่มีคนเขียนแนะนำเรื่องนี้ไว้แล้วในบทความเรื่องA Successful Git branching model

src: https://nvie.com/posts/a-successful-git-branching-model/

บทความนี้อธิบายไว้อย่างคร่าวๆว่าในการ Develop Software ขึ้นมาซักตัวนั้นเราควรจะมีแผนการในการแตกสาขา (Branch) ของ Source Code ที่เราเก็บไว้อย่างไรโดยจะแตกออกเป็น Branch หลักๆอยู่ 2 Branch คือ

• Master :: เป็น Branch หลักของตัวโค้ดเวอร์ชั่นสมบูรณ์แล้วพร้อมจะนำเข้าสู่ Server ในระดับ Production ซึ่งถ้ามองตามการเปลี่ยนแปลงภายในระบบก็คือ Major Change นั้นเองครับ
• Develop :: เป็น Branch หลักในการทำงานของทีม โดย Branch นี้จะมีการแก้ไขเปลี่ยนแปลงอยู่เกือบตลอด และเมื่อโค้ดใน Branch นี้สมบูรณ์แล้วก็จะถูก Merge เข้าสู่ Master Branch ต่อไป

นอกจากนั้นแล้วยังมี Branch อื่นๆ ที่มีความจำเป็นในการทำงานเนื่องจาก ถ้ามีแค่ 2 Branch นี้แล้ว Developer ทำการยำการทำงานอยู่ที่ Develop Branch อย่างเดียวก็ยังมีโอกาสสูงมากที่โปรเจ็คจะ Fail เนื่องจากโค้ดมันชนกัน ด้วยเหตุนี้จึงมี Branch อื่นๆ ที่เรียกว่า Supporting branch ไว้สำหรับการทำงานในส่วนต่างๆ ที่แยกจากกันดังนี้

• Feature :: สำหรับใน branch นี้มีไว้เพื่อให้นักพัฒนาทำการแยกไป เพื่อพัฒนา Function/Module หรือความสามารถของระบบเดี่ยวๆ แยกต่างหาก เพื่อป้องกันความผิดพลาด เมื่อพัฒนาเสร็จเรียบร้อยดีแล้ว ก็จะรวม branch นี้กลับมาที่ develop branch เพื่อจะรอปล่อยใน Minor release ต่อไป
• Release :: จะเป็นตัวเชื่อมระหว่าง Develop กับ Master เมื่อทีมประเมินว่าโค้ดที่อยู่ใน develop branch นั้นเสถียรดีแล้ว ก็จะทำการปล่อย Minor release ที่ branch นี้เพื่อเช็คความเรียบร้อยอีกครั้งนึง ซึ่งถ้ายังมีปัญหาอยู่ใน branch นี้ก็จะทำการรวมกลับไปที่ develop branch เพื่อทำการแก้ไขข้อผิดพลาด (Bugfixes) ก่อนจะทำการส่งกลับมาที่ Release branch ใหม่ เมื่อ Team เห็นว่าโค้ดไม่มีข้อผิดพลาดอะไรแล้วก็จะทำการรวมไปที่ Master branch เพื่อส่งเป็น Major Update ต่อไป
• Hotfixes :: เมื่อโค้ดที่อยู่ใน Master branch มีปัญหาทางทีมจะทำการแก้ปัญหาในจุดนั้นทันทีโดยแยกโค้ดออกมาที่ branch นี้ เมื่อทำการแก้ไขข้อผิดพลาดเสร็จเรียบร้อยแล้ว ทางทีมก็จะทำการรวมโค้ดกลับไปที่ Master branch เพื่อแก้ไขข้อผิดพลาดและ Develop branch เพื่อทำการพัฒนาต่อไป

การติดตั้ง Git

ก่อนที่เราจะทำการใช้งาน Git เป็น Version Control Software ของโปรเจ็คเราได้นั้นเราต้องมี Software ของมันก่อนครับซึ่งสามารถเข้าไปโหลดเวอร์ชั่นล่าสุดได้ที่http://git-scm.com/ครับซึ่งระหว่างการติดตั้งจะมีให้เราเลือกว่าให้เราใช้ Git ผ่านทางไหนได้บ้างแนะนำให้เลือก Run Git from the Windows Command Prompt ครับ (เดี๋ยวจะได้ใช้ประโยชน์ในอนาคต) เมื่อติดตั้งเสร็จแล้วก็จะสามารถลองใช้งานได้ผ่านทาง Git Bash หน้าตาประมาณรูปข้างบนครับหรือจะใช้ Git GUI ก็ได้แต่เราจะยังไม่ทำการตั้งค่าเบื้องต้น Git ตอนนี้ครับเพราะจะใช้ตัวนี้เป็นแค่ Back-end ของ Client อีกตัวที่เราจะใช้กันจริงๆซึ่งก็คือ SourceTree ครับ

การสมัครสมาชิก GitHub

สำหรับ Host หรือ Repository ของโค้ดในตอนนี้ผมเลือกใช้ GitHub ก่อนนะครับ (ตอนหลังๆจะย้ายไปใช้ตัวอื่น) โดยการสมัครสมาชิกสามารถเข้าไปสมัครได้ที่หน้าแรกตาม URL นี้เลยครับhttps://github.com/เมื่อสมัครสมาชิกเข้ามาแล้วส่วนสำคัญคือการตั้งค่า SSH Keys ที่จะใช้ในการยืนยันตัวตนของเครื่องเราเวลาที่จะทำการส่งโค้ดเข้าสู่ Repository ของตัว GitHub โดยสามารถเข้าไปตั้งค่าได้ที่ Account settings > SSH Keys โดยจะมีลิงค์บอกวิธีการสร้าง Keys อยู่ข้างบนสำหรับใน Windows ให้เปิด Git Bash ขึ้นมาแล้วทำตามขั้นตอนดังนี้ครับ

1. เช็คดูก่อนว่าในเครื่องเราได้มีการสร้าง ssh keys ไว้แล้วหรือยังโดยพิมพ์คำสั่ง
   
   $ cd ~/.ssh
   
   ซึ่งถ้าขึ้นว่า No such file or directory ก็แสดงว่าเครื่องเรายังไม่เคยสร้าง Keys ใดๆ ไว้นะครับ
2. ให้ทำการสร้าง SSH Key ใหม่ขึ้นมาโดยพิมพ์คำสั่ง
   
   $ ssh-keygen -t rsa -C “your_email@example.com”
   
   โดย email ที่ใส่ก็คือ email เดียวกับที่เราใช้สมัคร Account ของ GitHub ไปก่อนหน้านี้ครับระหว่างนั้นจะมีให้เราใส่ passphrase เพื่อเพิ่มความปลอดภัยของ Key ที่เราสร้างขึ้นครับซึ่งถ้าไม่ต้องการเปลี่ยนแปลงอะไรก็กดปุ่ม Enter ข้ามไปครับ
3. เมื่อสร้างคีย์เสร็จเรียบร้อยแล้วนะครับให้เราทำการ Copy ตัวเนื้อ Key โดยพิมพ์คำสั่ง
   
   $ clip < ~/.ssh/id_rsa.pub
   
   หลังจากนั้นแล้วให้เรากลับมาที่หน้า Account settings > SSH Keys แล้วเลือก Add SSH Key แล้วทำการ Paste ตัวเนื้อ Key ลงในช่อง Key เสร็จเรียบร้อยแล้วก็กด Add key ก็เป็นอันเสร็จเรียบร้อยครับ (ถ้ามีขึ้นให้ยืนยันพาสเวิร์ดอีกทีก็กรอกแล้วกด Enter ไปตามขั้นตอนครับ)
4. ตอนนี้เราก็ได้ Add Public Key ของเราเข้าที่ GitHub แล้วนะครับ โดยเราสามารถทดสอบดูได้ว่า Key ที่เราแอดไปสามารถใช้ได้หรือไม่โดยลองพิมพ์คำสั่งนี้ลงใน Git Bash ครับ
   
   $ ssh -T git@github.com
   
   หลังจากนั้นแล้วจะมีถามยืนยันที่จะเพิ่ม Host ก็พิมพ์ “yes” แล้วรอซักพัก ถ้าขึ้นว่า
   Hi username! You’ve successfully authenticated, but GitHub does not provide shell access. ก็แสดงว่า Key ที่เราเพิ่มเข้าไปตะกี้สามารถใช้งานได้แล้วนะครับ

การติดตั้ง SourceTree

เพื่อความสะดวกนะครับผมได้เลือกใช้ SourceTree ซึ่งเป็น Git GUI Client ตัวนึงในการใช้งานเนื่องจากไม่ต้องเสียเวลาจำคำสั่งมากและใช้งานง่ายสำหรับมือใหม่ในการทำความเข้าใจ Git รวมถึงสนับสนุนการทำงานแบบ Git Flow ที่ได้กล่าวไปแล้วข้างต้นได้อย่างเต็มที่ตัวโปรแกรมสามารถเข้าไป Download ตัวติดตั้งได้ตาม URL นี้ครับhttp://www.sourcetreeapp.com/

เมื่อติดตั้งเสร็จแล้วจะมีตัวเลือกให้เราตั้งค่าพื้นฐานของการใช้งานก็ใส่ Full Name และ Email address ไปนะครับ (อย่าลืมกด I agree to the SourceTree license agreementนะครับ) หลังจากนั้นกด Next ครับในส่วนของ SSH Client Configuration ก็ให้เลือกเป็น OpenSSH ต่อมาจะเป็นการตั้งค่ากับ remote repository ก็ใส่ Username กับ Password ของ github ไปให้เรียบร้อยแล้วกด Finish ระบบจะทำการทดสอบการเชื่อมต่อถ้าเชื่อมต่อได้ก็จะเข้าสู่โปรแกรมได้เลยครับสำหรับในตอนแรกก็จบเพียงเท่านี้นะครับในตอนต่อไปเราจะมาพูดถึงการใช้งาน Git เบื้องต้นโดยใช้ SourceTree กันครับ

Original post at: https://yothinix.blogspot.com/2013/10/team-development-environment-workflow-1.html