คำขอดึง GitHub แสดงคอมมิตที่อยู่ในสาขาเป้าหมายแล้ว


137

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

ฉันได้ตรวจสอบคำขอดึงในเครื่องแล้วและแสดงเฉพาะการคอมมิตที่ไม่ได้ผสานเท่านั้น


สิ่งนี้มีผลต่อพฤติกรรมการรวม PR หรือไม่?
Nathan Hinchey

ไม่เพียงความแตกต่างของ Github
lobati

ไม่มีใครรู้ว่า Gitlab ที่โฮสต์เองมีพฤติกรรมเดียวกันหรือไม่?
Jeff Welling

2
ฉันขอแนะนำให้เราทุกคนติดต่อ GitHub เพื่อแสดงความสนใจในการเปลี่ยนแปลงพฤติกรรมนี้ ( support.github.com/contact ) หากพวกเขาไม่ได้รับการติดต่อจากเราพวกเขาจะไม่รู้ว่าสิ่งนี้สำคัญเพียงใดและจะเป็นเช่นนี้ตลอดไป
steinybot

คำตอบ:


107

ดูเหมือนว่า Pull Request จะไม่ติดตามการเปลี่ยนแปลงในสาขาเป้าหมาย (ฉันติดต่อฝ่ายสนับสนุนของ GitHub และได้รับคำตอบเมื่อวันที่ 18 พ.ย. 2014 โดยระบุว่าเป็นการออกแบบ)

อย่างไรก็ตามคุณสามารถใช้เพื่อแสดงการเปลี่ยนแปลงที่อัปเดตโดยทำดังต่อไปนี้:

http://githuburl/org/repo/compare/targetbranch...currentbranch

แทนที่githuburl, org, repo, targetbranchและcurrentbranchตามความจำเป็น

หรือตามที่ hexsprite ระบุไว้ในคำตอบของเขาคุณยังสามารถบังคับให้อัปเดตได้โดยคลิกEditที่ PR และเปลี่ยนฐานชั่วคราวไปยังสาขาอื่นแล้วกลับมาอีกครั้ง สิ่งนี้ก่อให้เกิดคำเตือน:

แน่ใจไหมว่าต้องการเปลี่ยนฐาน

การคอมมิตบางอย่างจากสาขาฐานเดิมอาจถูกลบออกจากไทม์ไลน์และความคิดเห็นรีวิวเก่าอาจล้าสมัย

และจะทิ้งรายการบันทึกสองรายการไว้ใน PR:

ป้อนคำอธิบายภาพที่นี่


4
ใช่ฉันติดต่อฝ่ายสนับสนุนมาระยะหนึ่งแล้วและได้รับคำตอบแบบเดียวกัน พวกเขาไม่ได้ปรับให้เหมาะสมกับสถานการณ์นี้ มันเป็นบิตที่น่าผิดหวัง วิธีการของเราในการหลีกเลี่ยงมันคือการสร้างฐานใหม่และบังคับให้ดันขึ้นหรือปิดการดึงและสร้างใหม่
lobati

4
คำตอบนี้ไม่ได้ช่วยแก้ปัญหา แต่ช่วยให้ผู้ใช้เห็นความแตกต่างที่แท้จริง
FearlessFuture

4
คำถามคือ "เหตุใดจึงยังคงปรากฏในคำขอดึง" มันตอบคำถามนั้น
Adam Millerchip

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

11
มีคำขอgithub ที่ต้องการเปลี่ยนแปลงสิ่งนี้หรือไม่?
vossad01

90

นี่เป็นวิธีแก้ปัญหาที่ดี ใช้Editปุ่มเมื่อดูการประชาสัมพันธ์ใน GitHub masterจะเปลี่ยนสาขาฐานเพื่อสิ่งอื่นที่ไม่ใช่ จากนั้นเปลี่ยนกลับเป็นmasterและตอนนี้จะแสดงเฉพาะการเปลี่ยนแปลงจากการกระทำล่าสุดอย่างถูกต้อง


4
ฉันแปลกใจที่หลายคนไม่ยอมรับวิธีแก้ปัญหานี้ ฉันสงสัยว่าคำขอดึงข้อมูลที่ล้าสมัยเดิมจะใช้ได้ดี แต่ฉันไม่ชอบให้ GitHub แสดงไฟล์ที่ล้าสมัยทั้งหมดดังนั้นฉันจึงใช้สิ่งนี้และทั้งสองจะเก็บคำอธิบายไว้และแสดงเฉพาะการเปลี่ยนแปลงที่แท้จริงที่จะรวมเข้าด้วยกัน . ขอบคุณ!
taranaki

2
ไม่ได้ผลสำหรับฉัน
Shashank

ไอ้งานนี้!
Anurag Hazra

สามปีต่อมาและนี่ยังคงเป็นทางออกที่ยอดเยี่ยม และดูมีคนแสดงความคิดเห็นเมื่อไม่กี่ชั่วโมงก่อนด้วย ^^^
Ricardo Saporta

33

เพื่อสรุป GitHub จะไม่สร้างประวัติคอมมิตใหม่โดยอัตโนมัติในคำขอดึง วิธีแก้ปัญหาที่ง่ายที่สุดคือ:

โซลูชันที่ 1: Rebase

สมมติว่าคุณต้องการรวมเข้าmasterจากfeature-01:

git fetch origin
git checkout feature-01
git rebase origin/master
git push --force

ถ้าคุณกำลังทำงานบนส้อมแล้วคุณอาจจำเป็นต้องเปลี่ยนข้างต้นด้วยorigin upstreamดูฉันจะอัพเดตที่เก็บ GitHub forked ได้อย่างไร เพื่อเรียนรู้เพิ่มเติมเกี่ยวกับการติดตามสาขาระยะไกลของที่เก็บดั้งเดิม

โซลูชันที่ 2: สร้างคำขอดึงใหม่

สมมติว่าคุณต้องการรวมบทนำmasterจากfeature-01:

git checkout feature-01
git checkout -b feature-01-rebased
git push -u origin feature-01-rebased

ตอนนี้เปิดคำขอดึงสำหรับและปิดหนึ่งสำหรับfeature-01-rebasedfeature-01


4
rebase เปลี่ยนแฮชคอมมิตดังนั้นมันจะจบลงด้วยการทิ้งความคิดเห็นรีวิวที่มีอยู่หรือไม่
haridsv

@haridsv น่าจะใช่
Mateusz Piotrowski

สิ่งที่ต้องระวังเมื่อทำการผลัก - บังคับ?
Paul Bendevis

1
@haridsv นั่นไม่ใช่ประสบการณ์ของฉัน ฉันมักจะทำการทบทวนกลางคันบ่อยครั้งและความคิดเห็นจะไม่สูญหายไป แม้ว่าฉันจะสูญเสียประวัติการเปลี่ยนแปลงใน PR
joel

@JoelBerkeley จริง ๆ แล้วฉันได้พบกับบทวิจารณ์สองสามรายการในขณะที่ผู้เขียนปฏิเสธและสังเกตว่าความคิดเห็นนั้นอยู่ในชั้นเชิง อย่างไรก็ตามเราสูญเสียความสามารถในการตรวจสอบทีละน้อยและสำหรับบทวิจารณ์จำนวนมากผู้ตรวจสอบจะได้รับโทษอย่างมาก ตอนนี้เรามีหลักเกณฑ์บางประการสำหรับการประชาสัมพันธ์ของเราและหนึ่งในนั้นจะไม่ต้องตั้งฐานใหม่อีกครั้งหลังจากที่เปิดการตรวจสอบแล้ว (เว้นแต่จะแน่ใจว่ายังไม่มีใครเริ่มตรวจสอบ) การผสานเป็นสิ่งที่ดี แต่แนวทางของเราคือห้ามผสมการเปลี่ยนแปลงการผสานกับการเปลี่ยนแปลงอื่น ๆ นอกเหนือจากการแก้ไขข้อขัดแย้ง
haridsv

17

คุณต้องเพิ่มสิ่งต่อไปนี้ใน~/.gitconfigไฟล์ของคุณ:

[rebase]
    autosquash = true

สิ่งนี้จะบรรลุโดยอัตโนมัติเช่นเดียวกับที่คำตอบนี้แสดง

ผมได้รับนี้จากที่นี่


2
ฉันคลิกโหวตลงโดยบังเอิญ คำตอบนี้ช่วยฉัน ขอฉันเปลี่ยนได้ไหม
Hector

@hosein ไปเลย คุณควรจะทำได้แล้ว
Mateusz Piotrowski

1
ฉันคิดว่านี่ควรเป็นคำตอบที่ยอมรับหรือรวมอยู่ในคำตอบที่ยอมรับ สิ่งนี้บรรลุผลลัพธ์ที่ฉันต้องการ!
Ronald Rey

1
@RonaldRey rebasing git ไม่ใช่วิธีแก้ปัญหาสากลเพราะเกี่ยวข้องกับการแก้ไขประวัติ หากทุกคนกำลังทำงานกับส้อมส่วนตัวที่คนอื่นไม่เคยโคลนมาก่อนก็ใช้ได้ แต่ทันทีที่มีคนโคลนที่เก็บของคุณและคุณแก้ไขประวัติคุณจะได้รับประวัติศาสตร์ที่แตกต่างกัน
Adam Millerchip

14

สำหรับใครก็ตามที่เจอปัญหานี้และสับสนกับพฤติกรรม GitHub Pull Request สาเหตุที่แท้จริงคือ PR เป็นความแตกต่างของปลายสาขาต้นทางเทียบกับบรรพบุรุษทั่วไปของสาขาต้นทางและสาขาเป้าหมาย ดังนั้นจึงจะแสดงการเปลี่ยนแปลงทั้งหมดในสาขาต้นทางจนถึงบรรพบุรุษร่วมกันและจะไม่คำนึงถึงการเปลี่ยนแปลงใด ๆ ที่อาจเกิดขึ้นกับสาขาเป้าหมาย

ดูข้อมูลเพิ่มเติมได้ที่นี่: https://developer.atlassian.com/blog/2015/01/a-better-pull-request/

ความแตกต่างตามบรรพบุรุษทั่วไปดูเหมือนอันตราย ฉันหวังว่า GitHub จะมีตัวเลือกในการสร้าง PR แบบผสาน 3 ทางที่เป็นมาตรฐานมากขึ้น


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

2
พฤติกรรมนี้ดูเหมือนจะเกิดขึ้นเมื่อทำการ rebase แทนการผสาน
G.One

1
@ G.One ตอบช้าจริง ๆ แต่ใช่ - ถ้าคุณรวมจากสาขาหลักนั้นไปยังสาขาต้นทางของคุณคุณจะอัปเดตบรรพบุรุษร่วมกันตามนิยาม เป็นการกระทำต่อต้นแบบที่คุณรวมเข้าด้วยกัน
David K. Hess

13

วิธีหนึ่งในการแก้ไขปัญหานี้คือgit rebase targetbranchในการประชาสัมพันธ์นั้น จากgit push --force targetbranchนั้น Github จะแสดงการคอมมิตและความแตกต่างที่ถูกต้อง โปรดใช้ความระมัดระวังหากคุณไม่รู้ว่ากำลังทำอะไรอยู่ อาจจะเช็คเอาต์สาขาทดสอบก่อนเพื่อทำการรีเบสจากนั้นgit diff targetbranchเพื่อให้แน่ใจว่ายังคงเป็นสิ่งที่คุณต้องการ


10

สิ่งนี้เกิดขึ้นกับ GitHub เมื่อคุณทำสควอชรวมเข้าด้วยกันจากสาขาเป้าหมาย

ฉันใช้สควอชและผสานกับ Github เป็นกลยุทธ์การผสานเริ่มต้นรวมถึงการผสานจากสาขาเป้าหมาย สิ่งนี้เป็นการแนะนำคอมมิตใหม่และ GitHub ไม่ทราบว่าคอมมิตที่บีบอัดนี้เหมือนกับคอมมิตที่มีอยู่แล้ว (แต่มีแฮชต่างกัน) Git จัดการอย่างถูกต้อง แต่คุณเห็นการเปลี่ยนแปลงทั้งหมดอีกครั้งใน GitHub ทำให้การตรวจสอบน่ารำคาญ วิธีแก้ปัญหาคือทำการผสานอย่างสม่ำเสมอของสิ่งเหล่านี้ที่ดึงเข้ามาในต้นน้ำแทนที่จะเป็นสควอชและผสาน เมื่อคุณต้องการรวมในสาขาอื่นเป็นของคุณเป็นการพึ่งพาgit merge --squashและเปลี่ยนกลับคอมมิตเดียวนั้นก่อนที่จะดึงจากมาสเตอร์เมื่อสาขาอื่นได้ทำให้มันเชี่ยวชาญแล้ว

แก้ไข: อีกวิธีหนึ่งคือการสร้างฐานใหม่และบังคับให้ผลักดัน ประวัติที่สะอาด แต่เขียนใหม่


1
ขอบคุณ @achille นี่เป็นปัญหาของฉันจริงๆ หลังจากปิดใช้งานการผสานสควอชจะได้รับการแก้ไข
Ashvin777

0

ฉันไม่แน่ใจเกี่ยวกับทฤษฎีที่อยู่เบื้องหลังสิ่งนี้ แต่ฉันได้รับหลายครั้งและสามารถแก้ไขได้โดยทำสิ่งต่อไปนี้

git pull --rebase

สิ่งนี้จะดึงและรวมการเปลี่ยนแปลงจากสาขาต้นแบบ repo เดิมของคุณ (หากคุณมีจุดนั้น)

จากนั้นคุณผลักดันการเปลี่ยนแปลงของคุณอย่างแรงไปยังที่เก็บ github ที่โคลน (เป้าหมาย)

git push -f origin master

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



-1

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

git add .  && git commit -a --allow-empty-message -m '' && git reset --soft HEAD~2 &&
git commit --edit -m"$(git log --format=%B --reverse HEAD..HEAD@{1})"

ฉันไม่มีความขัดแย้งคุณพร้อมที่จะไป!

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.