บทนำสู่การควบคุมเวอร์ชันและ Git

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

ตอนนี้ลองนึกภาพแทนที่จะเป็นแผ่นงานที่เต็มไปด้วยย่อหน้า มีไฟล์ที่เต็มไปด้วยรหัสหลายร้อยบรรทัด และไม่เหมือนเอกสารฉบับเดียวตรงที่มีไฟล์ต่างๆ มากมาย อัปเดตอยู่ตลอดเวลา

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

นี่คือที่มาของซอฟต์แวร์ควบคุมเวอร์ชันในรูปภาพ

เหตุใดการควบคุมเวอร์ชันจึงมีความสำคัญในการพัฒนาซอฟต์แวร์

ตามชื่อที่แนะนำ ซอฟต์แวร์ควบคุมเวอร์ชันช่วยให้นักพัฒนาแอปบนอุปกรณ์เคลื่อนที่ติดตามเวอร์ชันต่างๆ ของวัฏจักรการพัฒนาซอฟต์แวร์และทำการเปลี่ยนแปลงในเวอร์ชันเหล่านั้น ความสามารถในการติดตามการเปลี่ยนแปลงทั้งหมดที่เกิดขึ้นในโค้ดและตัวเลือกในการเลิกทำการเปลี่ยนแปลงนี้เป็นสิ่งที่ทำให้การควบคุมเวอร์ชันเป็นส่วนสำคัญ ของกระบวนการของบริษัทพัฒนาแอปบนอุปกรณ์เคลื่อนที่ ซึ่งเกี่ยวข้องกับนักพัฒนาหลายคน

เมื่อพูดถึง Version Control มีซอฟต์แวร์จำนวนมากในตลาดในปัจจุบัน ให้เราดูบางส่วนของพวกเขา -

ซอฟต์แวร์ที่มีจำหน่ายสำหรับการควบคุมเวอร์ชัน

แม้ว่าในการสำรวจ GitLab ผู้นำด้านซอฟต์แวร์แบบกระจายพบว่า 98% ของผู้ใช้ใช้เครื่องมือโอเพ่นซอร์ส Git และนักพัฒนากว่า 92% ใช้ Git เป็นภาษาควบคุมเวอร์ชันในกระบวนการพัฒนาแอป เหตุผลที่นักพัฒนาอาจมอง Git ทางเลือก เหตุผลบางประการอาจแตกต่างกันไป – โครงสร้างราคา GitHub และความจริงที่ว่า Github เปิดตัวทั้งบน iOS และ Android ความเกลียดชังต่อ Octocat หรือระดับความสะดวกสบายที่เรียบง่ายด้วยภาษาควบคุมเวอร์ชันที่ไม่ใช่ Git

ไม่ว่าเหตุผลของคุณจะเป็นอย่างไร นี่คือทางเลือกอื่นของ Git สำหรับการควบคุมเวอร์ชัน -

ในตอนนี้ แม้ว่าจะมีทางเลือกมากมายสำหรับการควบคุมเวอร์ชันและที่ Appinventiv เราก็มีประสบการณ์ตรงในการทำงานกับตัวเลือกเหล่านี้จำนวนมาก เนื่องจากความต้องการของลูกค้าที่แตกต่างกัน เราจึงเป็นส่วนหนึ่งใน Git อย่างแท้จริง ให้ฉันบอกคุณว่าทำไม

เหตุใด Appinventiv จึงใช้ Git สำหรับการควบคุมเวอร์ชัน

1. สำหรับความเร็วสายฟ้า

จากซอฟต์แวร์ควบคุมเวอร์ชันทั้งหมดในตลาด ความเร็วที่องค์ประกอบบันทึกของ Git และ Commit นั้นไม่สามารถเทียบได้กับซอฟต์แวร์อื่นๆ และเมื่อทีมนักพัฒนาของคุณทำงานบนแพลตฟอร์ม ซอฟต์แวร์นั้นก็มีความรวดเร็วจำเป็นอย่างยิ่ง

2. สำหรับความสามารถในการทำงานแบบออฟไลน์

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

3. สำหรับ Undo Relief

Git มาพร้อมกับคำสั่ง 'undo' ที่ให้คุณแก้ไขและคืนค่าคอมมิตทั้งหมดได้ อันที่จริงมันยังให้ตัวเลือกแก่คุณในการกู้คืนคอมมิต 'ที่ถูกลบ' ผ่านตัวเลือก Reflog

4. สำหรับการสำรองข้อมูล

เมื่อทีมทำงานบน Git ทุกโคลนที่ทีมมีในเครื่องจะมาพร้อมกับข้อมูลสำรองที่ใช้งานได้ นอกจากนั้น เกือบทุกการกระทำของ Git จะเพิ่มเฉพาะข้อมูลและไม่ลบออก

5. สำหรับการทำภาระผูกพันที่เป็นประโยชน์

เมื่อทีมนักพัฒนาของเราทำการเปลี่ยนแปลงที่ไม่เกี่ยวข้องกัน เช่น นำคุณลักษณะบางอย่างจาก A มาใช้ แก้ไขข้อบกพร่องในอีกส่วน อาจเป็นเรื่องยากมากสำหรับสมาชิกในทีมคนอื่นๆ ที่จะทำความเข้าใจกับสิ่งที่เกิดขึ้น และอาจเป็นเรื่องยากสำหรับพวกเขาที่จะย้อนกลับ คุณสมบัติของ A ถ้ามันทำให้เกิดปัญหา

Git แก้ปัญหานี้ด้วยการสร้างคอมมิตแบบละเอียด ด้วยแนวคิด 'staging area' เราสามารถค้นหาได้อย่างง่ายดายว่าการเปลี่ยนแปลงใดบ้างที่จะรวมอยู่ในการคอมมิตครั้งต่อไป แม้ว่าคุณจะไม่ได้มองแค่บรรทัดเดียวก็ตาม

นี่คือเหตุผลหลักห้าประการที่เราใช้ Git ที่ Appinventiv เมื่อเราได้ดูสาเหตุแล้ว ก็ถึงเวลาดูที่ How เรารวม Git ไว้ในกระบวนการควบคุมเวอร์ชันของเราอย่างไร

ไปที่ตอนนี้กันเถอะ

กระบวนการควบคุมเวอร์ชันเมื่อใช้ Git

การสร้างที่เก็บ

จุดมุ่งหมายของ Git คือการจัดการชุดของไฟล์ aka Project ในการทำเช่นนั้น Git จะบันทึกข้อมูลทั้งหมดในโครงสร้างข้อมูลที่เรียกว่า Repository ที่เก็บประกอบด้วยซอร์สโค้ดของแอป ทรัพยากร และชุดข้อมูล โดยพื้นฐานแล้ว มันมีทุกอย่างที่กำหนดโปรเจ็กต์แอป

ขณะนี้ มีสองวิธีในการรับที่เก็บบน Git คุณสามารถใช้ไดเร็กทอรีในเครื่องและแปลงเป็นที่เก็บ Git โดยใช้บรรทัดคำสั่ง หรือคุณสามารถคัดลอกที่เก็บ Git ที่อัปโหลดแล้วลงในของคุณ

เมื่อคุณสร้างที่เก็บ คุณมักจะได้รับสองตัวเลือก – สาธารณะและส่วนตัว ที่เก็บข้อมูลสาธารณะเป็นที่ที่นักพัฒนารายอื่นสามารถดูได้โดยใช้ Git และที่เก็บข้อมูลส่วนตัวในทางกลับกันเป็นพื้นที่ที่มีเพียงไม่กี่คนเท่านั้นที่สามารถดูได้

สาขา

ถัดจาก Repository Creation คือ Branching ในบริษัทอย่าง Appinventiv ซึ่งนักพัฒนากว่า 15 - 20 คนกำลังทำงานในโครงการหนึ่งในช่วงเวลาใดก็ตาม ไม่ใช่เรื่องแปลกที่นักพัฒนาจะแชร์ซอร์สโค้ดเดียวกันและทำงานบนนั้น สิ่งที่เกิดขึ้นคือในขณะที่นักพัฒนาบางคนกำลังยุ่งอยู่กับการแก้ไขปัญหา คนอื่นๆ อาจกำลังใช้งานคุณลักษณะบางอย่างอยู่

ในสถานการณ์เช่นนี้ เราต้องการระบบที่ทำให้ง่ายต่อการจัดการโค้ดเวอร์ชันต่างๆ ในฐานโค้ดเดียวกัน

นี่คือที่มาของ Gitflow Gitflow เป็นเฟรมเวิร์กที่ใช้สำหรับการแตกสาขาอย่างเป็นระบบและมีประสิทธิภาพ

ก่อนที่เราจะพูดถึงวิธีการทำงานของกระบวนการ Branching บน Gitflow ให้ฉันอธิบายแนวคิดด้วยตัวอย่างก่อน

สมมติว่ามีนักพัฒนาซอฟต์แวร์ 5 คนในทีมของคุณและพวกเขากำลังพัฒนาแอปที่คล้ายกับ Instagram ตอนนี้คุณสมบัติแต่ละแอพเช่นสมมติฟีดและการแจ้งเตือนจะแสดงเป็นโมดูล 1 โมดูล 2 และอื่น ๆ เป็นต้น ตอนนี้โมดูลต่างๆ เหล่านี้คือสาขาการพัฒนา ซึ่งหลังจากทำงานเสร็จแล้ว จะถูกรวมเข้ากับสาขาหลักหรือมาสเตอร์

ทันทีที่นักพัฒนาเพิ่มสาขา พวกเขาสร้างสายการพัฒนาอิสระ ซึ่งแยกงานของตนออกจากงานของสมาชิกในทีม จากนั้นสาขาต่างๆ จะถูกรวมเข้ากับสาขาหลัก

การแยกสาขาเป็นวิธีที่ช่วยให้สมาชิกในทีมสามารถระบุการเปลี่ยนแปลงทั้งหมดที่พวกเขาควรคาดหวังและเป็นสิ่งที่ทำให้การย้อนกลับเป็นเรื่องง่าย

ในโครงการของเรา เรามักจะเก็บสาขาเหล่านี้ไว้ –

• ปริญญาโทสาขา
• สาขาพัฒนา
• สาขาคุณลักษณะ
• สาขาที่วางจำหน่าย
• การแก้ไขด่วนและการแก้ไขข้อบกพร่อง

ให้สัญญา

การเปลี่ยนแปลงที่นักพัฒนาทำในแต่ละไฟล์เรียกว่า Commit การเปลี่ยนแปลงหรือคอมมิตถูกเพิ่มในที่เก็บโลคัลและไม่ใช่ในเซิร์ฟเวอร์ ต่อไป นักพัฒนาของเราปฏิบัติตามนิสัยในการเขียนข้อความยืนยัน โดยจะมีการโพสต์คำอธิบายของการคอมมิต (การเปลี่ยนแปลงที่ทำในไฟล์) เพื่อให้นักพัฒนารายอื่นทราบรายละเอียดของการเปลี่ยนแปลงที่ทำในไฟล์ด้วย

ดัน

เมื่อคุณคอมมิตในที่เก็บ Git ในเครื่อง สิ่งที่เกิดขึ้นต่อไปคือการเปลี่ยนแปลงจะถูกส่งไปยังเซิร์ฟเวอร์ ซึ่งเรียก ว่า Push

มันค่อนข้างง่ายที่จะส่งประวัติการคอมมิตไปยังเซิร์ฟเวอร์เมื่อคุณเป็นคนเดียวที่ทำงานบนไฟล์ แต่ในกรณีที่มีผู้พัฒนารายอื่นที่เกี่ยวข้องกับกระบวนการนี้ด้วย คุณจะต้องดึงการเปลี่ยนแปลงก่อนจึงจะสามารถพุชชุดของ ยอมจำนนต่อ Git

ต่อไปเราจะดูสิ่งที่ทำในขั้นตอน Pull Change

ดึงคำขอ

เมื่อมีนักพัฒนามากกว่าหนึ่งคนทำงานในไฟล์เดียวกัน สิ่งที่เกิดขึ้นคือคอมมิตบางตัวอาจถูกส่งโดยผู้พัฒนารายอื่นบนเซิร์ฟเวอร์ก่อนที่คุณจะพุช และเมื่อสิ่งนั้นเกิดขึ้น ความขัดแย้งก็เกิดขึ้น (เพิ่มเติมในภายหลัง)

เพื่อหลีกเลี่ยงไม่ให้อัพโหลด codebase เดียวกันสองครั้งบนเซิร์ฟเวอร์ ขั้นแรกผู้พัฒนาดึงการเปลี่ยนแปลงจาก repository และตรวจสอบให้แน่ใจว่ารหัสต่างกัน โดยทั่วไปแล้ว เมื่อนักพัฒนาสองคนขึ้นไปทำงานในไฟล์เดียวกันและกดคอมมิตบนเซิร์ฟเวอร์ ตัวเลือกในการ 'ผสาน' จะปรากฎขึ้น

มาพูดถึงการผสานกันต่อไป

ผสาน

การผสานเป็นขั้นตอนที่นักพัฒนาจะรวมสาขาทั้งหมดเข้าด้วยกันก่อน จากนั้นจึงรวมเข้ากับสาขาหลักหรือหลัก

ทุกครั้งที่การส่งมอบเข้าสู่คำสั่ง Push พวกเขาจะได้รับตัวเลือก Merge ซึ่งจะถามพวกเขาถึงสาขาที่พวกเขาต้องการผสานการคอมมิต

ตอนนี้ที่ขั้นตอน Merge การเกิด Conflict เกิดขึ้นได้บ่อยมาก ความขัดแย้งมักเกิดขึ้นเมื่อสองสาขาที่คุณวางแผนที่จะรวมมีการเปลี่ยนแปลงในส่วนเดียวกันในไฟล์เดียวกัน สิ่งที่เกิดขึ้นที่นี่คือ Git ไม่สามารถทราบได้ว่าควรใช้เวอร์ชันใด

เมื่อเกิดปัญหาความขัดแย้งนี้ Git เสนอวิธีแก้ปัญหาสองแบบคือแบบอัตโนมัติและแบบแมนนวล

เมื่อขึ้นชื่อ สิ่งหนึ่งที่ Git ค้นพบปัญหาคือตัวมันเอง และในช่วงหลัง นักพัฒนาจะต้องดำเนินการด้วยตนเอง ที่ Appinventiv เรามุ่งเน้นที่การแก้ไขความขัดแย้งด้วยตนเอง โดยจะขจัดโอกาสเกิดข้อผิดพลาดเพียงไม่กี่นาที

ขณะที่เราใช้ Git เพื่อควบคุมเวอร์ชันของกระบวนการพัฒนาแอป สิ่งที่เกิดขึ้นพร้อมกันคือการติดตามปัญหา

เนื่องจากเราเป็นผู้ติดตาม Agile รายใหญ่และ ไว้วางใจ Agile สำหรับกระบวนการพัฒนาแอปบนอุปกรณ์เคลื่อนที่ เราจึงเข้าใจถึงความสำคัญของการจัดการกระบวนการพัฒนาหลายขั้นตอนพร้อมกัน และด้วยคุณลักษณะการติดตามปัญหา ผู้ทดสอบจะคอยติดตามโค้ดที่เขียนและผลักดันบนเซิร์ฟเวอร์ Git แบบเรียลไทม์ได้ง่ายขึ้นมาก

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