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

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

การอนุญาต

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

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

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

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

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

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

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

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

บทบาท Git

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

ที่เก็บ Azure

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

ที่เก็บ GitHub

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

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

• ถ้าคุณกําลังใช้โทเค็นการเข้าถึงแบบคลาสสิก ขอบเขตที่เก็บจะต้องเปิดใช้งาน:

  

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

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

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

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

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

โฟลเดอร์

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

หมายเหตุ

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

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

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

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

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

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

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

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

ไปที่ แท็บ บัญชี ทางด้านขวาของแผงควบคุม แหล่งข้อมูล เลือกบัญชี และเชื่อมต่อ

สถานะของ Git

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

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

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

ซิงค์ข้อมูล

ตราบใดที่คุณเชื่อมต่อข้อมูลต่อไปนี้จะปรากฏขึ้นที่ด้านล่างของหน้าจอ:

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

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

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

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

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

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

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

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

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

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

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

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

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

มอบ

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

อัปเดต

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

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

เงื่อนไขย่อย

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

• การดําเนินการที่คุณสามารถทําได้ในสาขาปัจจุบัน:

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

  

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

  

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

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

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

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

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

  • ผู้จัดหา
  • ชื่อบัญชี

• ที่เก็บ Git

• สาขา

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

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

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

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

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

ข้อจํากัด GitHub

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

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

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

• GitHub Enterprise Cloud ที่มีที่เก็บข้อมูล (ghe.com)
• เซิร์ฟเวอร์ GitHub Enterprise ที่มีโดเมนแบบกําหนดเองไม่ได้รับการสนับสนุนแม้ว่าอินสแตนซ์จะสามารถเข้าถึงได้โดยสาธารณะ
• เซิร์ฟเวอร์ Github Enterprise ที่โฮสต์บนเครือข่ายส่วนตัว
• รายการอนุญาต IP

ข้อควรพิจารณาในการโยกย้าย Azure DevOps ไปยัง GitHub Enterprise

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

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

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

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

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

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

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

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

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

การแตกสาขาออกข้อจํากัด

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

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

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

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

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