คอมไพล์ผสานหลังจากเชอร์รี่เลือกทำงานอย่างไร

ลองจินตนาการว่าเรามีmasterสาขา

จากนั้นเราสร้าง newbranch

git checkout -b newbranch

และสร้างใหม่สองคอมมิตถึงnewbranch: commit1และcommit2

จากนั้นเราเปลี่ยนเป็นต้นแบบและทำ cherry-pick

git checkout master
git cherry-pick hash_of_commit1

เมื่อมองgitkดูเราจะเห็นว่าcommit1และเวอร์ชั่นที่เลือกโดยเชอร์รี่นั้นมีแฮชที่แตกต่างกันดังนั้นในทางเทคนิคแล้วพวกมันต่างกันสองคอมมิชชัน

ในที่สุดเราก็รวมnewbranchเป็นmaster:

git merge newbranch

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

Git ทำการวิเคราะห์เนื้อหาของคอมมิชชันอย่างชาญฉลาดในขณะที่ผสานและตัดสินใจว่าไม่ควรใช้การเปลี่ยนแปลงสองครั้งหรือคอมมิชชันเหล่านี้มีการทำเครื่องหมายภายในเป็นการเชื่อมโยงเข้าด้วยกัน?

คำตอบสั้น ๆ

ไม่ต้องกังวล Git จะจัดการกับมัน

คำตอบที่ยาว

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

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

แหล่งที่มา

¹ Skip-Deltas ในการโค่นล้ม
² พื้นฐาน Git
³ โมเดลวัตถุ Git

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

วิธีการป้องกันไม่ให้ฉันอ้างจากบทความที่แนะนำสำหรับสาขาที่มีการซ้ำซ้อน (คัดสรรโดยเชอร์รี่) ให้ใช้ rebase ก่อนทำการผสาน:

คอมไพล์ผสานหลังจากคอมไพล์เชอร์รี่เลือก: หลีกเลี่ยงการกระทำที่ซ้ำกัน

ลองนึกภาพเรามีสาขาหลักและสาขา b:

   o---X   <-- master
    \
     b1---b2---b3---b4   <-- b

ตอนนี้เราต้องการความมุ่งมั่นอย่างเร่งด่วนในระดับ b1 และ b3 ในระดับปริญญาโท แต่ไม่ใช่ส่วนที่เหลือในรูปแบบ b ดังนั้นสิ่งที่เราทำคือเช็คเอาท์สาขาหลักและเลือกเชอร์รี่กระทำ b1 และ b3:

$ git checkout master
$ git cherry-pick "b1's SHA"
$ git cherry-pick "b3's SHA"

ผลลัพธ์จะเป็น:

   o---X---b1'---b3'   <-- master
    \
     b1---b2---b3---b4   <-- b

สมมติว่าเราทำอย่างอื่นกับอาจารย์แล้วเราจะได้:

   o---X---b1'---b3'---Y   <-- master
    \
     b1---b2---b3---b4   <-- b

ถ้าตอนนี้เราจะรวมสาขา b เป็นหลัก:

$ git merge b

เราจะได้รับดังต่อไปนี้:

   o---X---b1'---b3'---Y--- M  <-- master
     \                     /
      b1----b2----b3----b4   <-- b

นั่นหมายถึงการเปลี่ยนแปลงที่เกิดขึ้นโดย b1 และ b3 จะปรากฏขึ้นสองครั้งในประวัติศาสตร์ เพื่อหลีกเลี่ยงการที่เราสามารถรีบูตแทนการรวม:

$ git rebase master b

ซึ่งจะให้:

   o---X---b1'---b3'---Y   <-- master
                        \
                         b2'---b4'   <-- b

สุดท้าย:

$ git checkout master
$ git merge b

ให้เรา:

   o---X---b1'---b3'---Y---b2'---b4'   <-- master, b

แก้ไข โดยความเห็นของเดวิดเลม่อน