แนวคิดพื้นฐานในการรวม Git

บทความนี้จะอธิบายแนวคิดพื้นฐานของ Git และกระบวนการรวม Git กับพื้นที่ทํางาน Fabric ของคุณ

การอนุญาต

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

หมายเหตุ

ตั้งแต่วันที่ 1 ธันวาคม 2026 เป็นต้นไป ผู้ใช้ที่ไม่มีสิทธิ์อ่าน-เขียนในรายการ workspace จะไม่สามารถใช้งานการผสานรวมกับ Git ได้ ข้อจํากัดนี้อาจส่งผลให้สูญเสียการเข้าถึงสินค้าบางรายการเนื่องจากป้ายชื่อระดับความลับและนโยบายการป้องกันที่ใช้กับสินค้าเหล่านั้น สําหรับข้อมูลเพิ่มเติม ดูการปกป้องข้อมูลใน Microsoft Fabric

สิทธิ์ Git ที่จําเป็นสําหรับการดําเนินการยอดนิยม

รายการต่อไปนี้แสดงให้เห็นว่าบทบาทพื้นที่ทํางานที่แตกต่างกันสามารถทําอะไรได้บ้าง โดยขึ้นอยู่กับสิทธิ์ของพวกเขาในที่เก็บ Git ของพวกเขา:

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

สิทธิ์ Fabric ที่จําเป็นสําหรับการดําเนินการที่ได้รับความนิยม

บทบาทพื้นที่ทํางาน

ตารางต่อไปนี้อธิบายถึงสิทธิ์ที่จําเป็นในพื้นที่ทํางาน Fabric เพื่อดําเนินการทั่วไปต่าง ๆ:

การปฏิบัติงาน	บทบาทพื้นที่ทํางาน
เชื่อมต่อพื้นที่ทํางานกับ Git repo	ผู้ดูแลระบบ
ซิงค์พื้นที่ทํางานด้วย Git repo	ผู้ดูแลระบบ
ยกเลิกการเชื่อมต่อพื้นที่ทํางานจาก Git repo	ผู้ดูแลระบบ
สลับสาขาในพื้นที่ทํางาน (หรือการเปลี่ยนแปลงการตั้งค่าการเชื่อมต่อ)	ผู้ดูแลระบบ (เสมอ); สมาชิก/ผู้สนับสนุนที่มีสิทธิ์ WRITE ในทุกรายการ (เมื่อการตั้งค่าพื้นที่ทํางาน อนุญาตให้ผู้ใช้ที่มีบทบาทผู้สนับสนุนเป็นอย่างน้อยเปลี่ยนสาขา Git เป็น ON)
ดูรายละเอียดการเชื่อมต่อ Git	ผู้ดูแลระบบ สมาชิก ผู้สนับสนุน
ดูพื้นที่ทํางาน 'สถานะ Git'	ผู้ดูแลระบบ สมาชิก ผู้สนับสนุน
อัปเดตจาก Git	บทบาทต่อไปนี้ทั้งหมด: ผู้สนับสนุนในพื้นที่ทํางาน (สิทธิ์เขียนบนรายการทั้งหมด) เจ้าของรายการ (ถ้าสวิตช์ผู้เช่าบล็อกการอัปเดตสําหรับผู้ที่ไม่ใช่เจ้าของ) สร้างตามการขึ้นต่อกันภายนอก (ถ้ามี)
ยอมรับการเปลี่ยนแปลงพื้นที่ทํางานใน Git	บทบาทต่อไปนี้ทั้งหมด: ผู้สนับสนุนในพื้นที่ทํางาน (สิทธิ์เขียนบนรายการทั้งหมด) เจ้าของรายการ (ถ้าสวิตช์ผู้เช่าบล็อกการอัปเดตสําหรับผู้ที่ไม่ใช่เจ้าของ) สร้างตามการขึ้นต่อกันภายนอก (ถ้ามี)
สร้างสาขา Git ใหม่จากภายใน Fabric	ผู้ดูแลระบบ (เสมอ); สมาชิก/ผู้สนับสนุนที่มีสิทธิ์ WRITE ในทุกรายการ (เมื่อการตั้งค่าพื้นที่ทํางาน อนุญาตให้ผู้ใช้ที่มีบทบาทผู้สนับสนุนเป็นอย่างน้อยเปลี่ยนสาขา Git เป็น ON)
แยกสาขาออกไปยังพื้นที่ทํางานอื่น	ผู้ดูแลระบบ สมาชิก ผู้สนับสนุน

บทบาท Git

ตารางต่อไปนี้อธิบายถึงสิทธิ์ของ Git ที่จําเป็นในการดําเนินการทั่วไปต่าง ๆ:

การปฏิบัติงาน	สิทธิ์ของ Git
เชื่อมต่อพื้นที่ทํางานกับ Git repo	อ่าน=อนุญาต
ซิงค์พื้นที่ทํางานด้วย Git repo	อ่าน=อนุญาต
ยกเลิกการเชื่อมต่อพื้นที่ทํางานจาก Git repo	ไม่จําเป็นต้องมีสิทธิ์
สลับสาขาในพื้นที่ทํางาน (หรือการเปลี่ยนแปลงการตั้งค่าการเชื่อมต่อ)	อ่าน=อนุญาต (ในที่เก็บเป้าหมาย/ไดเรกทอรี/สาขา)
ดูรายละเอียดการเชื่อมต่อ Git	อ่านหรือไม่
ดูพื้นที่ทํางาน 'สถานะ Git'	อ่าน=อนุญาต
อัปเดตจาก Git	อ่าน=อนุญาต
ยอมรับการเปลี่ยนแปลงพื้นที่ทํางานใน Git	อ่าน=อนุญาต ร่วม=อนุญาต นโยบายสาขาควรอนุญาตการยอมรับโดยตรง
สร้างสาขา Git ใหม่จากภายใน Fabric	บทบาท=เขียน สร้างสาขา=อนุญาต
แยกสาขาออกไปยังพื้นที่ทํางานอื่น	อ่าน=อนุญาต สร้างสาขา=อนุญาต

• หากคุณกําลังใช้โทเค็น access แบบละเอียด จําเป็นต้องมีสิทธิ์ต่อไปนี้สําหรับการดําเนินการทั่วไป:

การปฏิบัติงาน	สิทธิ์ของ Git
เชื่อมต่อพื้นที่ทํางานกับ Git repo	Contents= Access: อ่าน
ซิงค์พื้นที่ทํางานด้วย Git repo	Contents= Access: อ่าน
ยกเลิกการเชื่อมต่อพื้นที่ทํางานจาก Git repo	ไม่จําเป็นต้องมีสิทธิ์
สลับสาขาในพื้นที่ทํางาน (หรือการเปลี่ยนแปลงการตั้งค่าการเชื่อมต่อ)	Contents= Access: อ่าน (ในที่เก็บ/ไดเรกทอรี/สาขาเป้าหมาย)
ดูรายละเอียดการเชื่อมต่อ Git	Contents= Access: อ่านหรือไม่มี
ดูพื้นที่ทํางาน 'สถานะ Git'	Contents= Access: อ่าน
อัปเดตจาก Git	Contents= Access: อ่าน
ยอมรับการเปลี่ยนแปลงพื้นที่ทํางานใน Git	Contents= Access: อ่านและเขียน นโยบายสาขาควรอนุญาตการยอมรับโดยตรง
สร้างสาขา Git ใหม่จากภายใน Fabric	Contents= Access: อ่านและเขียน
แยกสาขาออกไปยังพื้นที่ทํางานอื่น	Content=อ่านและเขียน

• หากคุณใช้โทเค็น access แบบคลาสสิก ต้องเปิดใช้ขอบเขตที่เก็บ:

เชื่อมต่อและซิงค์

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

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

หากคุณไม่เลือกเนื้อหาที่จะซิงค์ คุณจะไม่สามารถทํางานต่อไปได้

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

โฟลเดอร์

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

หมายเหตุ

เนื่องจากโครงสร้างโฟลเดอร์ถูกเก็บไว้ ถ้าพื้นที่ทํางานของคุณมีโฟลเดอร์และโฟลเดอร์ Git ที่เชื่อมต่อยังไม่มีโฟลเดอร์ย่อย จะถือว่าโฟลเดอร์นั้นแตกต่างกัน คุณได้รับสถานะ uncommitted changes ใน control panel ต้นทาง และคุณต้องยอมรับการเปลี่ยนแปลงกับ Git ก่อนที่จะอัปเดตพื้นที่ทํางาน หากคุณอัปเดตก่อนโครงสร้างโฟลเดอร์ Git เขียนทับพื้นที่ทํางาน โครงสร้างโฟลเดอร์ สําหรับข้อมูลเพิ่มเติม ให้ดู การเปลี่ยนแปลงโฟลเดอร์ 'การจัดการ ' อย่างปลอดภัย

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

การจัดการการเปลี่ยนแปลงโฟลเดอร์อย่างปลอดภัย

หากพื้นที่ทํางานของคุณมีโฟลเดอร์และโฟลเดอร์ Git ที่เชื่อมต่อยังไม่มีโฟลเดอร์ย่อย โฟลเดอร์ดังกล่าวจะถือว่าแตกต่างกันเนื่องจากโครงสร้างโฟลเดอร์นั้นแตกต่างกัน เมื่อคุณเชื่อมต่อพื้นที่ทํางานที่มีโฟลเดอร์กับ Git คุณจะได้รับสถานะ uncommitted changes ใน control panel ต้นทาง และคุณจําเป็นต้องยอมรับการเปลี่ยนแปลงกับ Git ก่อนที่จะอัปเดตพื้นที่ทํางาน

หากคุณไม่สามารถเปลี่ยนแปลงสาขาที่เชื่อมต่อได้โดยตรง เนื่องจากนโยบายหรือสิทธิ์ของสาขา เราขอแนะนําให้ใช้ตัวเลือก Checkout Branch:

1. เช็คเอาท์สาขาใหม่ : ใช้คุณลักษณะสาขาการชําระเงินเพื่อสร้างสาขาที่มีสถานะอัปเดตของพื้นที่ทํางาน Fabric ของคุณ
2. ยอมรับการเปลี่ยนแปลงโฟลเดอร์: การเปลี่ยนแปลงโฟลเดอร์พื้นที่ทํางานใด ๆ แล้วสามารถถูกบันทึกไปยังสาขาใหม่นี้
3. ผสานการเปลี่ยนแปลง: ใช้คําขอดึงข้อมูลทั่วไป (PR) และกระบวนการผสานเพื่อรวมการอัปเดตเหล่านี้กลับไปยังสาขาเดิม

เชื่อมต่อกับพื้นที่ทํางานที่ใช้ร่วมกัน

ถ้าคุณพยายามเชื่อมต่อกับพื้นที่ทํางานที่เชื่อมต่อกับ Git อยู่แล้ว คุณอาจได้รับข้อความต่อไปนี้:

ไปที่แท็บ บัญชี ทางด้านขวาของ control panel ต้นทาง เลือกบัญชี และเชื่อมต่อ

สถานะของ Git

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

แต่ละรายการมีสถานะใดสถานะหนึ่งต่อไปนี้:

• ซิงค์แล้ว (รายการจะเหมือนกันในพื้นที่ทํางานและสาขาของ Git)
• ข้อขัดแย้ง (รายการมีการเปลี่ยนแปลงทั้งในพื้นที่ทํางานและสาขา Git)
• รายการที่ไม่รองรับ
• การเปลี่ยนแปลงที่ยังไม่ได้ยอมรับในพื้นที่ทํางาน
• จําเป็นต้องมีการอัปเดตจาก Git
• หน่วยข้อมูลจะเหมือนกันในทั้งสองที่ แต่จําเป็นต้องอัปเดตเป็นยอมรับล่าสุด

ซิงค์ข้อมูล

ข้อมูลต่อไปนี้จะปรากฏที่ด้านล่างของหน้าจอ

• สาขาที่เชื่อมต่อกัน
• เวลาของการซิงก์ล่าสุด
• ลิงก์ไปยังยอมรับล่าสุดที่ซิงค์กับพื้นที่ทํางาน

บานหน้าต่างตัวควบคุมแหล่งข้อมูล

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

เลือกไอคอนตัวควบคุม แหล่งข้อมูล เพื่อเปิดแผงควบคุมแหล่งข้อมูล

บานหน้าต่างตัวควบคุมแหล่งข้อมูลมีสามแท็บที่ด้านข้าง:

• ยอมรับและอัปเดต
• สาขา
• รายละเอียดบัญชี

ยอมรับและอัปเดต

เมื่อมีการเปลี่ยนแปลงในพื้นที่ทํางานหรือสาขา Git ไอคอนตัวควบคุมแหล่งข้อมูลจะแสดงจํานวนของรายการที่แตกต่างกัน เลือกไอคอนตัวควบคุมแหล่งที่มาเพื่อเปิด control panel แหล่งที่มา

แผง บันทึกและอัปเดต มีสองส่วน

การเปลี่ยนแปลง แสดงจํานวนของรายการที่มีการเปลี่ยนแปลงในพื้นที่ทํางานและจําเป็นต้องมอบหมายให้กับ Git การอัปเดต แสดงจํานวนรายการที่ปรับเปลี่ยนในสาขา Git และจําเป็นต้องอัปเดตไปยังพื้นที่ทํางาน

ในแต่ละส่วน รายการที่เปลี่ยนแปลงจะแสดงรายการด้วยไอคอนที่ระบุสถานะ:

• ใหม่
• แก้ไข
• ลบ
• ความขัดแย้ง
• การเปลี่ยนแปลงเดียวกัน

ปุ่ม รีเฟรชด้านบนของแผงจะอัปเดตรายการการเปลี่ยนแปลงและการอัปเดต

มอบ

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

อัปเดต

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

อ่านเพิ่มเติมเกี่ยวกับวิธีการบันทึกและอัปเดต อ่านเพิ่มเติมเกี่ยวกับกระบวนการอัปเดตและวิธีการ แก้ไขข้อขัดแย้ง

สาขา

แท็บ Branches ของ control panel ต้นทางช่วยให้คุณสามารถจัดการสาขาของคุณและดําเนินการที่เกี่ยวข้องกับสาขาได้ มีส่วนดังต่อไปนี้:

• แยกสาขาไปยังพื้นที่ทํางานอื่น (ผู้สนับสนุนขึ้นไป): สร้างพื้นที่ทํางานแบบแยกสาขาใหม่ หรือสลับสาขาที่เชื่อมต่อของพื้นที่ทํางานแบบแยกสาขาที่มีอยู่เป็นสาขา Git ใหม่ที่สร้างขึ้นตามการคอมมิตล่าสุดของพื้นที่ทํางานต้นทาง
• เช็คเอาท์สาขา ใหม่ (ต้องเป็นผู้ดูแลระบบพื้นที่ทํางาน): สร้างสาขาใหม่ตามการยอมรับที่ซิงค์ล่าสุดในพื้นที่ทํางาน และเปลี่ยนแปลงการเชื่อมต่อ Git ในพื้นที่ทํางานปัจจุบัน ซึ่งจะไม่เปลี่ยนแปลงเนื้อหาพื้นที่ทํางาน
• สลับสาขา (ผู้ดูแลระบบพื้นที่ทํางาน หรือสมาชิก/ผู้สนับสนุนที่มีสิทธิ์เขียนรายการทั้งหมดเมื่อ เปิดใช้งาน อนุญาตให้ผู้ใช้ที่มีบทบาทผู้สนับสนุนอย่างน้อยเปลี่ยนสาขา Git ): ซิงค์พื้นที่ทํางานกับสาขาใหม่หรือสาขาอื่นที่มีอยู่ และแทนที่รายการทั้งหมดในพื้นที่ทํางานด้วยเนื้อหาของสาขาที่เลือก

• สาขาที่เกี่ยวข้อง: แท็บ สาขาที่เกี่ยวข้อง ยังมีรายการของพื้นที่ทํางานที่เกี่ยวข้องที่คุณสามารถเลือกและสลับไปใช้ได้ พื้นที่ทํางานที่เกี่ยวข้องเป็นหนึ่งในสอง:
  1. พื้นที่ทํางานแบบแยกสาขา
  2. มีคุณสมบัติการเชื่อมต่อเดียวกันกับสาขาปัจจุบัน เช่น องค์กร โครงการ ที่เก็บ และโฟลเดอร์ git เดียวกัน คุณลักษณะนี้ช่วยให้คุณสามารถนําทางไปยังพื้นที่ทํางานที่เกี่ยวข้องจากบริบทของงานปัจจุบันของคุณโดยไม่ต้องค้นหาในพื้นที่ทํางานเหล่านั้นในรายการพื้นที่ทํางาน Fabric ของคุณ หากต้องการเปิดพื้นที่ทํางานที่เกี่ยวข้อง ให้เลือกรายการในรายการ

สําหรับข้อมูลเพิ่มเติม ให้ดูที่ การแยกสาขาข้อจํากัด

รายละเอียดบัญชี

แท็บ รายละเอียดบัญชี แสดงรายละเอียดของบัญชี GitHub ที่ผู้ใช้เชื่อมต่ออยู่ ซึ่งมีสองส่วน ส่วนบนสุดแสดงตัวให้บริการ Git และชื่อบัญชี ส่วนด้านล่างแสดงที่เก็บข้อมูลและสาขาที่พื้นที่ทํางานเชื่อมต่ออยู่ ปัจจุบัน แท็บนี้พร้อมใช้งานสําหรับพื้นที่ทํางานที่เชื่อมต่อกับ GitHub เท่านั้น

รายละเอียดบัญชี GitHub ประกอบด้วย:

• รายละเอียดบัญชี Git

• ผู้จัดหา

• ชื่อบัญชี

• ที่เก็บ Git

• สาขา

ข้อควรพิจารณาและข้อจำกัด

ข้อจํากัดการรวม Git ทั่วไป

หมายเหตุ

ตั้งแต่วันที่ 1 พฤศจิกายน 2026 เป็นต้นไป ผู้ใช้ที่ไม่มีสิทธิ์อ่าน-เขียนในรายการพื้นที่ทํางานจะไม่สามารถใช้การรวม Git ได้ ข้อจํากัดนี้อาจส่งผลให้สูญเสียการเข้าถึงสินค้าบางรายการเนื่องจากป้ายชื่อระดับความลับและนโยบายการป้องกันที่ใช้กับสินค้าเหล่านั้น สําหรับข้อมูลเพิ่มเติม ดูการปกป้องข้อมูลใน Microsoft Fabric

• วิธีการรับรองความถูกต้องใน Fabric ต้องมีความแข็งแกร่งเป็นวิธีการรับรองความถูกต้องสําหรับ Git อย่างน้อย ตัวอย่างเช่น ถ้า Git ต้องการการรับรองความถูกต้องแบบหลายปัจจัย Fabric จําเป็นต้องรับรองความถูกต้องแบบหลายปัจจัยเช่นกัน

• ชุดข้อมูล Power BI ที่เชื่อมต่อกับ Analysis Services ไม่ได้รับการสนับสนุนในขณะนี้

• ถ้าคุณใช้ข้อมูลประจําตัวของพื้นที่ทํางานในวัตถุเดียวและยืนยันกับ Git จะสามารถอัปเดตได้ (กลับไปยังพื้นที่ทํางานพื้นที่ทํางานแบบแฟบริค) เฉพาะในพื้นที่ทํางานที่เชื่อมต่อกับข้อมูลประจําตัวเดียวกันเท่านั้น โปรดระวังเนื่องจากสิ่งนี้ยังส่งผลต่อคุณลักษณะเช่นการแตกสาขา

• ระบบไม่รองรับแบบจําลองย่อย

• ไม่รองรับบริการคลาวด์แบบ Sovereign

• พื้นที่ทํางาน Fabric สามารถมีรายการ Fabric1,000 รายการได้สูงสุด Power BI (ดู ขีดจํากัดรายการพื้นที่ทํางาน) ขีดจํากัดนี้ใช้กับรายการทั้งหมดที่จัดการผ่านการรวม Git หากพื้นที่ทํางานของคุณใกล้ถึงขีดจํากัดนี้ ให้พิจารณาแยกออกเป็นชุดสิ่งประดิษฐ์ขนาดเล็ก โดยวางแต่ละชุดในพื้นที่ทํางานแยกต่างหากและเชื่อมโยงไปยังสาขา Git อื่น หรือจัดระเบียบสาขาเดียวลงในโฟลเดอร์ต่างๆ สําหรับรายละเอียดเกี่ยวกับพฤติกรรมการซิงค์เมื่อสาขา Git เกินขีดจํากัดนี้ โปรดดู ข้อจํากัดของพื้นที่ทํางาน

Azure ข้อจํากัดของ DevOps

• Azure DevOps ไม่ได้รับการสนับสนุนหากเปิดใช้งาน เปิดใช้งานการตรวจสอบความถูกต้องของนโยบาย IP Conditional Access
• หากพื้นที่ทํางานและที่เก็บ Git อยู่ในสองภูมิภาคทางภูมิศาสตร์ที่แตกต่างกัน ผู้ดูแลระบบผู้เช่าต้องเปิดใช้งานการส่งออกข้ามภูมิศาสตร์
• หากองค์กรของคุณกําหนดค่า เงื่อนไข access ตรวจสอบให้แน่ใจว่า Power BI Service มี conditions set เหมือนกันเพื่อให้การรับรองความถูกต้องทํางานได้ตามที่คาดไว้
• มีการใช้ขีดจํากัดขนาดการคอมมิตต่อไปนี้:
  • 25 MB โดยใช้ตัวเชื่อมต่อ Azure DevOps กับบริการหลัก
  • 125 MB โดยใช้บัญชี Microsoft Entra ID การลงชื่อเข้าระบบครั้งเดียว (SSO) เริ่มต้นและตัวเชื่อมต่อ Azure DevOps ที่มีผู้ใช้หลัก

GitHub

• รองรับเฉพาะ GitHub เวอร์ชันคลาวด์เท่านั้น ไม่สนับสนุนในองค์กร
• GitHub ไม่สามารถบังคับใช้ การตรวจสอบข้ามภูมิศาสตร์
• ขนาดรวมทั้งหมดของไฟล์ที่จะบันทึกในครั้งเดียวจะถูกจํากัดไว้ที่ 50 MB ดังนั้น ถ้าคุณมีหลายรายการที่ต้องยอมรับ บางครั้งอาจจําเป็นต้องแยกรายการเหล่านั้นออกเป็นบันทึกที่แยกต่างหากสองสามรายการ สําหรับข้อมูลเพิ่มเติมเกี่ยวกับการกําหนดไฟล์ โปรดดูคู่มือการแก้ไขปัญหาของเรา

ข้อจํากัดของ GitHub Enterprise

ไม่รองรับเวอร์ชันและการตั้งค่า GitHub Enterprise บางเวอร์ชัน ตัวอย่างเช่น:

• ไม่รองรับ GitHub Enterprise Server ที่มี custom domain แม้ว่าอินสแตนซ์จะสามารถเข้าถึงได้แบบสาธารณะก็ตาม
• เซิร์ฟเวอร์ GitHub Enterprise ที่โฮสต์บนเครือข่ายส่วนตัว
• รายการอนุญาต IP

การพิจารณาการโยกย้าย Azure DevOps ไปยัง GitHub Enterprise

หากทีมของคุณใช้การรวม Fabric Git และกําลังประเมินการโยกย้ายจาก Azure DevOps ไปยัง GitHub Enterprise ขอแนะนําให้เรียกใช้การทดสอบการตรวจสอบความถูกต้องเพื่อให้แน่ใจว่าฟังก์ชันการรวม Git ยังคงไม่ได้รับผลกระทบ การรวม Fabric Git อาศัย API ของผู้ให้บริการ Git พื้นฐาน ซึ่งแตกต่างกันในความสามารถและข้อจํากัดระหว่าง Azure DevOps และ GitHub Enterprise ตามที่อธิบายไว้ข้างต้น

ความแตกต่างระหว่างการรวม Git และพฤติกรรมการกู้คืนไอเท็มถังรีไซเคิล

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

การบรรเทา

ลบไอเท็มที่สร้างขึ้นใหม่โดยการรวม Git หลังจากลบรายการที่ซ้ํากันแล้ว การดําเนินการ Git ควรกลับมาทํางานต่อตามปกติ

หมายเหตุเพิ่มเติม

การรวม Git สร้างนิยามไอเท็มใหม่เท่านั้น และไม่เรียกคืนข้อมูลไอเท็ม ในทางตรงกันข้าม การคืนค่ารายการจากถังรีไซเคิลจะคืนค่าทั้งข้อกําหนดของรายการและข้อมูลของรายการ

ข้อจํากัดของพื้นที่ทํางาน

• เฉพาะผู้ดูแลระบบพื้นที่ทํางานเท่านั้นที่สามารถจัดการการเชื่อมต่อกับ Git Repo เช่น การเชื่อมต่อ การตัดการเชื่อมต่อ หรือการเพิ่มสาขา
  เมื่อเชื่อมต่อแล้ว ทุกคนที่มีสิทธิ์สามารถทํางานในพื้นที่ทํางานได้
• พื้นที่ทํางานที่ติดตั้งแอปเทมเพลตจะไม่สามารถเชื่อมต่อกับ Git ได้
• MyWorkspace ไม่สามารถเชื่อมต่อกับผู้ให้บริการ Git ได้
• พื้นที่ทํางานสามารถมีได้สูงสุด 1,000 รายการ ถ้าสาขา Git มีมากกว่า 1,000 รายการ การซิงค์เนื้อหาไปยังพื้นที่ทํางานจะล้มเหลว เพื่อหลีกเลี่ยงข้อจํากัดนี้ ให้พิจารณาแยก artifacts ออกเป็นชุดเล็กๆ แต่ละชุดควรอยู่ในพื้นที่ทํางานแยกต่างหากและเชื่อมโยงกับสาขา Git ที่แตกต่างกัน หรือจัดระเบียบเป็นโฟลเดอร์ต่างๆ ภายในสาขาเดียว หากต้องการอ่านเพิ่มเติม ให้ทําตามขีดจํากัดรายการพื้นที่ทํางาน

ข้อจํากัดสาขาและโฟลเดอร์

• ความยาวสูงสุดของชื่อสาขาคือ 244 อักขระ
• ความยาวสูงสุดของเส้นทางแบบเต็มสําหรับชื่อแฟ้มคือ 250 อักขระ ชื่อที่ยาวขึ้นล้มเหลว
• ขนาดไฟล์สูงสุดคือ 25 MB
• โครงสร้างโฟลเดอร์ถูกเก็บไว้ลึกถึง 10 ระดับ
• ไม่แนะนําให้ดาวน์โหลดรายงาน/ชุดข้อมูลเป็น .pbix จากบริการหลังจากปรับใช้ด้วยการรวม Git เนื่องจากผลลัพธ์ไม่น่าเชื่อถือ เราขอแนะนําให้ใช้ Power BI Desktop เพื่อดาวน์โหลดรายงาน/ชุดข้อมูลเป็น .pbix
• หากชื่อที่แสดงของรายการมีลักษณะใด ๆ เหล่านี้ โฟลเดอร์ Git จะถูกเปลี่ยนชื่อเป็น ID เชิงตรรกะ (Guid) และชนิด:
  • มีอักขระมากกว่า 256 ตัว
  • ลงท้ายด้วย หรือช่องว่าง
  • ประกอบด้วยอักขระห้ามใช้งานตามที่อธิบายไว้ในข้อจํากัดชื่อไดเรกทอรี
• เมื่อคุณเชื่อมต่อพื้นที่ทํางานที่มีโฟลเดอร์กับ Git คุณจําเป็นต้องบันทึกการเปลี่ยนแปลง Git repo หากโครงสร้างโฟลเดอร์ แตกต่างกัน

ข้อจํากัดของชื่อไดเรกทอรี

• ชื่อของไดเรกทอรีที่เชื่อมต่อกับที่เก็บ Git มีข้อจํากัดในการตั้งชื่อดังต่อไปนี้:

  • ชื่อไดเรกทอรีไม่สามารถเริ่มต้นหรือลงท้ายด้วยช่องว่างหรือแท็บ
  • ชื่อไดเรกทอรีไม่สามารถมีอักขระใดๆ ต่อไปนี้: "/:<>\*?|

• โฟลเดอร์รายการ (โฟลเดอร์ที่มีแฟ้มรายการ) ไม่สามารถมีอักขระใด ๆ ต่อไปนี้ได้: ":<>\*?| ถ้าคุณเปลี่ยนชื่อโฟลเดอร์เป็นอักขระใดอักขระหนึ่งที่มีอักขระเหล่านี้ Git จะไม่สามารถเชื่อมต่อหรือซิงค์กับพื้นที่ทํางานและจะเกิดข้อผิดพลาดขึ้นได้

ขีดจํากัดการซิงค์และยอมรับ

• คุณสามารถซิงค์ได้ครั้งละหนึ่งทิศทางเท่านั้น คุณไม่สามารถยอมรับและอัปเดตในเวลาเดียวกันได้
• ป้ายชื่อระดับความลับไม่ได้รับการสนับสนุนและการส่งออกรายการที่มีป้ายชื่อระดับความลับอาจถูกปิดใช้งาน หากต้องการยอมรับรายการที่มีป้ายชื่อระดับความลับโดยไม่มีป้ายชื่อระดับความลับ โปรด ขอความช่วยเหลือจากผู้ดูแลระบบ ของคุณ
• ทํางานกับ รายการที่จํากัด รายการที่ไม่ได้รับการรองรับในโฟลเดอร์จะถูกละเว้น
• ไม่อนุญาตให้ใช้ชื่อการทําซ้ํา แม้ว่า Power BI จะอนุญาตให้ทําซ้ําชื่อ การอัปเดต ยอมรับ หรือยกเลิกการดําเนินการจะล้มเหลว
• ไม่รองรับ B2B
• การแก้ปัญหา ความขัดแย้งจะทําบางส่วนใน Git
• ในระหว่างกระบวนการการยอมรับไปยัง Git บริการ Fabric จะลบไฟล์ภายในโฟลเดอร์รายการที่ไม่ใช่ส่วนหนึ่งของข้อกําหนดรายการ แฟ้มที่ไม่เกี่ยวข้องที่ไม่อยู่ในโฟลเดอร์รายการจะไม่ถูกลบออก
• หลังจากที่คุณบันทึกการเปลี่ยนแปลงคุณอาจสังเกตเห็นการเปลี่ยนแปลงที่ไม่คาดคิดบางอย่างไปยังรายการที่คุณไม่ได้ทํา การเปลี่ยนแปลงเหล่านี้ไม่มีนัยสําคัญทางความหมายและสามารถเกิดขึ้นได้ด้วยเหตุผลหลายประการ ตัวอย่าง:
  • การเปลี่ยนแปลงแฟ้มข้อกําหนดหน่วยข้อมูลด้วยตนเอง การเปลี่ยนแปลงเหล่านี้ถูกต้อง แต่อาจแตกต่างจากถ้าทําผ่านตัวแก้ไข ตัวอย่างเช่น ถ้าคุณเปลี่ยนชื่อคอลัมน์แบบจําลองความหมายใน Git และนําเข้าการเปลี่ยนแปลงนี้ไปยังพื้นที่ทํางาน ในครั้งถัดไปที่คุณยอมรับการเปลี่ยนแปลงไปยังแบบจําลอง ความหมาย ไฟล์ bim จะลงทะเบียนเป็นการเปลี่ยนแปลงและคอลัมน์ที่ปรับเปลี่ยนแล้วจะถูกส่งไปยังด้านหลังของ columns อาร์เรย์ ทั้งนี้เนื่องจากกลไก AS ที่สร้าง ไฟล์ bim จะส่งคอลัมน์ที่เปลี่ยนชื่อไปยังส่วนท้ายของอาร์เรย์ การเปลี่ยนแปลงนี้จะไม่มีผลต่อวิธีดําเนินการของรายการ
  • บันทึกไฟล์ที่ใช้ตัวแบ่งบรรทัด CRLF บริการนี้ใช้ ตัวแบ่งบรรทัด LF (ตัวดึงข้อมูลบรรทัด) หากคุณมีไฟล์รายการใน Git repo ที่มีตัวแบ่งบรรทัด CRLF เมื่อคุณยอมรับจากบริการไฟล์เหล่านี้จะเปลี่ยนเป็น LF ตัวอย่างเช่น หากคุณเปิดรายงานในเดสก์ท็อป ให้บันทึกไฟล์ project (.pbip) และอัปโหลดไปยัง Git โดยใช้ CRLF
• การรีเฟรชแบบจําลองความหมายโดยใช้ API การรีเฟรชที่ปรับปรุงแล้วจะทําให้เกิด Git diff หลังจากการรีเฟรชแต่ละครั้ง

เนื้อหาที่เกี่ยวข้อง

• จัดการสาขา
• แก้ไขข้อผิดพลาดและข้อขัดแย้ง