เวิร์กโฟลว์การจัดสรร GitHub สำหรับการเปลี่ยนแปลงที่สำคัญ หรือใช้เวลานาน

ภาพรวม

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

ตัวอย่างของชนิดของการจัดสรรเหล่านี้ได้แก่:

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

คำศัพท์เฉพาะทาง

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

เวิร์กโฟลว์

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

ใช้โฟลว์ GitHub

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

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

ตอนนี้เรามาสร้างสาขาการทำงานใหม่ในที่เก็บภายในเครื่องของคุณเพื่อจับการเปลี่ยนแปลงที่เสนอของคุณ ถ้าคุณได้ตั้งค่า Git Bash แล้ว (ดู ติดตั้งเครื่องมือการเขียนเนื้อหา) คุณสามารถสร้างสาขาใหม่และ "ตรวจสอบ" สาขานั้นด้วยคำสั่งหนึ่งคำสั่งจากภายในที่เก็บข้อมูลที่ถูกลอกแบบขึ้นมาของคุณ:

git checkout -b "branchname"

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

การสร้างการเปลี่ยนแปลงของคุณ

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

การบันทึกการเปลี่ยนแปลงไปยังที่เก็บข้อมูลของคุณ

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

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

git add --all

ถัดไป คุณจำเป็นต้องยืนยันการเปลี่ยนแปลงที่บันทึกไว้ในที่เก็บข้อมูลภายในเครื่องของคุณ ซึ่งสามารถทำได้ใน Git Bash โดยการเรียกใช้:

git commit -m "Short Description of Changes Made"

ในท้ายที่สุด เนื่องจากคุณได้สร้างสาขานี้บนคอมพิวเตอร์ คุณจำเป็นต้องทำสำเนาในบัญชี GitHub.com ที่ทราบเกี่ยวกับเรื่องนี้ ถ้าคุณกำลังใช้ Git Bash การดำเนินการนี้สามารถทำได้โดยการเรียกใช้:

git push --set-upstream origin <branchname>

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

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

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

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

git checkout main
git pull upstream main
git checkout -b "branchname"

ตอนนี้คุณกลับมาอยู่ในสาขาใหม่แล้วและพร้อมแล้วที่จะเป็นผู้สนับสนุนผู้เชี่ยวชาญ

การประมวลคำขอดึงข้อมูล

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

การตรวจสอบความถูกต้อง

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

• ความสามารถในการรวมกัน: การทดสอบGitHubการรวมกันพื้นฐานจะเกิดขึ้นก่อนเพื่อตรวจสอบว่าการเปลี่ยนแปลงที่เสนอในสาขาของคุณนั้นขัดแย้งกับสาขาปลายทางหรือไม่ หากคำขอดึงข้อมูลระบุว่าการทดสอบนี้ล้มเหลว คุณต้องปรับเนื้อหาที่ก่อให้เกิดความขัดแย้งในการรวมก่อนดำเนินการต่อ
• CLA: หากคุณกำลังร่วมให้ข้อมูลในที่เก็บสาธารณะและไม่ใช่พนักงานของ Microsoft ทั้งนี้ขึ้นอยู่กับขนาดของการเปลี่ยนแปลงที่เสนอ คุณอาจถูกขอให้ลงนามในข้อตกลงสิทธิ์การให้ข้อมูลสั้นๆ (CLA) ในครั้งแรกที่คุณส่งคำขอดึงข้อมูลไปยังที่เก็บนั้น หลังจากดำเนินการขั้นตอน CLA แล้ว คำขอดึงข้อมูลของคุณจะได้รับการประมวลผล
• การติดป้ายกำกับ: ป้ายกำกับจะใช้กับคำขอดึงข้อมูลของคุณโดยอัตโนมัติเพื่อระบุสถานะของคำขอดึงข้อมูลนั้นในขณะที่ผ่านเวิร์กโฟลว์การตรวจสอบความถูกต้อง ตัวอย่างเช่น คำขอดึงข้อมูลใหม่อาจได้รับป้ายกำกับ "อย่ารวม (do-not-merge)" โดยอัตโนมัติ ซึ่งแสดงว่าคำขอดึงข้อมูลนั้นยังไม่เสร็จสิ้นขั้นตอนการตรวจสอบความถูกต้อง การตรวจทานและการลงชื่อออก
• การตรวจสอบความถูกต้องและสร้าง: การตรวจสอบโดยอัตโนมัติตรวจสอบว่าการเปลี่ยนแปลงของคุณผ่านการตรวจสอบความถูกต้องหรือไม่ การตรวจสอบความถูกต้องอาจทำให้เกิดคำเตือนหรือข้อผิดพลาดที่ทำให้คุณต้องทำการเปลี่ยนแปลงอย่างน้อยหนึ่งไฟล์ในคำขอดึงข้อมูลของคุณก่อนจึงจะสามารถรวมได้ ผลการตรวจสอบจะถูกเพิ่มเป็นข้อคิดเห็นในคำขอดึงข้อมูลของคุณเพื่อให้คุณพิจารณา และความคิดเห็นนั้นอาจส่งถึงคุณทางอีเมล
• การแสดงข้อมูล: หน้าบทความที่ได้รับผลกระทบจากการเปลี่ยนแปลงของคุณจะถูกใช้ในสภาพแสดงข้อมูลโดยอัตโนมัติเพื่อการตรวจทานหลังจากมีการตรวจสอบความถูกต้องและการสร้าง URL ที่แสดงตัวอย่างจะปรากฏในข้อความคิดเห็น PR
• รวมอัตโนมัติ: คำขอดึงข้อมูลอาจทำการผสานโดยอัตโนมัติหากผ่านการตรวจสอบความถูกต้องและเกณฑ์ที่กำหนด ในกรณีนี้ คุณไม่จำเป็นต้องดำเนินการใดๆ เพิ่มเติม

ตรวจทานและลงชื่อออก

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

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

เมื่อคำขอดึงข้อมูลไร้ปัญหาและถูกลงนาม-ออก การเปลี่ยนแปลงของคุณจะถูกผสานกลับเข้ากับสาขาแม่และคำขอดึงข้อมูลจะถูกปิด

กำลังเผยแพร่

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

หลังจากที่การร่วมสร้างข้อมูลของคุณได้รับการอนุมัติและผสาน กระบวนการตีพิมพ์ของ docs.microsoft.com จะเลือกเอกสารดังกล่าว เวลาการตีพิมพ์อาจแตกต่างกันไป ขึ้นอยู่กับทีมที่จัดการที่เก็บที่คุณกำลังร่วมสร้างข้อมูล บทความที่ได้รับการตีพิมพ์ภายใต้เส้นทางต่อไปนี้จะใช้งานได้ตามปกติในเวลาประมาณ 10.30 น. และ 15.30 น. ตามเวลาแปซิฟิก วันจันทร์ - ศุกร์:

• https://docs.microsoft.com/azure/
• https://docs.microsoft.com/aspnet/
• https://docs.microsoft.com/dotnet/
• https://docs.microsoft.com/enterprise-mobility-security

อาจใช้เวลาถึง 45 นาทีก่อนบทความจะปรากฏทางออนไลน์หลังจากตีพิมพ์ หลังจากตีพิมพ์บทความของคุณแล้ว คุณสามารถยืนยันการเปลี่ยนแปลงของคุณได้ที่ URL ที่เหมาะสม: https://docs.microsoft.com/<path-to-your-article-without-the-md-extension>

ขั้นตอนถัดไป

แค่นั้นเอง! คุณได้ทำการจัดสรรไปยังเนื้อหา docs.microsoft.com!

• เมื่อต้องการเรียนรู้เพิ่มเติมเกี่ยวกับหัวข้อต่างๆ เช่น Markdown และไวยากรณ์ส่วนขยาย Markdown ให้ดำเนินการต่อไปยังบทความ การอ้างอิง Markdown