จัดการการแยกสาขา คําขอดึงข้อมูล และการแก้ไขข้อขัดแย้ง

เสร็จสมบูรณ์เมื่อ

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

ใช้สาขาคุณลักษณะสําหรับการเปลี่ยนแปลงฐานข้อมูล

กลยุทธ์การแยกสาขาอย่างง่ายสําหรับโครงการฐานข้อมูล SQL เป็นไปตามหลักการสามประการ:

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

เมื่อคุณเริ่มการเปลี่ยนแปลงฐานข้อมูล ให้แยกสาขาออกmain งานของคุณถูกแยกออกจากทุกสิ่งทุกอย่างที่กําลังดําเนินการอยู่ คุณปรับเปลี่ยนไฟล์ที่เกี่ยวข้อง .sql และเนื่องจากแต่ละวัตถุมีไฟล์ของตัวเอง จึงเป็นการคอมมิตที่เพิ่มคอลัมน์เพื่อ Customers สัมผัสเท่านั้น Tables/Customers.sql และไม่มีอะไรอื่น

git checkout -b feature/add-customer-email

หลังจากเสร็จสิ้นการเปลี่ยนแปลง ให้ส่งสาขาไปยังที่เก็บระยะไกล:

git add .
git commit -m "Add Email column to Customers table"
git push origin feature/add-customer-email

ตรวจสอบการเปลี่ยนแปลงด้วยคําขอดึงข้อมูล

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

คําขอดึงข้อมูลสําหรับการเปลี่ยนแปลงฐานข้อมูลควรตอบคําถามเช่น:

• การเปลี่ยนแปลง Schema ทําลายคิวรีที่มีอยู่หรือกระบวนงานที่เก็บไว้หรือไม่
• แบบแผนการตั้งชื่อสอดคล้องกับส่วนที่เหลือของโครงการหรือไม่?
• การเปลี่ยนแปลงจําเป็นต้องมีการอัปเดตที่สอดคล้องกันกับสคริปต์หลังการปรับใช้หรือไม่
• การเปลี่ยนแปลงทําให้ข้อมูลสูญหายหรือต้องย้ายข้อมูลหรือไม่

ใน Azure DevOps ให้สร้างคําขอดึงข้อมูลจากสาขาคุณลักษณะไปยังmainในส่วน ที่เก็บ ใน GitHub ให้ใช้แท็บคําขอดึงข้อมูล

เชื่อมต่อคําขอดึงข้อมูลกับบิลด์ CI

คําขอดึงข้อมูลที่มีบิลด์สีเขียวช่วยให้ผู้ตรวจสอบมั่นใจ กําหนดค่า PR เพื่อทริกเกอร์การสร้าง CI ที่คอมไพล์โครงการฐานข้อมูล SQL หากบิลด์ล้มเหลวเนื่องจากการอ้างอิงที่ใช้งานไม่ได้ข้อผิดพลาดทางไวยากรณ์หรือการขึ้นต่อกันที่ยังไม่ได้รับการแก้ไขปัญหาจะถูกจับได้ก่อนที่จะไปถึงหลัก

ใน Azure DevOps คุณกําหนดค่าทริกเกอร์การสร้าง CI ผ่านนโยบายสาขาการตรวจสอบความถูกต้องของการสร้าง ใน GitHub คุณตั้งค่าเวิร์กโฟลว์ที่ทริกเกอร์เหตุการณ์pull_requestที่กําหนดเป้าหมายสาขาmain

แก้ไขข้อขัดแย้งการผสานในโครงการฐานข้อมูล SQL

ความขัดแย้งเกิดขึ้นเมื่อสองสาขาแก้ไขไฟล์เดียวกันในแบบที่ Git ไม่สามารถกระทบยอดได้ด้วยตัวเอง ในโครงการฐานข้อมูลสถานการณ์ทั่วไปคือนักพัฒนาสองคนแก้ไขคําสั่งเดียวกันCREATE TABLE คนหนึ่งเพิ่ม Phone คอลัมน์ อีกคนเพิ่ม Addressและทั้งคู่สัมผัสพื้นที่เดียวกันของไฟล์

วิธีแก้ไขข้อขัดแย้ง:

1. ดึงการเปลี่ยนแปลงล่าสุดจาก main สาขาฟีเจอร์ของคุณ:

   git checkout feature/add-customer-phone
   git pull origin main
   

2. Git ทําเครื่องหมายส่วนที่ขัดแย้งกันในไฟล์ เปิดไฟล์และตรวจสอบทั้งสองเวอร์ชัน

3. แก้ไขไฟล์เพื่อรวมการเปลี่ยนแปลงทั้งสองในไวยากรณ์ที่ถูกต้อง

4. ทําเครื่องหมายข้อขัดแย้งว่าได้รับการแก้ไขแล้วและดําเนินการ:

   git add Tables/Customers.sql
   git commit -m "Resolve merge conflict: include both Phone and Address columns"
   

เคล็ดลับ

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

ตรวจสอบความถูกต้องหลังจากแก้ไขข้อขัดแย้ง

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

dotnet build MyDatabaseProject.sqlproj

📝 การสร้างที่สําเร็จจะยืนยันว่าการอ้างอิงวัตถุไม่เสียหาย และไวยากรณ์ T-SQL ถูกต้องหลังจากการผสาน

ประเด็นสําคัญ

ใช้สาขาคุณลักษณะที่มีอายุสั้นเพื่อแยกการเปลี่ยนแปลงฐานข้อมูล และรวมกลับไปเป็น main ผ่านคําขอดึงข้อมูล กําหนดค่าบิลด์ CI เป็นการตรวจสอบคําขอดึงข้อมูล เพื่อให้ dotnet build ตรวจสอบความถูกต้องของการเปลี่ยนแปลงที่เสนอทุกครั้งก่อนที่จะรวมเข้าด้วยกัน ข้อขัดแย้งในการผสานใน .sql ไฟล์โดยทั่วไปจะตรงไปตรงมา เนื่องจากแต่ละไฟล์มีการประกาศวัตถุเดียว สร้างโปรเจ็กต์ใหม่ทุกครั้งหลังจากแก้ไขข้อขัดแย้งในการผสานเพื่อตรวจสอบว่าการอ้างอิงออบเจ็กต์ทั้งหมดไม่เสียหาย ถัดไป คุณจะได้เรียนรู้วิธีตรวจจับเมื่อฐานข้อมูลสดไม่ซิงค์กับโปรเจ็กต์ของคุณ