ฉันจะใช้ git-worktree เพื่ออะไร

ผมอ่านโพสต์บน Github Git-worktree พวกเขาเขียน:

สมมติว่าคุณกำลังทำงานในพื้นที่เก็บข้อมูล Git ในสาขาที่เรียกว่าfeatureเมื่อผู้ใช้รายงานข้อบกพร่องเร่งด่วนสูงmasterมา ขั้นแรกให้คุณสร้างแผนผังการทำงานที่เชื่อมโยงกับสาขาใหม่hotfixเช็คเอาท์สัมพันธ์กับต้นแบบ […] คุณสามารถแก้ไขข้อบกพร่องผลักโปรแกรมแก้ไขด่วนและสร้างคำขอดึง

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

ในทางกลับกันการใช้ git-worktree มีข้อ จำกัด ของตัวเอง:

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

ทำไมฉันถึงต้องเลือกขั้นตอนการทำงานที่ซับซ้อนมากขึ้นสำหรับปัญหาที่ได้รับการแก้ไขแล้ว?

มีอะไรที่เกี่ยวกับสิ่งgit-worktreeที่ไม่สามารถทำได้ล่วงหน้าและนั่นเป็นเหตุผลที่ทำให้คุณสมบัติใหม่ที่ซับซ้อนนี้ทั้งหมดใช่หรือไม่

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

ด้วย worktree คุณสามารถหลีกเลี่ยงการกำหนดค่าใหม่อย่างคงที่ ชำระเงินสาขาเก่าเหล่านั้นในโฟลเดอร์แยกโดยใช้ worktree สำหรับแต่ละสาขาคุณมีโครงการ IDE อิสระ

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

ฉันเห็นการใช้งานบางอย่างสำหรับสิ่งนี้

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

ดังนั้นgit-worktreeฉันจึงสามารถมีแนวคิดที่สองที่เปิดตัวสำหรับสาขาอื่นที่ทำงานอยู่ที่นั่น

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

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

การใช้งานที่ชัดเจนอย่างหนึ่งคือการเปรียบเทียบลักษณะการทำงาน (ไม่ใช่แหล่งที่มา) ของรุ่นต่าง ๆ พร้อมกันตัวอย่างเช่นเว็บไซต์หรือหน้าเว็บต่าง ๆ

ฉันลองสิ่งนี้ในเครื่อง

• page1สร้างไดเรกทอรี

• ภายในสร้างไดเรกทอรีsrcและgit initมัน

• ในการsrcสร้างpage1.htmlด้วยเนื้อหาเล็กน้อยและกระทำมัน

• $ git branch ver0

• $ git worktree add ../V0 ver0

• ในsrcต้นแบบเพิ่มข้อความเพิ่มเติมpage1.htmlและยอมรับมัน

• $ git branch sty1

• แก้ไขpage1.htmlในsty1สาขา (เพิ่มสไตล์ CSS ที่โดดเด่น) และเพิ่มกระทำมัน

• $ git worktree add ../S1 sty1

ตอนนี้คุณสามารถใช้เว็บเบราว์เซอร์เพื่อเปิดและดูทั้ง 3 เวอร์ชันพร้อมกัน:

• ..\page1\src\page1.html // git อะไรก็ได้ที่มีอยู่ในปัจจุบัน

• ..\page1\V0\page1.html // รุ่นเริ่มต้น

• ..\page1\S1\page1.html // เวอร์ชันที่มีสไตล์การทดลอง

1. มีเหตุผลที่ถูกต้องว่าทำไมคุณอาจต้องการ / ต้องการหลาย worktrees ในระบบไฟล์พร้อมกัน

   • จัดการไฟล์ที่เช็คเอาต์ในขณะที่ต้องการเปลี่ยนแปลงที่อื่น (เช่นการรวบรวม / ทดสอบ)

   • การกระจายไฟล์ผ่านเครื่องมือ diff ทั่วไป

   • ในระหว่างการรวมที่ขัดแย้งกันฉันมักจะต้องการท่องไปตามซอร์สโค้ดเพราะมันอยู่ด้านแหล่งที่มาในขณะที่การแก้ไขข้อขัดแย้งในไฟล์

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

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

2. บางคนถามว่า "ทำไมไม่ทำโคลนในพื้นที่หลายแห่ง" มันเป็นความจริงที่มีการตั้งค่าสถานะ "--local" คุณไม่ต้องกังวลเกี่ยวกับการใช้พื้นที่ดิสก์เพิ่มเติม (หรือความคิดที่คล้ายกัน) นี้คือสิ่งที่ฉันได้ทำมาถึงจุดนี้ ข้อได้เปรียบในการใช้งานของ worktrees ที่เชื่อมโยงกับโคลนในพื้นที่คือ:

   1. ด้วยโคลนนิ่งท้องถิ่น worktrees พิเศษของคุณ (ซึ่งอยู่ในโคลนนิ่งท้องถิ่น) ก็ไม่สามารถเข้าถึงที่มาหรือสาขาต้นน้ำ 'แหล่งกำเนิด' ในโคลนจะไม่เหมือนกับ 'แหล่งกำเนิด' ในโคลนแรก

      • วิ่งgit log @{u}..หรือgit diff origin/feature/other-featureมีประโยชน์มากและสิ่งเหล่านี้ไม่สามารถทำได้อีกต่อไปหรือยากกว่านี้ ความคิดเหล่านี้เป็นไปได้ในทางเทคนิคกับการโคลนนิ่งท้องถิ่นผ่านการเลือกประเภทของวิธีการทำงานที่หลากหลาย แต่การแก้ปัญหาทุกอย่างที่คุณทำได้ทำได้ดีกว่าและ / หรือง่ายขึ้นผ่านทางเวิร์คช็อปที่เชื่อมโยงกัน

   2. คุณสามารถแชร์การอ้างอิงระหว่าง worktrees หากคุณต้องการเปรียบเทียบหรือยืมการเปลี่ยนแปลงจากสาขาอื่นในท้องถิ่นคุณสามารถทำได้แล้ว

tl; dr: ทุกครั้งที่คุณต้องการให้มีต้นไม้ทำงานสองต้นเช็คเอาท์พร้อมกันไม่ว่าด้วยเหตุผลใดก็ตามgit-worktreeเป็นวิธีที่รวดเร็วและประหยัดพื้นที่

หากคุณสร้าง worktree อื่นส่วนใหญ่ของ repo (เช่น.git) จะถูกแบ่งปันซึ่งหมายความว่าถ้าคุณสร้างสาขาหรือดึงข้อมูลในขณะที่คุณอยู่ในต้นไม้ทำงานหนึ่งมันจะสามารถเข้าถึงได้จากต้นไม้ทำงานอื่น ๆ ที่คุณมี สมมติว่าคุณต้องการเรียกใช้ชุดทดสอบบนสาขา foo โดยไม่ต้องกดที่ใดที่หนึ่งเพื่อโคลนมันและคุณต้องการหลีกเลี่ยงความยุ่งยากในการโคลน repo ของคุณภายในเครื่องการใช้git-worktreeเป็นวิธีที่ดีในการสร้างเช็คเอาต์ใหม่ของรัฐใน สถานที่แยกต่างหากไม่ว่าจะชั่วคราวหรือถาวร เช่นเดียวกับโคลนสิ่งที่คุณต้องทำเมื่อลบเสร็จแล้วการอ้างอิงถึงมันจะถูกเก็บขยะหลังจากเวลาผ่านไป

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

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

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

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

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

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

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

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

ฉันใช้git worktreeสำหรับการพัฒนาการเรียนรู้ของเครื่อง

ฉันมีรหัสการทำงานหลักแล้วฉันต้องการแยกสาขาของการทดลองที่แตกต่างกัน (อัลกอริทึมที่แตกต่างกันและพารามิเตอร์ไฮเปอร์พารามิเตอร์ที่แตกต่างกัน) git worktreeอนุญาตให้ฉันรวมdvc เข้ากับโค้ดรุ่นต่าง ๆ ของฉันซึ่งมีความเชี่ยวชาญในอัลกอริทึมที่แตกต่างกัน หลังจากรันงานฝึกอบรมทั้งหมดแล้วฉันจะประเมินตัวชี้วัดขั้นสุดท้ายและผสานให้เป็นสาขา / โมเดลที่ดีที่สุด