เวิร์กโฟลว์และการใช้งาน Git ขั้นสูง

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

เวิร์กโฟลว์ Git

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

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

จากนั้น git-flow ก็ออกมาและฉันก็นำมันเป็นกลยุทธ์ของฉัน ฉันยังจำได้ว่ารู้สึกเหมือนกำลังแอบมองหลังม่านไปยังที่ๆ นักพัฒนาที่น่าทึ่งอยู่ ตอนนี้ฉันมีความเข้าใจอย่างถ่องแท้ว่าพวกเขาทำงานอย่างไรและสามารถเริ่มเป็นหนึ่งในนั้นได้

แต่ git-flow ไม่เหมาะกับทุกสถานการณ์ ดังนั้นในขณะที่เรากำลังจะดูเรื่องนี้ เราจะมาดูวิธีอื่นๆ สองสามวิธีในการจัดระเบียบโครงการ Git ของคุณ รวมถึงวิธีที่ฉันจัดการโครงการของฉันในฐานะนักพัฒนาคนเดียว

git-flow

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

มาดูกันว่า git-flow คืออะไร

หากคุณต้องการดูคำอธิบายโดยละเอียดเกี่ยวกับแผนภูมิและคำสั่ง Git สำหรับ Git Flow คุณควร อ่านโพสต์นี้

ใน git-flow สองสาขามีอายุการใช้งานไม่สิ้นสุด อันดับแรก หลัก ซึ่งควรสะท้อนถึงโค้ดที่พร้อมสำหรับการปรับใช้กับสภาพแวดล้อมการทำงานจริง/การใช้งานจริงของคุณ

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

นอกสาขาใหญ่ 2 สาขา มีสาขารองรับ 3 ประเภท

1. คุณสมบัติ

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

เมื่องานพร้อมสำหรับการเปิดตัวครั้งต่อไป งานจะถูกรวมกลับเข้าไปในสาขาการพัฒนาซึ่งรอเวลาเผยแพร่

2. ปล่อย

รีลีสสาขาถูกสร้างขึ้นจากสาขาพัฒนาและต้องรวมกลับเป็นทั้งพัฒนาและหลัก คุณตั้งชื่อ release branch ด้วยหลักการ release-x ในทางปฏิบัติ ซึ่งมักจะหมายความว่าคุณจะตั้งชื่อสาขาด้วยหมายเลขรุ่นที่คุณวางแผนจะใช้ดังนี้: release-2.2

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

3. โปรแกรมแก้ไขด่วน

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

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

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

git-flow มาตรฐานไม่ได้มีไว้สำหรับรองรับสิ่งนี้

Github Flow

ตัวเลือกที่สองที่หลายคนใช้คือ Github Flow

กฎข้อใหญ่ข้อหนึ่งของ Github Flow คือโค้ดใดก็ตามที่อยู่ในสาขาหลักสามารถนำไปใช้งานได้ตลอดเวลาเพราะมันพร้อมสำหรับการผลิต

สาขาทั้งหมดถูกสร้างขึ้นจากสาขาหลักพร้อมชื่อที่สื่อความหมายสำหรับสิ่งที่คุณกำลังทำ

เมื่อคุณเตรียมการเปลี่ยนแปลงแล้ว คุณก็สร้างคำขอดึง

คำขอดึงจะบอกผู้อื่นที่ทำงานในรหัสเดียวกันว่างานที่คุณทำนั้นพร้อมสำหรับการตรวจสอบก่อนที่การเปลี่ยนแปลงเหล่านั้นจะรวมเข้ากับรหัสหลัก

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

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

ฉันจะใช้เวิร์กโฟลว์ Git กับโปรเจ็กต์ไคลเอนต์ได้อย่างไร

ในงานลูกค้าของฉัน ปกติแล้วฉันเป็นเพียงคนเดียวที่เขียนโค้ดสำหรับโครงการในแต่ละวัน ลูกค้าของฉันอาจอัปเดตปลั๊กอิน WordPress หรือเปลี่ยน CSS บางส่วน แต่ไม่ได้ทำงานเขียนโค้ดที่สำคัญใดๆ นั่นหมายความว่าหากฉันใช้ Github flow ฉันจะตรวจสอบคำขอดึงของฉันซึ่งสร้างแต่ปัญหาการจัดการเพิ่มเติมเท่านั้น มาดูระบบที่ฉันใช้กัน ซึ่งมีความคล้ายคลึงกับทั้ง git-flow และ Github flow

ฉันมีสองสาขาหลักที่เรียกว่าหลักและการแสดงละคร สาขาหลักติดตามด้วยโค้ดใดก็ตามที่กำลังทำงานอยู่บนไซต์ที่ใช้งานจริง staging branch ติดตามสิ่งที่กำลังทดสอบบนไซต์ staging ที่เราใช้เพื่อทดสอบการเปลี่ยนแปลงก่อนที่เราจะพุชไปยังไซต์จริง

ทุกสาขาถูกสร้างขึ้นจากสาขาหลัก ฟีเจอร์ใหม่มีชื่อดังนี้: feature/32-new-feature ในบริบทนี้ หมายเลข 32 จะสอดคล้องกับหมายเลขตั๋วในระบบการจัดการโครงการของเรา และคำที่อยู่ข้างหลังเป็นคำอธิบายสั้นๆ เกี่ยวกับสิ่งที่กำลังดำเนินการอยู่ การแก้ไขข้อบกพร่องได้รับการตั้งชื่อในทำนองเดียวกัน bug/20-bug-name

ทุกสาขาที่สร้างขึ้นจะถูกรวมเข้ากับสาขาการจัดเตรียมของเราก่อน จากนั้นเมื่อได้รับอนุมัติจากลูกค้าหรือทดสอบด้วยตัวเองจะถูกรวมเข้ากับสาขาหลัก เวิร์กโฟลว์นั้นอาจมีลักษณะเช่นนี้

# ผสานคุณสมบัติเข้ากับสาขาการแสดงละคร

คุณสมบัติการผสาน git/32-new-feature

# ปรับใช้และทดสอบคุณสมบัติ

git ชำระเงินหลัก

คุณสมบัติการผสาน git/32-new-feature

# ปรับใช้คุณสมบัติกับไซต์สด

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

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

คำสั่ง Git ขั้นสูงที่ฉันใช้

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

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

การเพิ่มการเปลี่ยนแปลงโดย Line

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

ฉันใช้สิ่งนี้หลายครั้งทุกวัน

ติดตามสาขา Git ระยะไกล

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

มีสองสามวิธีในการทำเช่นนี้

# ตั้งค่าอัปสตรีมเมื่อกดไปที่รีโมท

git push -u การแสดงละครต้นกำเนิด

# ตั้งต้นน้ำ

# ถือว่าคุณอยู่ในสาขาที่คุณต้องการติดตามด้วยรีโมท

สาขา git -u ต้นทาง / การแสดงละคร

สาขา git --set-upstream-to=origin/staging

# หากคุณไม่ได้อยู่ในสาขาที่คุณต้องการติดตามดังนั้นคุณจึงระบุสาขาในตอนท้าย

สาขา git --set-upstream-to=origin/staging staging

บันทึกการเปลี่ยนแปลงโดยไม่ต้องผูกมัด

บางครั้งคุณอาจอยู่ท่ามกลางงานบางอย่างที่ยังไม่พร้อมจะลงมือทำ แต่คุณต้องรักษาสถานะไว้ นั่นคือสิ่งที่ git stash มีประโยชน์ คำสั่งนี้ซ่อนการเปลี่ยนแปลงสำหรับคุณโดยลบการเปลี่ยนแปลง คุณสามารถนำมันกลับมาได้โดยใช้ git stash pop มีคำสั่งอีกสองสามคำสั่งที่จะทำให้ที่เก็บสะสมมีประโยชน์ แต่นี่เป็นคำสั่งสองคำสั่งที่ฉันใช้เป็นประจำ

ดึงข้อผูกพัน Git เฉพาะ

บางครั้งคุณจำเป็นต้องดึงความมุ่งมั่นเฉพาะเข้าไปในงานปัจจุบันของคุณ ด้วย clean HEAD (คุณยังไม่ได้ทำการเปลี่ยนแปลงใดๆ) คุณสามารถดึงคอมมิตเฉพาะด้วย git cherry-pick ได้ คุณสามารถค้นหาเอกสารฉบับเต็มเกี่ยวกับ git cherry-pick ได้ที่นี่

สำหรับแต่ละคอมมิต Git จะสร้างลำดับตัวอักษรและตัวเลขแบบยาวซึ่งเรียกว่า Git Object และโดยทั่วไปจะเรียกว่า SHA เนื่องจากแต่ละคอมมิชชันได้รับหนึ่งอัน คุณจึงสามารถอ้างอิงคอมมิตด้วยค่า SHA ของมันได้ อ่านเพิ่มเติมเกี่ยวกับ Git Objects

ทิ้งการเปลี่ยนแปลงที่คุณไม่ต้องการ

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

รีเซ็ต git --hard

คำสั่งด้านบนจะรีเซ็ตโค้ดของคุณกลับไปเป็นคอมมิตล่าสุดบนแบรนช์ที่คุณกำลังดำเนินการอยู่ นอกจากนี้เรายังสามารถใช้ <#commitSHA> กับคำสั่งนี้เพื่อรีเซ็ตการคอมมิตเฉพาะได้ หากเราต้องการกลับสู่สถานะก่อนการคอมมิตล่าสุด บางทีคุณอาจใช้สิ่งนี้เพื่อรีเซ็ตเป็นการชำระเงินของสาขาเริ่มต้น เนื่องจากงานทั้งสาขาไม่ใช่สิ่งที่คุณต้องการเก็บไว้ แต่คุณได้ติดตามงานบางส่วนแล้ว

เพื่อก้าวไปอีกขั้น เราสามารถทิ้งไฟล์หรือไดเร็กทอรีที่ยังไม่ได้ติดตามในคอมไพล์ด้วยคำสั่ง git clean

git clean -fd: แฟล็ก f และ d บอกให้ git ทิ้งไฟล์และไดเร็กทอรีที่ไม่ได้ติดตาม

ลบสาขา

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

# ลบเวอร์ชันท้องถิ่น

git branch -d $branchname

#ลบสาขาบนรีโมทของฉัน

git push $remotename --delete $branchname

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

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

คุณจะสามารถไว้วางใจระบบของคุณและผลิตงานสำหรับโครงการของคุณต่อไป

ลองใช้โฮสติ้ง WordPress ที่มีการจัดการอย่างเต็มที่

ต้องการโฮสติ้งที่เหมาะสำหรับ WordPress หรือไม่? ตรวจสอบแผนโฮสติ้ง WordPress ที่มีการจัดการเต็มรูปแบบของ Nexcess ได้แล้ววันนี้