concept ของ pull request บน github.com ที่ไม่ได้ใช้ git-flow

=== ปวดหัวการแตก branch ===
svn ใช้คำสั่ง copy ในการแตก branch ซึ่งโดยมาตรฐานแล้วก็จะแตกจาก trunk ซึ่งก็คือ branch แม่ของมัน เมื่อสิ้นสุดกระบวนการแตก branch ก็จะมี branch ใหม่ชื่ออะไรก็ตาม **อยู่บน server** ย้ำว่ามันสร้าง branch บน server ไม่ได้สร้างบน local machine
อันนี้จะต่างกับ Git ที่ใช้คำสั่ง branch เพื่อสร้าง branch เปล่าๆบน local machine

=== ปวดหัวกับการดึง src code ===
เมื้อกี้สร้าง branch ไปแล้ว ทั้ง svn และ Git ถ้าอยากได้ source code ก็ต้องดึงมาก่อน สำหรับ svn จะใช้คำสั่ง checkout แต่ git จะใช้คำสั่ง pull อันนี้ไม่ได้ต่างกันมาก จะต่างกันก็ตรงที่ branch ที่สร้างของ svn มันดึงมาใช้ได้เลย แต่ git เราจะได้ branch เปล่ามาก่อนแล้ว pull ปลายทางมาใส่
สำหรับ svn เมื่อเราต้องการอัพเดตว่า branch บน server มีการอัพเดตไหม จะใช้คำสั่ง up ตรงนี้ svn จะทำการอัพเดตเลข revision ให้เราด้วย แต่ git จะ pull ลงมาลูกเดียว ตามประสบการณ์ git ทำได้ไวกว่าทั้งการดึง src code ลงมาจาก server หรือการอัพเดต src code ขึ้นไป
สำหรับ git-flow มันค่อนข้างโกง เพราะมันสร้าง branch ให้เอง ก๊อปโค๊ดจาก develop branch ให้เอง

=== ปวดหัวกับการอัพเดต src code ขึ้น server ===
เพราะว่า svn มันเก็บทุกอย่างไว้ข้างบน server หากว่าเราอัพเดตอะไรก็ให้ทำการ commit ของที่อัพเดต**จะถูกขึ้นไปไว้บน server** แต่มันต่างจาก commit ของ git ตรงที่ว่า git มัน commit **เข้า local machine** ตัวเอง แต่ถ้าอยากเอาขึ้น server ก็ push ขึ้นไป นี่อาจเป็นข้อเสียของ svn แต่มันก็ดีตรงที่มันสร้างนิสัยให้เรา commit ของขึ้นไปบ่อยๆ

=== ปวดหัวกับการเปลี่ยน branch ===
svn ใช้คำสั่ง switch ในการเปลี่ยน แต่มันไม่ได้เปลี่ยนเหมือน Git หรอกนะ หากว่าเราอยู่ branch A มีไฟล์อยู่ 10 ไฟล์ ทำการ switch ไป branch B ซึ่งมีไฟล์อยู่เพียง 5 ไฟล์ svn จะทำการดึงไฟล์ของ branch B บน **server** มาแทนและแสดงผล diff ว่ามีไฟล์อะไรถูกเพิ่มถูกลบบ้าง หากว่าไฟล์ทั้งหมดมันใหญ่ หรือว่าอินเตอร์เน็ตมีปัญหาช่วงที่ทำการ switch ก็เสี่ยงที่จะเจ๊งได้ (แต่มันก็แก้ได้ง่ายๆเหมือนกัน) มันไม่เหมือน Git ที่สลับ src code บน local machine การเปลี่ยน branch ของ git เลยไวกว่า แล้วหากว่า เราอยู่ branch B เขียนไฟล์เพิ่มไปครึ่งวัน แล้วเราไปเปลี่ยน branch กลับไปเป็น branch A แต่ลืม commit ทุกอย่างที่เราทำใน branch B ก็เป็นฝุ่น พอเปลี่ยนกลับมา B ของที่เราทำๆก็หาไม่เจอ เพราะมันไม่ได้ commit ขึ้น server อย่างไรก็ตาม ความถี่ในการเปลี่ยน branch มันขึ้นอยู่กับว่า manage project ดีมากน้อยแค่ไหน ถ้าแบ่ง feature ดี แบ่ง cards ให้มัน independent มากที่สุดเท่าที่จะเป็นไปได้ก็ไม่รู้จะสลับ branch ไปมาเพื่ออะไร git อาจไม่ค่อยมีปัญหาเรื่องของการสลับ branch แต่ svn แก้ง่ายๆด้วยการ checkout ตัว trunk ลงมาไว้ที่หนึ่งเพื่ออัพเดตว่าทีมได้ merge อะไรเข้าไปบ้าง มีของใหม่อะไรเข้าไปบ้าง และทำการ merge branch ของเราเข้าไปใน trunk เมื่อไม่มีอะไรพังก็ commit ขึ้น server
การสลับ branch ใน git-flow ผมไม่ค่อยปลื้มเท่าไหร่ เพราะว่ามันลากไฟล์ทุกอย่างที่อัพเดตมาด้วย เวลาอยากรู้ว่า develop มีอะไรเปลี่ยนเลยต้อง trash แล้ว pull –rebase แล้วมา pop ของกลับมา

=== ไม่เชิงปวดหัวกับ conflict ===
conflict มันเป็นเรื่องธรรมดา สำหรับ svn และ git จะทำคล้ายๆกันคือไปแก้ conflict ซะ ทาง svn เมื่อมี conflict เกิดขึ้นจะมี option ให้เลือกว่า เราจะใช้ไฟล์ที่เราอัพไป หรือไฟล์บนเซอร์เวอร์ หรือว่าให้ postpone มันไปก่อน แล้วค่อยแก้ conflict เอง หลังจากแก้เสร็จจะใช้คำสั่ง resolved เพื่อย้ำว่าไฟล์มันสะอาดแล้ว แต่สำหรับ git ไฟล์ที่มัน conflicted จะถูก untrack อัตโนมัติ เราต้องไป add ไฟล์๋นั้นใหม่ (สถานะ conflicted file ของ svn จะยัง tracked อยู่ และวิธี untrack คือการลบไฟล์ทิ้งไปเลย \O/)

=== เลข revision กับ log ===
เห็นว่า mention เรื่องนี้ด้วย เลข revision ของ svn มันเป็นจุดเด่นตรงที่รันด้วยเลข ทำให้มัน”เถียง” กันง่าย “blame” กันง่าย ถ้าถามว่าตอนนี้บน demo server เป็นเลข revision อะไร ตอบด้วยเลขมันเข้าใจมากกว่าตอบด้วย hash string ของ git
ส่วนกรณี log นั้น trunk ของ svn จะเก็บ log เฉพาะ comment ที่ merge branch ต่างๆเข้ามาเท่านั้น ส่วน comment ยิบย่อยใน branch มันไม่เก็บ เวลาดู log มันเลยค่อนข้างเป็นระเบียบมากกว่า เช่น
r1028 complete st510-add facebook comment
r1020 hotfix fix js test cases
r1015 complete st508-add buildbot for running silenum
(^ตัวอย่างนะครับ จริงๆรายละเอียดมันเยอะกว่านี้ เช่นเวลา ใครเป็นคน commit บลาๆ)
หากว่า product บน demo เราเจ๊งแล้วเราไม่รู้จริงๆว่า card ใบไหน feature ที่ใครทำ มันทำให้งานคนอื่นเจ๊ง product เสีย เราก็ค่อยๆทำการ revision ไปทีละนิด เพราะ trunk มัน”อัพเดตเมื่อ feature เสร็จ”อยู่แล้ว แค่ถอดออกทีละ feature เท่านั้นเอง หลังจากนั้นก็ blame คนที่ทำของเจ๊งให้มาแก้ซะ
ตรงนี้ผมมองว่ามันดีกว่า git ที่เอาทุกๆ log มาแสดงผล เวลาหาอะไรทีมันลำบาก

=== svn vs git ===
โดยส่วนตัวชอบ git-flow เพราะมันสลับสนุนแนวคิด agile ในตัว เวลาจะ push จะ pull ก็ใช้ git-cola สบายจะจะตาย แต่ svn ผมชอบตรงที่ทุกอย่างอยู่บน server แม้ว่า git มันก็ทำได้ แต่ความคิดผม svn มันแชร์กันง่ายกว่า ถ้าใครทำการ์ดไม่เสร็จและไม่ว่างมีลากิจก็ commit ขึ้นไป คนต่อมาก็ checkout มาทำต่อได้ หรือถ้าป่วยอยากทำงานต่อที่บ้านก็ checkout ทำเองได้หลายๆครั้งที่มีประเด็นที่ว่า “ถ้าเครื่องเจ๊งให้ทำยังไง” หรือถ้าอยากย้ายที่ทำงานทำยังไง ตอนที่น้ำท่วม กทม.แล้วพวกป๋มยกบริษัทมาอยู่เชียงใหม่ชั่วคราวก็เอา labtop มาคนละเครื่องเอง src ทุกอย่างอยู่ข้างบน server หมด แค่มีเน็ตก็ทำงานต่อได้ โปรเจคทุกตัวก็เดินต่อไปได้ปกติ