Git push ถูกปฏิเสธหลังจากการรีบูทของฟีเจอร์

ตกลงฉันคิดว่านี่เป็นสถานการณ์คอมไพล์อย่างง่ายฉันจะพลาดอะไรไป

ฉันมีmasterสาขาและfeatureสาขา ฉันทำงานบางอย่างทำงานmasterบ้างfeatureแล้วก็ทำงานต่อmasterไป ฉันท้ายด้วยบางสิ่งเช่นนี้ (คำสั่งทำพจนานุกรมหมายถึงคำสั่งของการกระทำ):

A--B--C------F--G  (master)
       \    
        D--E  (feature)

ฉันไม่มีปัญหาในgit push origin masterการmasterอัปเดตรีโมตและไม่มีgit push origin feature(เมื่อเปิดfeature) เพื่อรักษาการสำรองข้อมูลระยะไกลสำหรับfeatureงานของฉัน จนถึงตอนนี้เราก็ยังดี

แต่ตอนนี้ผมอยากจะ rebase featureที่ด้านบนของF--Gกระทำบนต้นแบบดังนั้นฉันและgit checkout feature git rebase masterยังคงดีอยู่. ตอนนี้เรามี:

A--B--C------F--G  (master)
                 \
                  D'--E'  (feature)

ปัญหา:ทันทีที่ฉันต้องการสำรองfeatureกิ่งที่ถูกรีบาวด์ใหม่git push origin feature, การกดจะถูกปฏิเสธเนื่องจากต้นไม้มีการเปลี่ยนแปลงเนื่องจากการรีบูท git push --force origin featureนี้สามารถแก้ไขได้เฉพาะกับ

ฉันเกลียดการใช้--forceโดยไม่แน่ใจว่าฉันต้องการมัน ดังนั้นฉันต้องการมันหรือไม่? การรีบูตจำเป็นต้องบอกเป็นนัยว่าสิ่งต่อไปpushควรเป็นจริง--forceหรือไม่?

สาขาคุณลักษณะนี้ไม่ได้ใช้ร่วมกันกับ devs อื่น ๆ ดังนั้นผมจึงไม่มีปัญหาพฤตินัยด้วยการกดบังคับฉันจะไม่สูญเสียข้อมูลใด ๆ คำถามคือแนวความคิดอื่น ๆ อีกมากมาย

ปัญหาคือgit pushสมมติว่าสาขาระยะไกลสามารถส่งต่ออย่างรวดเร็วไปยังสาขาในพื้นที่ของคุณนั่นคือความแตกต่างทั้งหมดระหว่างสาขาในพื้นที่และสาขาที่อยู่ห่างไกลอยู่ในพื้นที่ที่มีความมุ่งมั่นใหม่ ๆ ในตอนท้ายดังนี้

Z--X--R         <- origin/some-branch (can be fast-forwarded to Y commit)
       \        
        T--Y    <- some-branch

เมื่อคุณทำคอมมิชชันgit rebaseD และ E จะใช้กับฐานใหม่และคอมมิชชันใหม่จะถูกสร้างขึ้น นั่นหมายความว่าหลังจากการรีบูทคุณมีสิ่งที่ต้องการ:

A--B--C------F--G--D'--E'   <- feature-branch
       \  
        D--E                <- origin/feature-branch

ในสถานการณ์นั้นไม่สามารถส่งต่อไปยังสาขาระยะไกลในพื้นที่ได้อย่างรวดเร็ว แม้ว่าสาขาในท้องถิ่นตามหลักวิชาสามารถรวมเข้ากับรีโมท (เห็นได้ชัดว่าคุณไม่จำเป็นต้องใช้ในกรณีนี้) แต่เมื่อgit pushทำการผสานการกรอไปข้างหน้าอย่างรวดเร็วมันจะพ่นและเกิดข้อผิดพลาด

และสิ่งที่--forceตัวเลือกทำก็เพียงแค่เพิกเฉยต่อสถานะของสาขาระยะไกลและตั้งค่าเป็นความมุ่งมั่นที่คุณกำลังผลักดันเข้าไป ดังนั้นgit push --force origin feature-branchเพียงแค่แทนที่ท้องถิ่นorigin/feature-branchfeature-branch

ในความคิดของฉันการรีบูตคุณลักษณะของสาขาmasterและการบังคับให้พวกเขากลับไปที่พื้นที่เก็บข้อมูลระยะไกลนั้นก็โอเคตราบใดที่คุณเป็นคนเดียวที่ทำงานในสาขานั้น

แทนที่จะใช้ -f หรือ --force นักพัฒนาควรใช้

--force-with-lease

ทำไม? เพราะมันตรวจสอบสาขาระยะไกลสำหรับการเปลี่ยนแปลงซึ่งเป็นความคิดที่ดีอย่างแน่นอน ลองนึกภาพว่าเจมส์กับลิซ่ากำลังทำงานในสาขาฟีเจอร์เดียวกันและลิซ่าก็ได้แสดงความมุ่งมั่น ตอนนี้เจมส์ rebases สาขาท้องถิ่นของเขาและถูกปฏิเสธเมื่อพยายามที่จะผลักดัน แน่นอนว่าเจมส์คิดว่านี่เป็นเพราะการลดและใช้ - บังคับและจะเขียนการเปลี่ยนแปลงทั้งหมดของลิซ่า ถ้าเจมส์ใช้ --force-with-lease เขาจะได้รับคำเตือนว่ามีคนอื่นกระทำ ฉันไม่เห็นว่าทำไมทุกคนจะใช้ --force แทน --force-with-lease เมื่อกดหลังจากรีบูต

ฉันจะใช้แทน "checkout -b" และง่ายต่อการเข้าใจ

git checkout myFeature
git rebase master
git push origin --delete myFeature
git push origin myFeature

เมื่อคุณลบคุณจะป้องกันไม่ให้ดันออกจากสาขาที่มีรหัส SHA อื่น ฉันกำลังลบเฉพาะสาขาระยะไกลในกรณีนี้

ทางออกหนึ่งในการนี้คือการทำในสิ่งที่ msysgit ของการผสาน rebasingสคริปต์ไม่ - หลังจาก rebase ที่ผสานในหัวเก่าด้วยfeature -s oursคุณจบลงด้วยกราฟการกระทำ:

A--B--C------F--G (master)
       \         \
        \         D'--E' (feature)
         \           /
          \       --
           \    /
            D--E (old-feature)

... และความfeatureมุ่งมั่นของคุณจะเป็นไปอย่างรวดเร็ว

กล่าวอีกนัยหนึ่งคุณสามารถทำได้:

git checkout feature
git branch old-feature
git rebase master
git merge -s ours old-feature
git push origin feature

(ไม่ได้ทดสอบ แต่ฉันคิดว่ามันถูกต้อง ... )

มันอาจจะใช่หรือไม่ใช่ในกรณีที่มีนักพัฒนาเพียงคนเดียวในสาขานี้นั่นคือตอนนี้ (หลังจากการ rebase) ไม่สอดคล้องกับที่มา / คุณสมบัติ

ดังนั้นฉันขอแนะนำให้ใช้ลำดับต่อไปนี้:

git rebase master
git checkout -b feature_branch_2
git push origin feature_branch_2

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

วิธีหลีกเลี่ยงการใช้แรงผลักดันของฉันคือการสร้างสาขาใหม่และทำงานอย่างต่อเนื่องในสาขาใหม่นั้นและหลังจากที่มีความมั่นคงแล้วให้ลบสาขาเก่าที่ถูกปฏิเสธ:

• รีสาขาที่เช็คเอาต์ในเครื่อง
• การแตกแขนงจากกิ่งที่ถูกปฏิเสธไปยังสาขาใหม่
• ผลักสาขานั้นเป็นสาขาใหม่ไปยังระยะไกล และลบสาขาเก่าบนรีโมท

อื่น ๆ ได้ตอบคำถามของคุณ หากคุณรีบูทสาขาคุณจะต้องบังคับให้ดันสาขานั้น

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

โดยทั่วไป rebase จะทำงานได้ดีสำหรับการจัดการสาขาในท้องถิ่น การจัดการสาขาระยะไกลทำงานได้ดีที่สุดกับการรวมที่ชัดเจน (--no-ff)

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

ผิดปกติกับคืออะไรgit merge masterในfeatureสาขา? สิ่งนี้จะรักษางานที่คุณมีในขณะที่แยกออกจากสาขาการฉีด

A--B--C------F--G
       \         \
        D--E------H

แก้ไข:อ่าขอโทษที่ไม่ได้อ่านคำชี้แจงปัญหาของคุณ rebaseคุณจะต้องมีผลบังคับใช้ในขณะที่คุณดำเนินการ คำสั่งทั้งหมดที่แก้ไขประวัติจะต้องมี--forceอาร์กิวเมนต์ นี่คือความล้มเหลวที่จะป้องกันไม่ให้คุณสูญเสียงาน (เก่าDและEจะหายไป)

ดังนั้นคุณจึงทำสิ่งgit rebaseที่ทำให้ต้นไม้ดูเหมือน (แม้ว่าซ่อนอยู่บางส่วนDและEไม่อยู่ในสาขาที่มีชื่อ):

A--B--C------F--G
       \         \
        D--E      D'--E'

ดังนั้นเมื่อพยายามที่จะผลักดันใหม่featureสาขา (ที่มีD'และE'ในนั้น) คุณจะสูญเสียและDE

สำหรับฉันทำตามขั้นตอนง่าย ๆ ใช้งานได้:

1. git checkout myFeature
2. git rebase master
3. git push --force-with-lease
4. git branch -f master HEAD
5. git checkout master
6. git pull

หลังจากทำทั้งหมดข้างต้นเราสามารถลบ myFeature branch ได้ด้วยคำสั่งดังต่อไปนี้:

git push origin --delete myFeature

งานต่อไปนี้สำหรับฉัน:

git push -f origin branch_name

และจะไม่ลบรหัสใด ๆ ของฉัน

แต่ถ้าคุณต้องการหลีกเลี่ยงปัญหานี้คุณสามารถทำสิ่งต่อไปนี้:

git checkout master
git pull --rebase
git checkout -b new_branch_name

จากนั้นคุณสามารถเลือกเชอร์รี่ทั้งหมดที่คุณให้ไว้กับสาขาใหม่ git cherry-pick COMMIT ID แล้วดันสาขาใหม่ของคุณ

เนื่องจาก OP เข้าใจปัญหาเพียงมองหาโซลูชันที่ดีกว่า ...

วิธีนี้เกี่ยวกับการปฏิบัติเป็นอย่างไร

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

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

อาจมีชื่อรูปแบบสำหรับวิธีนี้แล้ว