Git - Masalah apa yang muncul dari bekerja langsung pada master?

25

Saya telah melihat banyak saran tentang model percabangan git dan pendapat paling umum tampaknya bahwa membuat perubahan langsung pada cabang master adalah ide yang buruk.

Salah satu rekan kerja kami cukup senang membuat perubahan langsung di cabang utama, dan meskipun beberapa percakapan, mereka sepertinya tidak akan mengubah ini.

Pada titik waktu ini, saya tidak dapat meyakinkan rekan kerja yang merupakan praktik buruk untuk bekerja secara langsung pada master, tetapi saya ingin memahami hal-hal yang akan bertentangan dengan cara kerjanya, untuk mengetahui kapan saya perlu mengunjungi kembali masalah ini.

version-control git svn branching linuxunil
sumber
2
Tentukan "bekerja secara langsung". Guru ada karena itu dimaksudkan untuk digunakan. Anda pikir untuk apa dan untuk apa?
candied_orange
3
Apakah bekerja dari tuan bekerja untuk Anda? Jika ya, mengapa Anda merasa perlu berubah sekarang? Jika tidak berfungsi, masalah apa yang Anda alami? Alih-alih meminta orang untuk mengarahkan Anda ke argumen orang lain, kami dapat membantu Anda memecahkan masalah Anda.
Thomas Owens
1
Kedengarannya seperti dia melakukan pengembangan trunk, yang, bersama dengan integrasi berkelanjutan, cukup normal di tim Agile. Jika dia ingin bekerja seperti ini, Anda harus menegakkan WIP untuk memastikan bahwa tidak pernah ada terlalu banyak pekerjaan yang terjadi pada satu produk pada suatu waktu - dan juga menggunakan peralihan fitur untuk memastikan bahwa master dapat dilepaskan dengan fitur tidak lengkap dimatikan.
Mr Cochese
... seberapa besar timnya?
ZJR
@ McCochese Saya tidak akan menyebut pengembangan trunk dalam arti di sini "normal". Tentu saja tidak satu pun dari banyak tempat yang pernah saya gunakan, Git telah bekerja seperti itu, dan saya akan mengecilkannya. Cabang fitur berfungsi lebih baik.
Marnen Laibow-Koser

Jawaban:

57

Ada beberapa masalah ketika komit langsung didorong untuk dikuasai

  • Jika Anda mendorong status pekerjaan-dalam-proses ke jarak jauh, master berpotensi rusak
  • Jika pengembang lain mulai bekerja untuk fitur baru dari master, ia mulai dengan kondisi yang berpotensi rusak. Ini memperlambat perkembangan
  • Berbagai fitur / perbaikan bug tidak terisolasi, sehingga kompleksitas semua tugas pengembangan yang sedang berlangsung digabungkan dalam satu cabang. Ini meningkatkan jumlah komunikasi yang diperlukan antara semua pengembang
  • Anda tidak dapat melakukan permintaan tarik yang merupakan mekanisme yang sangat baik untuk ulasan kode
  • Anda tidak dapat menekan komit / mengubah riwayat git secara umum, karena pengembang lain mungkin sudah menarik cabang master sementara itu
Gernot
sumber
11
Hei lihat! Anda sebenarnya menjawab pertanyaan itu, tidak seperti orang lain pada dasarnya. ++ Selamat datang di SE.SE!
RubberDuck
Sebagian besar dari ini adalah masalah yang berasal dari bekerja secara langsung pada master yang buruk , bukan dari bekerja langsung pada master per se.
Semut P
1
@AntP masalah apa yang bisa dicegah dari sudut pandang Anda?
Gernot
10

Jelaskan kepadanya bahwa fitur-fitur baru memerlukan cabang pengembangan mereka sendiri yang dapat digunakan untuk lingkungan pengujian sebelum didorong ke produksi.

Jika tidak, Anda dalam kondisi abadi dengan fitur setengah jadi. Anda tidak dapat menggunakan fitur yang setengah jadi untuk produksi, jadi jika Anda bekerja langsung pada cabang master, semua orang harus menunggu Anda untuk menyelesaikan fitur Anda sebelum perubahan orang lain dapat diproduksi, termasuk perbaikan bug.

Menggunakan cabang independen untuk fitur berarti bahwa setiap fitur baru dapat diuji dan digunakan secara terpisah dari yang lain.

Robert Harvey
sumber
"Anda tidak dapat menggunakan fitur setengah jadi untuk produksi" - ini tidak benar sama sekali - sangat mungkin untuk bekerja langsung pada cabang utama, kode kapal setiap komit, sering menggunakan "fitur setengah jadi" dan tidak pernah melanggar apa pun . Pengiriman berkelanjutan adalah tentang melakukan hal ini: memisahkan pemasangan dari rilis. Yang juga terjadi untuk menyelesaikan banyak masalah organisasi lain yang biasanya ditangani orang dengan solusi teknis setengah rusak. Terkadang ini melibatkan fitur toggle tetapi biasanya dimungkinkan untuk membangun dan menggunakan 90% fitur tanpa perubahan perilaku yang terlihat.
Semut P
@ AntP: Proses yang Anda gambarkan bukan apa yang saya sebut "fitur setengah jadi." Fitur tersebut baik diuji, produksi-siap dan dapat digunakan, atau mereka disembunyikan oleh sebuah saklar fitur atau sesuatu yang serupa sampai saat mereka sedang diuji, produksi-siap dan dapat digunakan. Anda tidak mengirim fitur yang tidak berfungsi.
Robert Harvey
Anda menegaskan bahwa fitur baru perlu dikembangkan di cabang non-master karena Anda tidak dapat menggunakan yang setengah jadi: bukan itu masalahnya. Anda benar-benar dapat mengembangkan fitur-fitur baru secara langsung pada master dan mengirimkan kode apa saja yang terkait dengan fitur-fitur tersebut untuk diproduksi sebelum fitur tersebut lengkap dan tanpa menahan pengembangan lainnya.
Semut P
1
@AntP: Satu-satunya hal yang dimiliki cabang fitur yang tidak bisa disediakan oleh teknik Anda adalah penghitungan lengkap pekerjaan yang dilakukan pada fitur tertentu. Di beberapa toko (khususnya milik saya), pertanggungjawaban semacam itu bukanlah suatu kemewahan melainkan suatu persyaratan.
Robert Harvey
1
@ AntP Jika saya mengerti Anda dengan benar, saya akan menganggap itu sebagai langkah mundur. Saya suka pelacak isu bagus, dan saya menggunakannya secara luas, tetapi saya ingin VCS memberi tahu saya sejarah pengembangan fitur atau baris kode apa pun. Pelacak masalah dapat menceritakan kisah perubahan sisi bisnis , tetapi jika VCS tidak dapat membantu saya melacak dan mengaudit kode itu sendiri, maka itu tidak melakukan tugasnya. Ini adalah salah satu alasan saya keberatan dengan pengembangan berbasis trunk: itu membuat VCS bodoh, tanpa keuntungan kompensasi yang bisa saya lihat. (Juga: kopling getas? Fitur adalah perubahan kode.)
Marnen Laibow-Koser
2

Master harus berpotensi dirilis. Periode. Seharusnya tidak ada setengah jadi karya master (kecuali dinonaktifkan dengan bendera fitur)

Dengan mengatakan bahwa saya telah melihat beberapa tim mempersulit aliran mereka.

Tidak menggunakan PR saat mengintegrasikan ke master adalah kesalahan karena pengembang tidak akan memiliki kekuatan untuk memilih ketika integrasi terjadi.

Cabang pengembangan tunggal membawa nilai yang sangat kecil. Biasanya itu hanya mempersulit. Banyak cabang fitur membawa banyak nilai.

Membuat cabang untuk setiap lingkungan (dev, test, prod) adalah sebuah kesalahan. Ini di luar ruang lingkup untuk git dan harus ditangani oleh pipa rilis. Bangunan yang sama persis harus digunakan untuk semua lingkungan yang tidak mungkin jika ada cabang untuk setiap lingkungan.

Jika fitur sangat besar tidak dapat dilakukan dalam satu atau dua hari semua pekerjaan ke cabang fitur harus di cabang terpisah dan terintegrasi dengan PR.

Esben Skov Pedersen
sumber
Saya setuju dengan sebagian besar dari apa yang Anda katakan, kecuali untuk ini: "Bangunan yang sama persis harus digunakan untuk semua lingkungan". Bahkan, sebuah pipa rilis umumnya harus dapat menggunakan bangunan yang berbeda untuk lingkungan yang berbeda dan kemudian mempromosikannya saat pengujian berlalu. Bagaimana Anda menangani ini, jika tidak dengan cabang berbeda (atau setidaknya tag berbeda)?
Marnen Laibow-Koser
Mungkin saya tidak sepenuhnya jelas. Setelah membangun dikerahkan ke lingkungan. Artefak yang sama harus digunakan untuk lingkungan berikutnya tanpa membangun kembali.
Esben Skov Pedersen
Jika Anda memiliki bangunan berulang, tidak masalah apakah Anda membangun kembali. Jika Anda tidak memiliki bangunan berulang, Anda punya masalah yang lebih besar. :)
Marnen Laibow-Koser
... tapi ya, saya pikir Anda harus menandai komitmen yang digunakan agar Anda dapat mempromosikan kode yang sama (terlepas dari apakah Anda membangun kembali).
Marnen Laibow-Koser
Ya, tetapi sebagian besar server CI dapat menautkan build ke rilis di luar kotak sehingga memudahkan untuk melacak penyebaran. Ketika setup dengan benar, itu tidak benar-benar diperlukan untuk melacak penyebaran di git. Git adalah scm. Bukan alat penyebaran.
Esben Skov Pedersen
2
  • Master harus mencerminkan cabang produksi, versi final yang berfungsi.
  • Bekerja langsung di master berarti bahwa jika Anda membuat bug, Anda tidak memiliki pilihan lain untuk "kembali" daripada membalikkan / menghapus / mereset komit, yang bukan cara kerja yang bersih dan dapat menyebabkan Anda kehilangan bagian-bagian dari kode baru yang baik-baik saja.
  • Tentu saja, pada tahap pertama pengembangan mungkin Anda dapat mulai bekerja secara langsung pada master, tetapi setelah Anda memiliki sesuatu untuk disampaikan, Anda harus menggunakan cabang pengembangan, pengujian atau percobaan untuk tidak menyentuh versi yang diterbitkan, lengkap, dan berfungsi.
Tulains Córdova
sumber
2

Pertama, saya ingin menunjukkan bahwa dalam git, setiap pulloperasi secara harfiah bercabang, dan setiap pushgabungan. Pada mastermesin pengembang adalah cabang yang sepenuhnya terpisah dari masterpada repo pusat yang Anda bagikan, dengan kedudukan yang sama dari perspektif teknis. Kadang-kadang saya akan mengganti nama versi lokal saya upstreamatau sesuatu jika itu sesuai dengan tujuan saya lebih baik.

Saya menunjukkan hal ini karena banyak organisasi berpikir mereka menggunakan cabang lebih efektif daripada rekan Anda, ketika mereka benar-benar melakukan sedikit lebih banyak daripada membuat nama tambahan untuk cabang di sepanjang jalan, itu tidak akan disimpan dalam sejarah. Jika kolega Anda sedang melakukan fitur dalam satu komit atom, sama mudahnya untuk mundur sebagai komit gabungan dari cabang fitur. Sebagian besar cabang fitur harus berumur pendek dan sering digabungkan.

Yang sedang berkata, kelemahan utama dari gaya kerjanya ada dua. Pertama, sangat sulit untuk berkolaborasi pada fitur yang belum selesai. Namun, tidak akan sulit untuk membuat cabang pada saat-saat ketika kolaborasi diperlukan.

Kedua, membuat review sebelum penggabungan menjadi sangat sulit. Pada titik ini, Anda sebenarnya tidak perlu meyakinkannya. Anda dapat mengadopsi alat seperti github, gerrit, atau gitlab, dan memerlukan ulasan kode permintaan tarik dan lulus tes otomatis untuk semua penggabungan. Jika Anda tidak melakukan hal seperti ini, terus terang Anda tidak menggunakan git secara maksimal, dan tidak heran kolega Anda tidak melihat potensi itu.

Karl Bielefeldt
sumber
1
Juga mendorong pengembang mesin cabangnya setiap hari adalah cadangan yang bagus.
Ian
Saya tidak mengerti perasaan pertama Anda. Saya tidak melihat bagaimana a pullakan membuat cabang baru atau bagaimana pushoperasi penggabungan. Sebaliknya, pulladalah secara harfiah sebuah fetchdiikuti oleh merge!
mkrieger1
@ mkrieger1 Saya dapat dengan mudah melihat bagaimana orang dapat menganggap lokal mastersebagai cabang yang berbeda origin master. Secara teknis, mereka adalah cabang yang berbeda pada dua remote yang berbeda, masing-masing dengan sejarah mereka sendiri.
RubberDuck
@RubberDuck Ya, tepatnya. Dengan pull: Sebelum: dua cabang berpotensi menunjuk komit yang berbeda - Setelah: dua cabang menunjuk komit setara - Tidak ada cabang yang dibuat, oleh karena itu saya tidak akan menyebutnya "operasi percabangan". Jika salah satu dari dua perintah, saya akan menyebutnya push, karena berpotensi membuat cabang baru di remote. Apa yang tidak dilakukannya, adalah penggabungan.
mkrieger1
@ mkrieger1 Anda perlu mempertimbangkan arah penggabungan juga.
RubberDuck
2

Jawaban lain telah menyebutkan berbagai keuntungan (fitur terisolasi, kode shippable selalu pada master, dll) untuk bekerja TIDAK pada master secara langsung.

Bagi saya, Anda tampaknya memiliki masalah yang berbeda. Jelas Anda tidak memiliki proses pengembangan, yang disetujui atau digunakan oleh semua pengembang Anda (atau pengembang Anda yang bersangkutan benar-benar mengabaikan proses tersebut).

Apakah Anda memiliki cabang fitur, yang digabung menjadi master atau apakah Anda memiliki cabang rilis yang berbeda juga atau apakah Anda menggunakan proses yang sama sekali berbeda?

"Jangan gunakan cabang master" tidak cukup.

Simon
sumber
2

Salah satu rekan kerja kami cukup senang membuat perubahan langsung di cabang utama, dan meskipun beberapa percakapan, mereka sepertinya tidak akan mengubah ini.

Ini membuat saya percaya ada lebih banyak masalah. Bekerja pada master atau tidak sebagian besar merupakan bagian dari filosofi yang lebih besar tentang bagaimana, apa dan kapan Anda merilis produk.

Jadi bersamaan dengan "Anda seharusnya tidak pernah bekerja pada master", apakah Anda memiliki tes fitur, apakah Anda menguji satu sama lain bekerja apakah Anda meninjau satu sama lain kode. Tes penerimaan dan integrasi.

Jika Anda tidak memiliki hal-hal di atas dan Anda hanya melakukannya untuk "melakukan git", Anda bisa juga bekerja pada master.

Pieter B
sumber
1

Tidak ada "praktik buruk" di sekitar bekerja langsung di cabang. Tetapi Anda harus memutuskan apa yang paling mendukung proses Anda:

Pertanyaan 1: Haruskah master Anda mewakili status rilis perangkat lunak Anda saat ini? Maka Anda harus memperkenalkan cabang pengembangan global dan menggabungkan pengembangan di akhir pengembangan rilis.

Pertanyaan 2: Apakah Anda ingin memiliki proses peninjauan kode? Maka Anda harus memiliki "cabang fitur" yang akan digabungkan menjadi master (atau mengembangkan, jika Anda memilikinya) melalui permintaan tarik.

Pertanyaan 3: Apakah perlu membagikan status kode perantara ke pengembang lain yang belum dipublikasikan dalam produksi (atau pengujian)? Itu sebabnya lebih dari satu pengembang mengembangkan fitur. Maka Anda harus memperkenalkan "cabang fitur".

oopexpert
sumber
Tag adalah cara yang sangat layak untuk mewakili keadaan basis kode saat rilis. Git membuatnya sangat mudah untuk checkout tag tertentu. Membuat cabang dev jenis moot.
RubberDuck