มันผิดไหมถ้าคอมไพล์แรงผลักดันกิ่งไม้?

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

ในระหว่างการพัฒนาคุณลักษณะฉันต้องการผลักดันงานกลางของฉันไปยังที่เก็บข้อมูลระยะไกลเพื่อเป็นการสำรองข้อมูล เช่นเมื่อฮาร์ดไดรฟ์ล่มฉันไม่ต้องการให้ฟีเจอร์สาขาของฉันหาย

อย่างไรก็ตามสิ่งนี้นำไปสู่ความจริงที่ว่าฉันมักจะต้องทำgit push --forceกับที่เก็บระยะไกลหลังจาก rebase การกระทำที่ขมวดคิ้วโดยทั่วไป หรือเป็นหน้า GitHub ที่เชื่อมโยงพูดว่า:

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

มีนโยบาย (ที่ยอมรับกันโดยทั่วไป) ที่แก้ไขข้อขัดแย้งนี้หรือไม่?

ทำไมสิ่งนี้จึงไม่ซ้ำซ้อนกับ git "Golden Rule of Rebasing" จำเป็นหรือไม่

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

git

— Chiel ten Brinke
แหล่งที่มา

สำเนาที่เป็นไปได้ของgit "Golden Rule of Rebasing" จำเป็นหรือไม่

— gbjbaanb

@gbjbaanb หากคุณใช้งาน WIP การ rebase นั้นมีประโยชน์มากในการหลีกเลี่ยงการทำงานหลายครั้งในหนึ่งวัน ฉันมักจะกระทำเพื่อการเปลี่ยนแปลงเล็กน้อยดังนั้นฉันจึงมีตัวเลือก "ยกเลิกสถานะที่จำได้" ถ้าจำเป็น - สิ่งเหล่านี้ส่วนใหญ่ไม่เกี่ยวข้อง / เสียงรบกวนในประวัติศาสตร์หลักของ repo

— enderland

@gbjbaanb นั่นเป็นเรื่องของความเห็นฉันคิดว่า หลายทีมใช้กลยุทธ์การรีบูตเพื่อรักษาความสะอาดของประวัติ

— Chiel ten Brinke

@enderland ทุกคนต้องการประวัติที่ดีมันยังคงเป็นสิ่งที่ผิด (และอันตราย) ที่ต้องทำตามลิงค์ Torvalds ไม่ควรใส่เข้าไปเขาควรอนุญาตให้คอมมิท "บีบอัด" บนหน้าจอแทน

— gbjbaanb

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

— enderland

คำตอบ:

คำถามสำคัญที่ถามตัวเอง:

คุณรักษาสาขาระยะไกลของคุณหลังจากรวมกลับเข้าที่หลักหรือไม่?

หากคุณลบสาขาฟีเจอร์รีโมตหลังจากรวมกันเป็นมาสเตอร์แสดงว่าคุณสูญเสียประวัติไปแล้ว สมมติว่าคุณสควอช / rebase สาขาก่อนที่จะทำให้การผสาน / PR ของคุณคุณสูญเสียประวัติศาสตร์นี้ แรงผลักดันทั้งหมดของคุณกำลังทำในกรณีนี้จะช่วยให้คุณใช้ GitHub เป็นตัวสำรอง

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

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

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

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

— enderland
แหล่งที่มา

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

— Chiel ten Brinke

@ChieltenBrinke ฉันแก้ไขไปเล็กน้อย FYI

— enderland

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

— Chiel ten Brinke

@ChieltenBrinke ดีคุณสามารถบรรลุสิ่งเดียวกันในหลากหลายวิธี หากสาขาฟีเจอร์ของคุณอยู่ในที่เก็บระยะไกลคุณสามารถแยก repo และมีเวอร์ชันของสาขานั้น แล้วรวมสาขานั้นเข้ากับสาขาระยะไกลของคุณหลังจากการคอมมิชชัน หรือคุณสามารถสร้างสาขาในพื้นที่ที่แตกต่างกัน (อาจfeaturebranch-local) จากนั้นทำการเปิดใช้งาน dev บนสาขานั้นโดยมีการผูกมัดตามที่คุณต้องการ เมื่อคุณต้องการผสานแล้วให้สควอชเหล่านั้นรวมเข้ากับคุณสมบัติ โดยทั่วไปเพียงแค่ทำการพัฒนาในสาขาชั่วคราวจริง ๆ แล้วทำการบีบอัด / รวมเข้าไปในฟีเจอร์ของคุณ

— enderland

สมมติว่าการเลิกซื้อ repo นั้นไม่มีทางเลือกเพราะไม่มี Github เราจึงจะทำงานกับdevelop-featureสาขา"ส่วนตัว" แน่นอนว่าความเป็นส่วนตัวนั้นเกิดจากการประชุมล้วน ๆ และไม่ได้บังคับอะไรเลย แต่สามารถทำให้เป็นส่วนหนึ่งของนโยบายโดยเฉพาะอย่างยิ่งหากมีการแนะนำการตั้งชื่อสาขาบางสาขา (บางทีฉันอาจเป็นกังวลเกินไปตอนนี้อาจไม่ใช่ :) การรวมกันกับ--force-with-leaseไม่สามารถทำร้ายแม้ว่าไม่ควรพึ่งตามที่ระบุไว้ในโพสต์อื่นของฉัน

— Chiel ten Brinke

ฉันแสดงความเป็นไปได้บางอย่างที่นี่

ทำการรีบูทกับสาขาใหม่เสมอ

เมื่อมีสาขาที่ยุ่งsome-featureให้รีบูทบนสาขาใหม่ เช่น

$ git checkout -b some-feature-rebase
$ git rebase -i master # etc..

จากนั้นได้some-feature-rebaseตรวจสอบและบูรณาการ

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

ใช้ `git push --force-with-lease`

ฉันเพิ่งเรียนรู้เกี่ยวกับgit push --force-with-leaseทางเลือกgit push --forceซึ่ง

ปฏิเสธที่จะอัปเดตสาขาเว้นแต่จะเป็นสถานะที่เราคาดไว้ คือไม่มีใครอัปเดตสาขาต้นน้ำ

ปัญหา : สิ่งนี้ดูเหมือนว่าจะปรับปรุงโดยตรงกับสถานการณ์ที่เราใช้เพียง--forceแต่ยังมีข้อแม้บางอย่างที่สะดุดตาที่สุดเมื่อฉันทำgit fetchแทน a git pullซึ่งอัปเดตสาขาอัปสตรีมท้องถิ่นของเราหลอกให้--force-with-leaseคิดว่าไม่มีการเปลี่ยนแปลงที่ไม่ได้ทำบนรีโมท สาขา.

— Chiel ten Brinke
แหล่งที่มา

มันผิดไหมถ้าคอมไพล์แรงผลักดันกิ่งไม้?

ทำไมสิ่งนี้จึงไม่ซ้ำซ้อนกับ git "Golden Rule of Rebasing" จำเป็นหรือไม่

ทำการรีบูทกับสาขาใหม่เสมอ

ใช้ git push --force-with-lease

ใช้ `git push --force-with-lease`