Di mana refactoring termasuk dalam model penamaan cabang GitFlow?

Saya baru-baru ini mulai bekerja dengan model GitFlow seperti yang diterapkan oleh bitbucket. Dan ada satu hal yang tidak sepenuhnya jelas bagi saya.

Kami mencoba untuk secara teratur mengatasi utang teknis kami dengan menumpuk, merencanakan, dan melaksanakan tugas-tugas refactoring. Cabang-cabang refactoring semacam itu diakhiri dengan tarik-permintaan yang digabung develop. Pertanyaan saya adalah di mana cabang refactoring berada di GitFlow ?

Menggunakan featureawalan tampaknya yang paling logis, namun rasanya tidak sepenuhnya benar, karena refactoring tidak menambah fungsionalitas baru.
Namun menggunakan bugfixawalan tampaknya tidak benar dan tidak ada perbaikan bug refactoring yang sebenarnya .
Membuat awalan khusus di sisi lain sepertinya menyulitkan jika tidak melakukan rekayasa berlebihan.

Apakah Anda mengalami situasi seperti itu? Latihan mana yang Anda gunakan untuk mengatasi ini? Tolong jelaskan mengapa.

— AMA
sumber

Mengapa Anda memerlukan cabang untuk refaktor sama sekali? Mereka tidak mengubah fungsi produk dengan definisi, jadi Anda harus dapat melakukannya secara langsung dalam pengembangan.

— jonrsharpe

@jonrsharpe singkatnya, lebih nyaman dan terkendali. Biasanya ada tiket Jira untuk refactoring dan juga kode-ditinjau selama permintaan tarik. Selain itu build dan tes dijalankan untuk itu, sebelum digabungkan. Kami mencoba untuk terus mengembangkan cabang hijau.

— AMA

Anda hal-hal rekayasa berlebihan - dalam hal ini, prosesnya. Refactor saat Anda bekerja pada sistem, bukan sebagai paket kerja diskrit.

— Mr Cochese

Dalam hal ini: 1. Anda mendapatkan simpati saya; dan 2. Saya akan mengatakan gunakan refactor, maka sudah jelas apa yang mengubah setiap penggabungan yang diharapkan untuk dilakukan pada produk (perbaikan bug: memperbaiki perilaku yang rusak, fitur: tambahkan perilaku baru, refactor: pertahankan perilaku sebelumnya). Tapi @MrCochese benar, seharusnya benar-benar menjadi bagian dari pekerjaan lain yang Anda lakukan bukan tugas yang terpisah. Perhatikan juga bahwa jika refactor Anda merusak build, mereka bukan refactor!

— jonrsharpe

Beberapa pekerjaan refactoring yang Anda lakukan harus benar-benar menjadi bagian dari pekerjaan utama. Saya tentu tidak akan membuat cabang refactor secara rutin, tetapi hanya sebagai bagian dari upaya pembersihan yang lebih besar. Menjadikan ini kebiasaan akan mendorong kebiasaan buruk lainnya, seperti menunda pekerjaan pembersihan ke cabang "refactor".

— Robert Harvey

Pekerjaan refactoring harus dilakukan di cabang fitur.

Awalan "fitur" hanyalah sebuah kata untuk menggambarkan tugas pemrograman diskrit, Anda dapat memilih kata yang Anda suka, cabang apa pun dari pengembangan adalah cabang "fitur" atau cabang "rilis"

Menambahkan awalan baru seperti "refactoring" bermasalah. Karena Anda akan sering melakukan refactoring ketika menambahkan fitur, Anda hanya memberi diri Anda masalah penamaan dan menambahkan kebingungan. yaitu. "beberapa cabang fitur kami disebut 'refactoring', tidak, mereka tidak mengandung semua pekerjaan refactoring dan kadang-kadang mereka memiliki perbaikan bug atau fitur di dalamnya '

sama "hotfix" cabang tidak disebut hotfix karena mengandung hotfix, tetapi karena mereka bercabang dari master daripada mengembangkan

— Ewan
sumber

Terima kasih. Ini terdengar masuk akal. Saya akan menunggu lebih lama, dan jika tidak ada jawaban lain, saya akan menerima jawaban Anda.

— AMA