Mengapa setiap repo Github serius yang saya lakukan menarik permintaan untuk ingin saya menekan komitmen saya menjadi satu komit?

Saya pikir log git ada di sana sehingga Anda dapat memeriksa semua sejarah Anda dan melihat dengan tepat perubahan apa yang terjadi di mana, tetapi menekannya menariknya keluar dari sejarah dan menggabungkannya menjadi satu komit. Apa intinya?

Ini juga tampaknya bertentangan dengan mantra "komit lebih awal dan komit sering".

Sehingga Anda memiliki sejarah git yang jelas dan ringkas yang dengan jelas dan mudah mendokumentasikan perubahan yang dilakukan dan alasannya.

Sebagai contoh, sebuah log git 'unsquashed' untuk saya mungkin terlihat seperti berikut:

7hgf8978g9... Added new slideshow feature, JIRA # 848394839
85493g2458... Fixed slideshow display issue in ie
gh354354gh... wip, done for the week
789fdfffdf... minor alignment issue
787g8fgf78... hotfix for #5849564648
9080gf6567... implemented feature # 65896859
gh34839843... minor fix (typo) for 3rd test

Berantakan sekali!

Sedangkan git log yang dikelola dan digabung dengan lebih hati-hati dengan sedikit fokus tambahan pada pesan untuk ini mungkin terlihat seperti:

7hgf8978g9... 8483948393 Added new slideshow feature
787g8fgf78... 5849564648 Hotfix for android display issue
9080gf6567... 6589685988 Implemented pop-up to select language

Saya pikir Anda dapat melihat titik squashing melakukan secara umum dan prinsip yang sama berlaku untuk menarik permintaan - Keterbacaan Sejarah. Anda juga dapat menambahkan ke log komit yang sudah memiliki ratusan atau bahkan ribuan komit dan ini akan membantu menjaga sejarah yang berkembang singkat dan singkat.

Anda ingin melakukan lebih awal dan sering. Ini praktik terbaik karena berbagai alasan. Saya menemukan bahwa ini menuntun saya untuk sering memiliki komitmen yang "menghapus" (pekerjaan dalam proses) atau "bagian A selesai" atau "kesalahan ketik, perbaikan kecil" di mana saya menggunakan git untuk membantu saya bekerja dan memberi saya poin kerja yang Saya dapat kembali ke jika kode berikut ini tidak berfungsi karena saya maju untuk menyelesaikan pekerjaan. Namun saya tidak perlu atau menginginkan sejarah itu sebagai bagian dari sejarah git akhir sehingga saya dapat menekan komitmen saya - tetapi lihat catatan di bawah ini tentang apa artinya ini pada cabang pengembangan vs master.

Jika ada tonggak utama yang mewakili tahapan kerja yang berbeda, masih ok untuk memiliki lebih dari satu komit per fitur / tugas / bug. Namun ini sering dapat menyoroti fakta bahwa tiket yang sedang dikembangkan adalah 'terlalu besar' dan perlu dipecah menjadi potongan-potongan kecil yang dapat berdiri sendiri, misalnya:

8754390gf87... Implement feature switches

sepertinya "1 karya". Entah mereka ada atau tidak! Sepertinya tidak masuk akal untuk memecahkannya. Namun pengalaman telah menunjukkan kepada saya bahwa (tergantung pada ukuran dan kompleksitas organisasi) jalur yang lebih terperinci adalah:

fgfd7897899... Add field to database, add indexes and a trigger for the dw group
9458947548g... Add 'backend' code in controller for when id is passed in url.
6256ac24426... Add 'backend' code to make field available for views.
402c476edf6... Add feature to UI

Potongan kecil berarti ulasan kode yang lebih mudah, pengujian unit yang lebih mudah, kesempatan yang lebih baik untuk qa, penyelarasan yang lebih baik dengan Prinsip Tanggung Jawab Tunggal, dll.

Untuk kepraktisan kapan harus melakukan squash seperti itu, pada dasarnya ada dua tahap berbeda yang memiliki alur kerja sendiri

• pengembangan Anda, mis. tarik permintaan
• pekerjaan Anda ditambahkan ke cabang jalur utama, mis. master

Selama perkembangan Anda, Anda melakukan pesan 'awal dan sering' dan dengan cepat 'sekali pakai'. Anda mungkin ingin squash di sini kadang-kadang, misalnya terjepit di wip dan todo pesan dilakukan. Tidak masalah, di dalam cabang, untuk mempertahankan beberapa komitmen yang mewakili langkah berbeda yang Anda buat dalam pengembangan. Sebagian besar squash yang Anda pilih harus berada di dalam cabang-cabang fitur ini, sementara mereka sedang dikembangkan dan sebelum bergabung untuk dikuasai.
Saat menambahkan ke cabang jalur utama, Anda ingin komit dibuat ringkas dan diformat dengan benar sesuai dengan riwayat jalur utama yang ada. Ini mungkin termasuk ID sistem Pelacak Tiket, mis. JIRA seperti ditunjukkan dalam contoh. Squashing tidak benar-benar berlaku di sini kecuali jika Anda ingin 'menggulung' beberapa komitmen berbeda pada master. Biasanya tidak.

Menggunakan --no-ffsaat penggabungan ke master akan menggunakan satu komit untuk penggabungan dan juga mempertahankan sejarah (di cabang). Beberapa organisasi menganggap ini sebagai praktik terbaik. Lihat lebih lanjut di https://stackoverflow.com/q/9069061/631619 Anda juga akan melihat efek praktis di git logmana --no-ffkomit akan menjadi komit terbaru, di bagian atas KEPALA (bila baru saja selesai), sedangkan tanpanya --no-ffmungkin lebih jauh dalam sejarah, tergantung pada tanggal dan komitmen lainnya.

Karena seringkali orang yang menarik PR peduli tentang efek bersih dari komit "menambahkan fitur X", bukan tentang "templat dasar, fungsi perbaikan bug X, menambahkan fungsi Y, memperbaiki kesalahan ketik dalam komentar, parameter penskalaan data yang disesuaikan, hashmap berkinerja lebih baik daripada daftar "... level detail

Jika Anda berpikir bahwa 16 komit Anda lebih baik diwakili oleh 2 komit daripada 1 "Fitur tambahan X, faktor ulang Z untuk menggunakan X" maka itu mungkin baik untuk mengusulkan sebuah pr dengan 2 komit, tetapi mungkin lebih baik untuk mengusulkan 2 p terpisah dalam hal itu (jika repo masih bersikeras pada komit tunggal)

Ini tidak bertentangan dengan mantra "komit lebih awal dan komit sering", seperti dalam repo Anda, ketika Anda sedang mengembangkan Anda masih memiliki detail granular, sehingga Anda memiliki peluang minimal kehilangan pekerjaan, dan orang lain dapat meninjau / menarik / mengusulkan pr menentang pekerjaan Anda saat pr baru sedang dikembangkan.

Alasan utama dari apa yang bisa saya lihat adalah sebagai berikut:

• GitHub UI untuk menggabungkan permintaan tarikan saat ini (Oktober 2015) tidak memungkinkan Anda untuk mengedit baris pertama dari pesan komit, memaksanya menjadi Merge pull request #123 from joebloggs/fix-snafoo
• GitHub UI untuk menelusuri riwayat komit saat ini tidak memungkinkan Anda untuk melihat riwayat cabang dari --first-parentsudut pandang
• GitHub UI untuk melihat kesalahan pada file saat ini tidak memungkinkan Anda untuk melihat kesalahan file dengan --first-parentsudut pandang (perhatikan bahwa ini hanya diperbaiki di Git 2.6.2, jadi kami bisa memaafkan GitHub karena tidak memiliki itu tersedia)

Jadi, ketika Anda menggabungkan ketiga situasi di atas, Anda mendapatkan situasi di mana komit tanpa ikatan digabung terlihat buruk dari GitHub UI.

Riwayat Anda dengan komit terjepit akan terlihat seperti

1256556316... Merge pull request #423 from jrandom/add-slideshows
7hgf8978g9... Added new slideshow feature
56556316ad... Merge pull request #324 from ahacker/fix-android-display
787g8fgf78... Hotfix for android display issue
f56556316e... Merge pull request #28 from somwhere/select-lang-popup
9080gf6567... Implemented pop-up to select language

Sedangkan tanpa terjepit melakukan sejarah akan terlihat seperti

1256556316... Merge pull request #423 from jrandom/add-slideshows
7hgf8978g9... Added new slideshow feature, JIRA # 848394839
85493g2458... Fixed slideshow display issue in ie
gh354354gh... wip, done for the week
789fdfffdf... minor alignment issue
56556316ad... Merge pull request #324 from ahacker/fix-android-display
787g8fgf78... hotfix for #5849564648
f56556316e... Merge pull request #28 from somwhere/select-lang-popup
9080gf6567... implemented feature # 65896859
gh34839843... minor fix (typo) for 3rd test

Ketika Anda memiliki banyak komitmen dalam penelusuran PR di mana perubahan terjadi dapat menjadi sedikit mimpi buruk jika Anda membatasi diri untuk menggunakan GitHub UI .

Misalnya, Anda menemukan penunjuk nol sedang tidak direferensikan di suatu tempat dalam file ... jadi Anda berkata "siapa yang melakukan ini, dan kapan? Versi rilis apa yang terpengaruh?". Kemudian Anda berjalan ke tampilan menyalahkan di UI GitHub dan Anda melihat bahwa garis itu diubah789fdfffdf... "oh tapi tunggu sebentar, baris itu baru saja indentasinya diubah agar sesuai dengan sisa kode", jadi sekarang Anda perlu menavigasi ke status pohon untuk file yang di komit induk dan mengunjungi kembali halaman menyalahkan ... akhirnya Anda menemukan komit ... itu komit dari 6 bulan yang lalu ... "oh **** ini dapat mempengaruhi pengguna selama 6 bulan" Anda mengatakan ... ah tapi tunggu, komit itu sebenarnya dalam Permintaan Tarik dan hanya bergabung kemarin dan belum ada yang memotong rilis ... "Sialan kalian untuk menggabungkan komitmen tanpa menekan sejarah" adalah teriakan yang biasanya dapat didengar setelah sekitar 2 atau 3 ekspedisi kode arkeologi melalui GitHub UI

Sekarang mari kita pertimbangkan bagaimana ini bekerja jika Anda menggunakan baris perintah Git (dan super-mengagumkan 2.6.2 yang memiliki perbaikan untuk git blame --first-parent)

• Jika Anda menggunakan baris perintah Git, Anda akan dapat sepenuhnya mengontrol pesan gabungan komit dan karenanya komit gabungan bisa memiliki baris ringkasan yang bagus.

Jadi sejarah komit kita akan terlihat seperti

$ git log
1256556316... #423 Added new slideshow feature
7hgf8978g9... Added new slideshow feature, JIRA # 848394839
85493g2458... Fixed slideshow display issue in ie
gh354354gh... wip, done for the week
789fdfffdf... minor alignment issue
56556316ad... #324 Hotfix for android display issue
787g8fgf78... hotfix for #5849564648
f56556316e... #28 Implemented pop-up to select language
9080gf6567... implemented feature # 65896859
gh34839843... minor fix (typo) for 3rd test

Tapi kita juga bisa melakukannya

$ git log --first-parent
1256556316... #423 Added new slideshow feature
56556316ad... #324 Hotfix for android display issue
f56556316e... #28 Implemented pop-up to select language

(Dengan kata lain: Git CLI memungkinkan Anda memiliki kue dan memakannya juga)

Sekarang ketika kita menekan masalah null pointer ... well kita hanya menggunakan git blame --first-parent -w dodgy-file.cdan kita langsung diberikan komit tepat di mana referensi-nol pointer-nol diperkenalkan ke cabang master mengabaikan perubahan spasi putih sederhana.

Tentu saja jika Anda melakukan penggabungan menggunakan GitHub UI maka git log --first-parentitu benar-benar jelek berkat GitHub yang memaksa baris pertama dari pesan komit gabungan:

1256556316... Merge pull request #423 from jrandom/add-slideshows
56556316ad... Merge pull request #324 from ahacker/fix-android-display
f56556316e... Merge pull request #28 from somwhere/select-lang-popup

Jadi untuk mempersingkat cerita:

GitHub UI (Oktober 2015) memiliki sejumlah kekurangan dengan cara menggabungkan permintaan tarik, bagaimana menyajikan riwayat commit dan bagaimana atributnya menyalahkan informasi. Cara terbaik saat ini untuk meretas cacat-cacat ini di GitHub UI adalah dengan meminta orang untuk menekan komitmen mereka sebelum bergabung.

Git CLI tidak memiliki masalah ini dan Anda dapat dengan mudah memilih tampilan mana yang ingin Anda lihat sehingga Anda berdua dapat menemukan alasan mengapa perubahan tertentu dibuat seperti itu (dengan melihat riwayat dari komitmen yang tidak dirusak) serta lihat komitmen terjepit.

Tulisan Skrip

Alasan terakhir yang sering dikutip untuk squashing commit adalah untuk membuat backporting lebih mudah ... jika Anda hanya memiliki satu commit untuk mendukung port (yaitu commit squashing) maka mudah untuk memilih ...

Nah jika Anda melihat sejarah git dengan git log --first-parentmaka Anda bisa saja memilih komit gabungan. Sebagian besar orang bingung menentukan komitmen memilih cherry karena Anda harus menentukan -m Nopsi tetapi jika Anda mendapat komit dari git log --first-parentmaka Anda tahu bahwa itu adalah orang tua pertama yang ingin Anda ikuti sehingga akan menjadigit cherry-pick -m 1 ...

Saya setuju dengan sentimen yang diungkapkan dalam jawaban lain di utas ini tentang menunjukkan riwayat fitur yang jelas dan ringkas yang ditambahkan dan bug diperbaiki. Namun saya lakukan, ingin membahas aspek lain yang pertanyaan Anda luput tetapi tidak secara eksplisit menyatakan. Bagian dari hangup yang mungkin Anda miliki tentang beberapa metode kerja git adalah git memungkinkan Anda untuk menulis ulang sejarah yang tampaknya aneh ketika diperkenalkan ke git setelah menggunakan bentuk kontrol sumber lain di mana tindakan seperti itu tidak mungkin. Selain itu, ini juga bertentangan dengan prinsip kontrol sumber yang diterima secara umum bahwa sekali sesuatu dilakukan / dicentang ke kontrol sumber, Anda harus dapat kembali ke keadaan itu tidak peduli perubahan apa pun yang Anda lakukan setelah komit itu dilakukan. Seperti yang Anda maksudkan dalam pertanyaan Anda, ini adalah salah satu situasi itu. Saya pikir git adalah sistem kontrol versi yang hebat; namun, untuk memahaminya Anda harus memahami beberapa detail implementasi dan merancang keputusan di baliknya, dan sebagai hasilnya ia memiliki kurva belajar yang lebih curam. Perlu diingat git dimaksudkan untuk menjadi sistem kontrol versi terdistribusi dan itu akan membantu menjelaskan mengapa para desainer mengizinkan sejarah git untuk ditulis ulang dengan squash commit menjadi salah satu contohnya.

Karena perspektif ... Praktik terbaik adalah memiliki komitmen tunggal per <<issue-management-system>>masalah tunggal jika memungkinkan.

Anda dapat memiliki banyak komitmen seperti yang Anda inginkan di cabang fitur / repo Anda sendiri, tetapi itu adalah riwayat Anda yang relevan dengan apa yang Anda lakukan sekarang untuk perspektif ANDA ... itu bukan SEJARAH untuk seluruh TIM / PROYEK atau aplikasi dari mereka perspektif untuk disimpan beberapa bulan dari sekarang ...

Jadi setiap kali Anda ingin melakukan perbaikan bug atau fitur untuk repo umum (contoh ini adalah dengan mengembangkan cabang) apa yang bisa Anda lakukan sebagai berikut:

cara rebase cabang fitur Anda menjadi berkembang dengan cepat

    # set your current branch , make a backup of it , caveat minute precision
    curr_branch=$(git rev-parse --abbrev-ref HEAD); git branch "$curr_branch"--$(date "+%Y%m%d_%H%M"); git branch -a | grep $curr_branch | sort -nr

    # squash all your changes at once 
    git reset $(git merge-base develop $curr_branch)

    # check the modified files to add 
    git status

    # add the modified files dir by dir, or file by file or all as shown
    git add --all 

    # check once again 
    git log --format='%h %ai %an %m%m %s'  | less

    # add the single message of your commit for the stuff you did 
    git commit -m "<<MY-ISSUE-ID>>: add my very important feature"

    # check once again 
    git log --format='%h %ai %an %m%m %s'  | less

    # make a backup once again , use seconds precision if you were too fast ... 
    curr_branch=$(git rev-parse --abbrev-ref HEAD); git branch "$curr_branch"--$(date "+%Y%m%d_%H%M"); git branch -a | grep $curr_branch | sort -nr

    # compare the old backup with the new backup , should not have any differences 
    git diff <<old-backup>>..<<new-backup-branch>>


    # you would have to git push force to your feature branch 
    git push --force 

Saya akan melihat apakah kode tersebut go public atau tidak.

Ketika proyek bersifat pribadi:

Saya akan merekomendasikan untuk tidak squash dan melihat pembuatan sosis. Jika Anda menggunakan komit yang baik dan kecil, alat seperti git bisect sangat berguna dan orang-orang dapat dengan cepat menunjukkan komitmen regresi, dan melihat mengapa Anda melakukannya (karena pesan komit).

Ketika proyek go public:

Hancurkan semuanya karena beberapa komit dapat berisi kebocoran keamanan. Misalnya kata sandi yang telah dikomit dan dihapus lagi.