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

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

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

วิธีแก้ปัญหาที่ชัดเจนวิธีหนึ่งที่ฉันได้เห็นจะใช้ได้ผลหากคุณไม่มีข้อผูกมัดในท้องถิ่นfooและได้รับการปรับใหม่:

git fetch
git checkout foo
git reset --hard origin/foo

สิ่งนี้จะทิ้งสถานะท้องถิ่นที่fooสนับสนุนประวัติศาสตร์ของมันตามที่เก็บระยะไกล

แต่จะจัดการกับสถานการณ์ได้อย่างไรหากมีการเปลี่ยนแปลงในท้องถิ่นอย่างมากในสาขานั้น

การกลับมาซิงค์หลังจาก rebase แบบพุชนั้นไม่ได้ซับซ้อนขนาดนั้นในกรณีส่วนใหญ่

git checkout foo
git branch old-foo origin/foo # BEFORE fetching!!
git fetch
git rebase --onto origin/foo old-foo foo
git branch -D old-foo

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

การพูดซ้ำก็เหมือนความรุนแรงถ้ามันไม่ช่วยแก้ปัญหาของคุณคุณก็แค่ต้องการมันมากขึ้น ☺

คุณสามารถทำได้โดยไม่ต้องใช้บุ๊กมาร์กแน่นอนหากคุณค้นหาorigin/fooรหัสการคอมมิตpre-rebase และใช้สิ่งนั้น

นี่คือวิธีจัดการกับสถานการณ์ที่คุณลืมทำบุ๊กมาร์กก่อนดึงข้อมูล ไม่มีอะไรสูญหาย - คุณต้องตรวจสอบ reflog สำหรับสาขาระยะไกล:

git reflog show origin/foo | awk '
    PRINT_NEXT==1 { print $1; exit }
    /fetch: forced-update/ { PRINT_NEXT=1 }'

การดำเนินการนี้จะพิมพ์รหัสคอมมิตที่origin/fooชี้ไปก่อนการดึงข้อมูลล่าสุดที่เปลี่ยนประวัติ

จากนั้นคุณสามารถทำได้ง่ายๆ

git rebase --onto origin/foo $commit foo

ฉันจะบอกว่าการกู้คืนจากส่วนrebase ต้นน้ำของหน้าคน git-rebase ครอบคลุมทั้งหมดนี้

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

เริ่มต้นด้วย git 1.9 / 2.0 Q1 2014 คุณจะไม่ต้องทำเครื่องหมายที่มาของสาขาก่อนหน้าก่อนที่จะทำการรีฐานข้อมูลบนสาขาต้นน้ำที่เขียนใหม่ตามที่อธิบายไว้ในคำตอบของAristotle Pagaltzis : ดูที่กระทำ 07d406bและกระทำ d96855f :

หลังจากทำงานกับtopicสาขาที่สร้างขึ้นgit checkout -b topic origin/masterประวัติของสาขาการติดตามระยะไกลorigin/masterอาจได้รับการกรอกลับและสร้างขึ้นใหม่ซึ่งนำไปสู่ประวัติของรูปร่างนี้:

                   o---B1
                  /
  ---o---o---B2--o---o---o---B (origin/master)
          \
           B3
            \
             Derived (topic)

ที่origin/masterใช้ในการกระทำที่จุดB3, B2, B1และตอนนี้ก็ชี้ที่Bและคุณtopicสาขาเริ่มต้นด้านบนของมันกลับมาเมื่ออยู่ที่ origin/masterB3

โหมดนี้ใช้ reflog ของorigin/masterเพื่อค้นหาB3เป็นจุดแยกเพื่อให้topicสามารถ rebased ที่ด้านบนของการปรับปรุงorigin/masterโดย:

$ fork_point=$(git merge-base --fork-point origin/master topic)
$ git rebase --onto origin/master $fork_point topic

นั่นคือเหตุผลที่git merge-baseคำสั่งมีตัวเลือกใหม่:

--fork-point::

ค้นหาจุดที่สาขา (หรือมีประวัติใด ๆ ที่นำไปสู่การ<commit>) คดเคี้ยวจากสาขาอื่น (หรือการอ้างอิงใด ๆ<ref>)
สิ่งนี้ไม่เพียงแค่มองหาบรรพบุรุษร่วมของทั้งสองคนเท่านั้น แต่ยังคำนึงถึง reflog <ref>เพื่อดูว่าประวัติศาสตร์ที่นำไปสู่การ<commit>แยกจากชาติก่อนของสาขา<ref>หรือไม่

ว่า " git pull --rebaseคำสั่ง" คำนวณจุดแยกของสาขาที่ถูก rebased ใช้รายการ reflog ของ " baseสาขา" (โดยปกติจะเป็นสาขาที่ห่างไกลการติดตาม) การทำงานของสาขาอยู่บนพื้นฐานในการสั่งซื้อที่จะรับมือกับกรณีที่ "ฐาน" สาขาได้รับการกรอใหม่และสร้างใหม่

ตัวอย่างเช่นหากประวัติดูเหมือนที่ไหน:

• เคล็ดลับในปัจจุบันของ " baseสาขา" ที่Bแต่ก่อนหน้านี้ดึงข้อมูลข้อสังเกตว่าปลายที่เคยเป็นB3แล้วB2และจากนั้นB1 ก่อนที่จะเดินทางไปยังปัจจุบันกระทำและ
• สาขาที่ถูก rebased ด้านบนของ "ฐาน" ล่าสุดอยู่บนพื้นฐานการกระทำB3,

ก็พยายามที่จะหาB3โดยจะผ่านการส่งออกของ " git rev-list --reflog base" (คือB, B1, B2, B3) จนกว่าจะพบการกระทำที่เป็นบรรพบุรุษของปลายปัจจุบัน " Derived (topic)"

ภายในเรามีget_merge_bases_many()ที่สามารถคำนวณสิ่งนี้ได้ในครั้งเดียว
เราต้องการการผสานฐานระหว่างDerivedและการผสานรวมที่สมมติขึ้นซึ่งจะเกิดจากการรวมเคล็ดลับทางประวัติศาสตร์ทั้งหมดของ " base (origin/master)"
เมื่อมีการคอมมิตดังกล่าวเราควรได้ผลลัพธ์เดียวซึ่งตรงกับหนึ่งในรายการ reflog ของ " base"

Git 2.1 (Q3 2014) จะเพิ่มทำให้คุณลักษณะนี้มีประสิทธิภาพมากขึ้น: ดูการกระทำ 1e0dacdโดยJohn Keeping ( johnkeeping)

จัดการกับสถานการณ์ที่เรามีโทโพโลยีต่อไปนี้อย่างถูกต้อง:

    C --- D --- E  <- dev
   /
  B  <- master@{1}
 /
o --- B' --- C* --- D*  <- master

ที่ไหน:

• B'เป็นรุ่นที่ได้รับการแก้ไขแล้วของBที่ไม่ได้แพทช์เหมือนกันกับB;
• C*และD*เป็นแพทช์เหมือนกันCและDตามลำดับและขัดแย้งกันทางข้อความหากนำไปใช้ในลำดับที่ไม่ถูกต้อง
• Eขึ้นอยู่ textually Dบน

ผลที่ถูกต้องของการgit rebase master devเป็นสิ่งที่Bถูกระบุว่าเป็นส้อมจุดdevและmasterเพื่อให้C, D, Eเป็นกระทำที่จะต้องมีการย้อนสู่master; แต่CและDมีแพทช์เหมือนกันกับC*และD*และเพื่อให้สามารถปรับตัวลดลงเพื่อให้ผลลัพธ์ที่ได้คือ:

o --- B' --- C* --- D* --- E  <- dev

หากไม่ได้ระบุจุดส้อมการเลือกBไปยังสาขาที่มีB'ผลลัพธ์ในความขัดแย้งและหากระบุการกระทำที่เหมือนกันของแพทช์ไม่ถูกต้องการเลือกCไปยังสาขาที่มีD(หรือเทียบเท่าD*) จะทำให้เกิดความขัดแย้ง

ว่า " --fork-pointโหมด" ของ " git rebase" ถดถอยเมื่อคำสั่งที่ถูกเขียนใหม่ใน C ย้อนกลับไปในยุค 2.20 ซึ่งได้รับการแก้ไขด้วย Git 2.27 (Q2 2020)

ดูกระทำ f08132f (9 ธันวาคม 2019) โดยJunio C Hamano (gitster )
^{(ผสานโดยJunio ​​C Hamano - gitster-ในการกระทำ fb4175b , 27 มี.ค. 2020)}

rebase: --fork-pointการแก้ไขการถดถอย

^{ลงนามโดย: Alex Torok
[jc: ปรับปรุงการแก้ไขและใช้การทดสอบของ Alex]
ลงนามโดย: Junio ​​C Hamano}

" git rebase --fork-point master" เคยใช้งานได้ตามที่เรียกภายใน " git merge-base --fork-point" ซึ่งรู้วิธีจัดการ refname สั้น ๆ และย่อให้เป็น refname แบบเต็มก่อนที่จะเรียกget_fork_point()ฟังก์ชันพื้นฐาน

สิ่งนี้ไม่เป็นความจริงอีกต่อไปหลังจากที่เขียนคำสั่งใหม่ในภาษา C เนื่องจากการเรียกภายในที่โทรโดยตรงไปยังget_fork_point()ไม่ได้ลดการอ้างอิงสั้น ๆ

ย้ายอาร์กิวเมนต์ "dwim the refname ไปยัง refname แบบเต็ม" ที่ใช้ใน "git merge-base" ไปยังget_fork_point()ฟังก์ชันพื้นฐานเพื่อให้ผู้เรียกใช้ฟังก์ชันอื่นในการใช้ "git rebase" ทำงานในลักษณะเดียวกันในการแก้ไข การถดถอยนี้