Permintaan tarik GitHub menunjukkan komitmen yang sudah ada di cabang target


136

Saya mencoba meninjau permintaan tarik pada GitHub ke cabang yang bukan master. Cabang target berada di belakang master dan permintaan tarikan menunjukkan komit dari master, jadi saya menggabungkan master dan mendorongnya ke GitHub, tetapi komit dan diff untuk mereka masih muncul dalam permintaan tarikan setelah menyegarkan. Saya telah menggandakan memeriksa bahwa cabang di GitHub memiliki komit dari master. Mengapa mereka masih muncul dalam permintaan tarik?

Saya juga telah memeriksa permintaan tarik secara lokal dan itu hanya menunjukkan komitmen yang tidak digabungkan.


Apakah ini memengaruhi perilaku menggabungkan PR?
Nathan Hinchey

Tidak, hanya perbedaan pada Github.
lobati

Adakah yang tahu kalau Gitlab yang di-host-sendiri menderita perilaku yang sama?
Jeff Welling

2
Saya menyarankan agar kita semua menghubungi GitHub untuk menyatakan minat kami untuk mengubah perilaku ini ( support.github.com/contact ). Jika mereka tidak mendengar dari kami maka mereka tidak akan tahu betapa pentingnya hal ini dan akan seperti ini selamanya.
steinybot

Jawaban:


107

Sepertinya Permintaan Tarik tidak melacak perubahan ke cabang target (saya menghubungi dukungan GitHub, dan menerima respons pada 18 November 2014 yang menyatakan ini sesuai desain).

Namun, Anda bisa menampilkan perubahan yang diperbarui dengan melakukan hal berikut:

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

Ganti githuburl, org, repo, targetbranch, dan currentbranchsesuai kebutuhan.

Atau seperti yang ditunjukkan hexsprite dalam jawabannya, Anda juga dapat memaksanya untuk memperbarui dengan mengklik EditPR dan untuk sementara mengubah basis menjadi cabang yang berbeda dan kembali lagi. Ini menghasilkan peringatan:

Anda yakin ingin mengubah basis?

Beberapa komitmen dari cabang dasar yang lama dapat dihapus dari timeline, dan komentar ulasan yang lama mungkin menjadi usang.

Dan akan meninggalkan dua entri log di PR:

masukkan deskripsi gambar di sini


4
Ya, saya menghubungi dukungan beberapa waktu lalu dan mendapat respons yang sama. Mereka tidak mengoptimalkan untuk situasi ini. Agak frustasi. Cara kami menyiasatinya adalah dengan rebase dan memaksa push up, atau untuk menutup tarikan dan membuat yang baru.
lobati

4
Jawaban ini tidak memperbaiki masalah, tetapi hanya memungkinkan pengguna untuk melihat perbedaan yang sebenarnya.
FearlessFuture

4
Pertanyaannya adalah "Mengapa mereka masih muncul dalam permintaan tarik?". Itu menjawab pertanyaan itu.
Adam Millerchip

3
Lihatlah komentar saya untuk solusi yang baik. Anda cukup menggunakan tombol edit PR untuk beralih ke cabang lain dan kemudian kembali ke cabang basis asli dan itu akan menghitung ulang diff.
hexsprite

11
Apakah ada permintaan sayang-github untuk mengubahnya?
vossad01

87

Ini solusi yang bagus. Gunakan Edittombol saat melihat PR di GitHub untuk mengubah cabang dasar ke sesuatu selain master. Kemudian alihkan kembali masterdan sekarang hanya akan menunjukkan perubahan dari komit terbaru.


4
Saya terkejut lebih banyak orang tidak mengakui solusi ini. Saya curiga permintaan tarik keluar yang asli akan baik-baik saja, tetapi saya tidak suka GitHub menampilkan semua file yang kedaluwarsa, jadi saya menggunakan ini dan keduanya menyimpan komentar dan hanya menunjukkan perubahan aktual yang akan digabung. . Terima kasih!
taranaki

2
Tidak bekerja untuk saya.
Shashank

Sialan ini berhasil!
Anurag Hazra

Tiga tahun kemudian dan ini masih merupakan solusi yang bagus. Dan lihat seseorang juga baru berkomentar beberapa jam yang lalu ^^^
Ricardo Saporta

32

Singkatnya, GitHub tidak mengubah riwayat komit secara otomatis dalam permintaan tarik. Solusi paling sederhana adalah:

Solusi 1: Rebase

Misalkan Anda ingin bergabung masterdari feature-01:

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

Jika Anda mengerjakan garpu maka Anda mungkin perlu mengganti origindengan upstream. Lihat Bagaimana cara saya memperbarui repositori bercabang GitHub? untuk mempelajari lebih lanjut tentang pelacakan cabang jauh dari repositori asli.

Solusi 2: Buat permintaan tarik baru

Misalkan Anda ingin menggabungkan intro masterdari feature-01:

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

Sekarang buka permintaan tarik untuk feature-01-rebaseddan tutup satu untuk feature-01.


4
Rebase mengubah hash komit, jadi apakah akhirnya akan menghancurkan komentar ulasan yang ada?
haridsv

@ haridsv Mungkin ya.
Mateusz Piotrowski

Adakah yang harus diperhatikan saat melakukan push - force?
Paul Bendevis

1
@ haridsv, itu bukan pengalaman saya. Saya sering membuat ulang pertengahan ulasan dan komentar tidak hilang. Meskipun saya kehilangan sejarah perubahan dalam PR
joel

@ JoelBerkeley Saya benar-benar mengalami beberapa ulasan sementara itu di mana penulis rebased dan mengamati bahwa komentar-komentar dalam kebijaksanaan. Namun, kami kehilangan kemampuan untuk meninjau secara bertahap dan untuk ulasan besar, ini merupakan penalti besar bagi pengulas. Kami sekarang memiliki beberapa pedoman untuk PR kami dan salah satunya tidak akan rebase setelah review dibuka (kecuali ada yang yakin belum ada yang mulai meninjau). Penggabungan baik-baik saja tetapi pedoman kami adalah untuk tidak mencampur perubahan gabungan dengan perubahan lain selain resolusi konflik.
haridsv

17

Anda perlu menambahkan yang berikut ke ~/.gitconfigfile Anda :

[rebase]
    autosquash = true

Ini akan secara otomatis mencapai yang sama dengan apa yang ditunjukkan oleh jawaban ini .

Saya mendapat ini dari sini .


2
sial, saya mengklik voting secara tidak sengaja. jawaban ini membantu saya. izinkan saya mengubahnya.
Hector

@hosein Pergi untuk itu. Anda harus dapat melakukannya sekarang.
Mateusz Piotrowski

1
Saya pikir ini harus berupa jawaban yang diterima, atau dimasukkan dalam jawaban yang diterima. Ini mencapai hasil yang saya cari!
Ronald Rey

1
@RonaldRey git rebasing bukanlah solusi universal, karena melibatkan pengeditan riwayat. Jika semua orang mengerjakan garpu pribadi yang tidak pernah dikloning oleh orang lain, maka tidak apa-apa, tetapi begitu seseorang mengkloning repositori Anda dan Anda kemudian mengedit sejarah, Anda berakhir dengan sejarah yang berbeda.
Adam Millerchip

14

Bagi siapa pun yang menemukan ini dan bingung dengan perilaku Permintaan Tarik GitHub, penyebab dasarnya adalah bahwa PR adalah beda ujung cabang sumber terhadap leluhur umum dari cabang sumber dan cabang target. Karena itu ia akan menampilkan semua perubahan pada cabang sumber hingga leluhur yang sama dan tidak akan memperhitungkan perubahan apa pun yang mungkin terjadi pada cabang target.

Informasi lebih lanjut tersedia di sini: https://developer.atlassian.com/blog/2015/01/a-better-pull-request/

Difs berbasis leluhur umum tampaknya berbahaya. Saya berharap GitHub memiliki opsi untuk membuat PR berbasis penggabungan 3-arah yang lebih standar.


1
Alasan yang Anda sebutkan tampaknya benar, tetapi saya bingung karena umumnya setiap kali master diperbarui, saya kembali menggabungkan perubahan ke cabang saya ... git checkout my-branch -> git merge master . Permintaan tarik segera disegarkan. Apakah nenek moyang yang sama juga mendapatkan pembaruan?
G.Satu

2
Perilaku ini tampaknya terjadi ketika melakukan rebase alih-alih bergabung
G.Satu

1
@ G.One, balasan yang benar-benar terlambat, tapi ya - jika Anda menggabungkan dari cabang master ke cabang sumber Anda, Anda secara definisi telah memperbarui leluhur yang sama. Ini adalah komit master yang Anda gabungkan.
David K. Hess

13

Salah satu cara untuk memperbaikinya adalah dengan git rebase targetbranchmenggunakan PR itu. Lalu git push --force targetbranch, maka Github akan menunjukkan commit yang tepat dan diff. Hati-hati dengan ini jika Anda tidak tahu apa yang Anda lakukan. Mungkin checkout cabang tes pertama untuk melakukan rebase kemudian git diff targetbranchuntuk memastikan itu masih apa yang Anda inginkan.


10

Ini terjadi dengan GitHub ketika squash Anda melakukan merger dari cabang target.

Saya telah menggunakan squash and merge dengan Github sebagai strategi penggabungan default, termasuk penggabungan dari cabang target. Ini memperkenalkan komit baru dan GitHub tidak menyadari bahwa komit tergencet ini sama dengan komit yang sudah ada di master (tetapi dengan hash yang berbeda). Git menanganinya dengan benar tetapi Anda melihat semua perubahan lagi di GitHub, membuatnya menjengkelkan untuk ditinjau. Solusinya adalah dengan melakukan gabungan rutin dari komitmen hulu ini alih-alih squash dan gabungan. Ketika Anda ingin menggabungkan cabang lain menjadi cabang Anda sebagai dependensi, git merge --squashdan kembalikan komit tunggal itu sebelum menarik dari master begitu cabang lain benar-benar membuatnya untuk dikuasai.

EDIT: solusi lain adalah rebase dan memaksa push. Riwayat bersih tapi ditulis ulang


1
Terima kasih @achille, ini benar-benar masalah di pihak saya. Setelah menonaktifkan penggabungan squash itu diselesaikan.
Ashvin777

0

Saya tidak begitu yakin tentang teori di balik ini. Tetapi saya mendapatkan ini beberapa kali dan dapat memperbaikinya dengan melakukan hal berikut.

git pull --rebase

Ini akan mengambil dan menggabungkan perubahan dari cabang master repo asli Anda (Jika Anda memiliki maksud untuk itu)

Kemudian Anda mendorong perubahan Anda dengan paksa ke repositori github Anda (target)

git push -f origin master

Ini akan memastikan klon github Anda dan repo orang tua Anda berada pada tingkat komit github yang sama dan Anda tidak melihat perubahan yang tidak perlu di seluruh cabang.


0

Coba perintah di bawah ini, satu per satu.

git pull "latest

git reset --hard master

-1

Gagal pendekatan yang aman jika Anda terlalu khawatir tentang mengacaukan segalanya: buka file dan hapus perubahan secara manual, lalu hancurkan dengan komit terakhir Anda menggunakan

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})"

Saya tidak ada konflik, Anda baik untuk pergi!

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.