Permintaan tarik dibuat sehingga seseorang dapat meninjau pekerjaan, membuat komentar, saran, membuat atau meminta suntingan dan kemudian menggabungkan kode untuk dikuasai.
Dalam kasus Anda seseorang itu adalah Anda.
Sebagai satu-satunya pengembang Anda masih harus meninjau pekerjaan Anda sendiri, refactor dan menggabungkannya untuk dikuasai ketika siap.
Salah satu pendekatan yang sering saya gunakan adalah mencoba 'memakai topi lain', 'coba kepribadian lain'. Jadi duduk sebentar dan tempatkan diri Anda dalam situasi: pemula untuk grup; pengembang junior; kolega yang Anda hormati di masa lalu, dll. Coba dan lihat melalui mata mereka dan coba pikirkan apa yang bisa Anda lakukan untuk membuat perubahan lebih jelas, lebih baik ditulis dengan nama yang lebih baik yang menghindari pengetahuan suku dan domain sebanyak mungkin .
Jadi, seperti yang Anda tunjukkan, Anda harus bekerja di cabang ketika Anda ingin memisahkan fitur dan perubahan yang tidak siap untuk master. Anda dapat melakukan semua itu di cabang (Anda bahkan tidak perlu menarik permintaan untuk mengelolanya jika Anda tetap melakukan tugas PR, tetapi mungkin memberikan struktur yang berguna bagi Anda).
Juga, kadang-kadang saya akan menemukan bahwa perubahan saya tidak berfungsi, tetapi alih-alih kengerian mencoba untuk mundur dari master, mungkin sekarang dicampur dengan perubahan master lainnya, saya hanya bisa melakukan semuanya di cabang yang kemudian dapat saya abaikan / hapus jika mulai salah. Ini adalah manfaat yang sangat besar.
Jadi, Anda harus bekerja di cabang dan tidak berkomitmen langsung untuk menguasai sampai Anda memutuskan untuk menggabungkan seluruh cabang.
Ini adalah pedoman - dan bukan aturan - untuk diikuti. Terkadang saya sengaja mematahkannya. Misalnya, kemarin saya melakukan perbaikan kesalahan ketik untuk dikuasai.