Apakah melakukan / memeriksa kode setiap hari merupakan praktik yang baik?

63

Saya telah membaca catatan Martin Fowler tentang Integrasi Berkelanjutan dan ia mencantumkan sebagai keharusan "Setiap Orang Berkomitmen Untuk Mainline Setiap Hari".

Saya tidak suka melakukan kode kecuali bagian yang saya kerjakan selesai dan dalam praktiknya saya melakukan kode saya setiap tiga hari: satu hari untuk menyelidiki / mereproduksi tugas dan membuat beberapa perubahan awal, hari kedua untuk menyelesaikan perubahan , dan hari ketiga untuk menulis tes dan membersihkannya ^ untuk pengiriman. Saya tidak akan merasa nyaman mengirimkan kode lebih cepat.

Sekarang, saya menarik perubahan dari repositori dan mengintegrasikannya secara lokal biasanya dua kali sehari, tetapi saya tidak sering melakukan itu kecuali saya dapat mengukir sebagian kecil dari pekerjaan.

Pertanyaan: apakah melakukan setiap hari suatu praktik yang baik sehingga saya harus mengubah alur kerja saya untuk mengakomodasinya, atau tidak disarankan?

Sunting: Saya kira saya seharusnya mengklarifikasi bahwa maksud saya "komit" dalam makna CVS tentang itu (alias "push") karena kemungkinan itulah yang dimaksud Fowler pada tahun 2006 ketika ia menulis ini.

^ Urutannya lebih arbitrer dan tergantung pada tugasnya, maksud saya adalah menggambarkan rentang waktu dan kegiatan, bukan urutan yang tepat.

version-control

— Kereta luncur
sumber

20

Anda dapat mengkomit kode Anda jika mengkompilasi dan melakukan beberapa logika yang berguna. Lebih baik komit kode dalam siklus pendek jika Anda bekerja di lingkungan tim.

— EL Yusubov

4

Apakah Martin Fowler mengasumsikan VCS yang tidak didistribusikan?

— user16764

4

Catat tanggal pada artikel itu: 1 Mei 2006. Git dan Mercurial bahkan belum dimulai sampai April 2005, dan kesan saya adalah mereka benar-benar mulai mendapatkan daya tarik pada sekitar 2008. Saya tidak dapat menemukan artikel di situs Fowler yang merujuk untuk salah satu dari mereka sebelum 2009. Jadi artikel ini dari 2006 dengan jelas mengasumsikan sistem kontrol sumber terpusat seperti SVN. Saran ini tidak berlaku untuk tim yang menggunakan DVCS.

— Kyralessa

2

@ Kirralessa: Artikel itu bahkan menyatakan bahwa "Subversion adalah [sistem kontrol versi] modern".

— che

4

Pertama kode dan tes?

43

Saya tidak setuju dengan aturan ini dan saya setuju dengan apa yang dikatakan Mason Wheeler . Saya ingin menambahkan beberapa ide.

Saya mencoba untuk melakukan setiap kali saya memiliki perubahan yang berarti untuk melakukan: ini bisa beberapa kali sehari jika saya memperbaiki beberapa bug kecil, atau seminggu sekali jika saya bekerja pada perangkat lunak yang lebih besar yang tidak dapat digunakan oleh sisa dari kode dengan cara apa pun yang berarti sampai mencapai kondisi yang konsisten.

Juga, saya menafsirkan komitmen sebagai penerbitan revisi yang bermakna yang menyumbangkan fungsionalitas baru ke basis kode. Saya pikir seseorang harus mencoba untuk membersihkan kode sebelum melakukan sehingga pengembang lain dapat memahami arti dan tujuan perubahan ketika mereka melihat sejarah revisi. Semakin sedikit perubahan yang dilihat pengembang lain dalam riwayat, semakin baik: ketika saya melihat riwayat revisi, saya ingin melihat peningkatan yang menambahkan beberapa fungsi yang berarti; Saya tidak tertarik pada setiap ide kecil yang dimiliki masing-masing pengembang dan ingin mencoba sebelum mereka mencapai solusi.

Selain itu, saya tidak berpikir itu ide yang baik untuk menggunakan server SVN (atau sistem kontrol versi apa pun) sebagai fasilitas cadangan yang snapshot saat ini dari kode tersebut dilakukan (asalkan dikompilasi): Anda dapat menggunakan stik USB atau USB-drive eksternal atau disk jaringan untuk mencerminkan kode Anda saat ini sehingga tidak hilang jika komputer Anda rusak. Kontrol revisi dan cadangan data adalah dua hal yang berbeda. Menerbitkan revisi tidak sama dengan menyimpan snapshot kode Anda.

Akhirnya, saya berpikir bahwa itu seharusnya tidak menjadi masalah untuk dilakukan setiap sekarang dan kemudian (yaitu hanya ketika seseorang benar-benar puas dengan keadaan kode saat ini) dan menghindari penggabungan konflik bukanlah pembenaran yang baik untuk melakukan terlalu sering. Banyak konflik menggabungkan terjadi ketika orang yang berbeda bekerja pada file yang sama pada saat yang sama, yang merupakan praktik buruk (lihat misalnya artikel ini , poin 7). Menggabungkan konflik harus dikurangi dengan memecah proyek menjadi modul dengan antarmuka yang jelas dan ketergantungan sesedikit mungkin, dan dengan mengoordinasikan pekerjaan pengembang sehingga kode yang mereka kerjakan tumpang tindih sesedikit mungkin.

Hanya 2 sen saya.

SUNTING

Alasan lain terhadap komitmen prematur yang muncul di benak saya adalah bahwa versi (sangat) kereta tidak dapat diuji. Jika Anda berkomitmen pada trunk dan tim pengujian Anda menguji setiap hari, mereka mungkin tidak memiliki versi yang dapat diuji selama beberapa jam (atau selama sehari). Bahkan jika Anda tidak mencoba untuk memperbaiki bug dan hanya mengembalikan perubahan Anda, pembangunan kembali dapat memakan waktu beberapa jam. Dengan, katakanlah, lima penguji yang bekerja di tim Anda, Anda telah menyia-nyiakan waktu 5 x 2 = 10 jam karena kurangnya aktivitas. Itu terjadi pada saya sekali jadi saya benar-benar mencoba untuk menghindari komitmen prematur atas nama komit sesegera mungkin .

— Giorgio
sumber

23

'Komit' bukan 'terbitkan'. 'Komit' berarti 'potret'; 'publish' disebut 'push' dalam scm-lingo. Tentu saja, SVN hanya menggabungkan kedua konsep menjadi satu, membuat banyak alur kerja yang masuk akal menjadi tidak mungkin, tetapi itu adalah keterbatasan alat, bukan alur kerja kontrol sumber secara umum.

— tdammers

3

Revision control and data backup are two different thingsYa, saya pasti merasakan hal ini.

— Kereta luncur

1

@tdammers: Maksud saya mempublikasikan secara informal: Selama kode ada di komputer saya itu adalah perubahan pribadi saya ke kode umum. Begitu saya komit, itu diterbitkan, diketahui oleh seluruh tim dan bagian dari sejarah proyek resmi.

— Giorgio

1

Kalau begitu, 'komit' mungkin kata yang salah. Banyak SCM mengizinkan komit lokal, dan membagikan kode Anda dengan anggota tim lainnya adalah tindakan terpisah, biasanya disebut 'push'. Sekali lagi, SVN menggabungkan dua konsep menjadi satu, tetapi itu adalah keterbatasan alat, dan jika itu menghalangi alur kerja Anda, pertimbangkan untuk beralih ke SCM yang berbeda.

— Pelaku

@tdammers: Untuk memiliki perbedaan yang jelas antara komit lokal dan publikasi akan menjadi langkah maju. Di SVN saya bisa menggunakan cabang terpisah untuk itu. Tetapi sekali lagi, saya bertanya-tanya mengapa saya ingin melacak revisi yang tidak masuk akal bagi saya? Saya tidak yakin bahwa saya ingin revisi baru (bahkan yang pribadi) hanya karena jam 5 'dan saya pulang. Saya lebih suka memiliki cadangan sebagai gantinya.

— Giorgio

107

Saya melakukan kode beberapa kali sehari . Setiap kali saya mencapai titik di mana kode tersebut cukup lengkap untuk dikompilasi dan tidak merusak hal-hal lain, itu masuk.

Anda harus mempertimbangkan untuk memecah pekerjaan Anda sehingga Anda dapat dengan aman check-in beberapa kali sehari.

Alasan untuk ini adalah dua:

Pekerjaan apa pun yang tidak dicentang mungkin hilang - komputer Anda mungkin mengalami kegagalan besar. Dalam hal ini, semakin lama Anda menunggu, semakin banyak pekerjaan yang hilang.
Semakin banyak pekerjaan yang Anda lakukan tanpa memeriksa, semakin banyak kode lain yang perlu diintegrasikan ketika Anda akhirnya memutuskan bahwa itu dibuat. Ini memperkenalkan lebih banyak peluang konflik dan menggabungkan masalah.

— Oded
sumber

2

Jika Anda memiliki masalah serius dengan konflik dan menggabungkan masalah, itu artinya manajer proyek Anda tidak melakukan tugasnya. Banyak kasus yang melibatkan fungsi serupa harus dimiliki oleh pengembang yang sama, sehingga Anda tidak memiliki dua atau lebih coder yang saling menginjak-injak.

— Mason Wheeler

14

@MasonWheeler - Setelah 3 hari kerja yang belum dilakukan, ada kemungkinan yang sangat baik bahwa seseorang telah menyentuh kode yang dimiliki orang lain pada saat yang sama. Jika Anda memiliki sekelompok programmer melakukan ini, acara manajer proyek terbaik tidak dapat menghindari konflik terjadi.

— Oded

3

@ Oded: Mungkin. Saya kira tanggapan saya diwarnai oleh pengalaman saya pada basis kode yang cukup besar sehingga pengembang kami (sekitar selusin coder dalam tim) semuanya cenderung memiliki tanggung jawab yang tidak tumpang tindih. Tidak yakin seberapa berbedanya dengan proyek yang lebih kecil.

— Mason Wheeler

3

@ ArtB - Bagaimana jika ada orang seperti Anda yang hanya memeriksa setiap 3 hari? Atau seminggu sekali? Anda mengandalkan orang lain melakukan hal yang benar.

— Oded

3

Ketika saya membaca pertanyaan, tanggapan saya adalah "apakah itu seperti bertanya apakah itu ide yang baik untuk mandi setiap minggu"?

— Andrew Grimm

39

Berpegang teguh pada metodologi atau praktik apa pun tanpa memahami alasan di baliknya tidak pernah merupakan ide yang baik. Di situlah pemrograman kargo-kultus berasal.

Karena itu, "Saya harus berkomitmen setiap hari karena Martin Fowler berkata begitu" adalah hal yang bodoh. Dan terkadang itu juga tidak praktis. Jika Anda mengerjakan fitur baru yang rumit, Anda mungkin tidak akan mencapai titik di mana layak untuk dicek sampai Anda telah mengerjakannya selama beberapa hari.

Ini tidak berarti Anda harus memastikan semuanya sempurna sebelum memeriksanya. Itu cara yang baik untuk kehilangan pekerjaan jika terjadi kesalahan. Hal yang benar untuk dilakukan adalah mengembangkan dan menggunakan penilaian yang baik tentang masalah tersebut. Aturan praktis hanya bisa sangat membantu Anda.

— Mason Wheeler
sumber

1

Maka jika itu adalah integrasi / pengembangan fitur yang kompleks, masih besar kerugian untuk tidak melakukannya, mungkin tidak ke trunk, tetapi setidaknya di cabang untuk fitur ini, itulah gunanya cabang!

— Vincent B.

2

Apa maksud Anda 'layak check-in'? Jika tidak merusak kode orang lain, mengapa Anda tidak memeriksanya?

— Kirk Broadhurst

2

"Apa maksudmu 'layak check-in'? Jika tidak melanggar kode orang lain, mengapa Anda tidak memeriksanya?": Karena saya tidak ingin menyimpan salinan kode yang lama hanya karena mereka ada di beberapa titik waktu. Saya juga ingin menyimpan salinan kode lama jika berisi beberapa informasi berguna yang mungkin ingin saya ambil di masa depan. Kalau tidak, saya hanya menghasilkan suara yang tidak berguna dalam sejarah revisi.

— Giorgio

3

+1. Saya pernah bekerja di tim di mana kami harus memeriksa kode ke vcs setiap hari, bahkan jika kode itu lonjakan atau penyelidikan yang tidak berguna. Itu terbukti tidak efisien dan boros, terutama karena itu memerlukan pemeliharaan berkala untuk membersihkan vcs. Itu karena kombinasi paranoia atas risiko kehilangan sedikit waktu untuk mengulang sesuatu, dan karena manajer telah membaca dalam sebuah buku yang harus Anda lakukan setiap hari. Contoh ekstrem mungkin, tetapi serius, jika Anda tidak memiliki penilaian untuk mengetahui apakah itu "layak" memeriksa sesuatu, Anda mungkin tidak cocok dengan pekerjaan itu.

— S.Robins

14

Oded memberi dua alasan penting untuk melakukan kode sesering mungkin. Saya akan menambahkan beberapa lagi:

Saat mengerjakan bagian kode Anda, yang lain mungkin memerlukan beberapa fungsi pada kode itu. Mereka seharusnya tidak menunggu 6 hari untuk mendapatkannya. Dalam hal ini kolega saya biasanya membuat prototipe di bagian kode saya, komit, saya tambahkan tubuh dan komit lagi. Dan ini biasanya dilakukan dalam beberapa jam.
Kode 'umum' adalah untuk semua orang melihat setiap perubahan secepat mungkin. Jika potongan kode yang Anda kerjakan benar-benar terpisah dari pekerjaan orang lain dan Anda tidak akan meminta mereka menunggu, maka disarankan untuk membuat cabang untuk Anda kerjakan, dan kemudian, jika semuanya berhasil, gabungkan menjadi jalur utama.

— superM
sumber

1

Mengapa jawaban ini dengan (IMO) satu-satunya jawaban yang benar dan akurat (poin 2) berperingkat rendah ?! Tentu saja itu titik cabang! @Mason Wheeler: Jadi Anda menikmati pengkodean beberapa hari secara mentah tanpa melakukan satu kali pun? Lalu mengapa menggunakan sistem kontrol versi ?!

— Vincent B.

2

Ini jawaban yang benar. Jika tugas Anda adalah beberapa hari kerja sebelum dapat digunakan, maka cabang. Kalau tidak, Anda berkomitmen kapan pun itu berfungsi untuk memastikan bahwa anggota tim memiliki versi terbaru, mereka dapat menguji apakah itu berfungsi, dan mereka mengidentifikasi fitur yang ditambahkan / hilang SECEPATNYA.

— Kirk Broadhurst

"Jadi, Anda menikmati pengkodean beberapa hari secara mentah tanpa melakukan satu waktu? Lalu mengapa menggunakan sistem kontrol versi?!": Karena pada akhirnya Anda ingin melakukan revisi, meskipun Anda tidak dipaksa untuk melakukan komitmen buta setiap hari. Sebaliknya, itu terserah Anda untuk memutuskan apakah Anda melakukan beberapa kali sehari atau Anda bekerja tiga hari berturut-turut tanpa komitmen. Saya benar-benar tidak melihat gunanya melakukan beberapa fitur yang belum selesai yang tidak dapat digunakan oleh siapa pun: cukup buat cadangan, hari berikutnya Anda bisa menyelesaikannya dan melakukannya.

— Giorgio

8

Saya sangat percaya dalam melakukan setiap perubahan logis yang layak dijaga. Berkomitmen sering, dan jika kode tidak layak disimpan, kembalikan ke keadaan bersih. Semakin lama Anda menunggu untuk mendorong / mempublikasikan kode Anda kembali, semakin sulit untuk diterapkan, dan semakin banyak masalah yang akan Anda hadapi. Anda juga akan mendapatkan umpan balik tentang kontribusi Anda lebih cepat:

apakah mereka merusak bangunan?
Apakah Anda menduplikasi upaya anggota tim lain?
apakah kamu melakukan sesuatu yang salah?
atau apakah orang menunggu sesuatu dari Anda?

Perubahan kecil jauh lebih mudah untuk dikelola.

Juga, perlu dicatat perbedaan antara sistem kontrol versi yang berbeda. Beberapa, seperti Git (didistribusikan), akan memungkinkan Anda untuk melakukan dan mengendalikan seluruh riwayat Anda secara lokal, hanya mendorong ketika Anda siap untuk menerbitkan. Lainnya, seperti SVN (terpusat), akan menggabungkan dua langkah membuat komitmen kecil sangat tidak efisien.

Jangan lupa bahwa komit Anda pada dasarnya mengubah dokumentasi. Ketika ada yang salah, Anda akan senang memiliki lebih banyak sejarah daripada tidak cukup. Satu komitmen untuk pekerjaan minggu tampaknya tidak berguna bagi saya. Saya baru saja berakhir membaca setiap baris kode berubah daripada ringkasan setiap potongan logis.

— Adrian Schneider
sumber

5

Saya pikir sebagian besar jawaban di sini melewatkan salah satu poin utama dalam pernyataan Martin Fowlers. Ini terkait dengan Integrasi Berkelanjutan . Kode yang tidak dicentang (didorong / dipublikasikan / digabungkan) ke jalur utama tidak diuji.

Ini tidak boleh dibaca sebagai dorongan untuk melakukan kode apa pun yang Anda miliki di mesin lokal Anda kapan pun saatnya meninggalkan kantor. Seperti yang ditunjukkan oleh beberapa orang lain di sini bahwa itu akan menjadi buruk, akan merusak bangunan dan menyebabkan arus utama tidak stabil.

Namun, merupakan dorongan untuk mencoba membuat perubahan Anda dalam langkah-langkah kecil yang dapat diperiksa ke jalur utama tanpa menyebabkan masalah. Ini mendorong evolusi kode alih-alih merobeknya dan menulis ulang.

Sekarang, apa gunanya cara kerja ini?

Tidak melakukan potongan kode besar atau perubahan revolusioner mengurangi peluang untuk merusak build.
Jika komit Anda merusak build, cukup sepele untuk mengidentifikasi apa masalahnya, untuk mengembalikannya dan kemudian melakukan versi perbaikan dengan cepat.
Dengan memastikan semua tes berjalan pada setiap perubahan kecil dalam kode, Anda memastikan bahwa Anda tidak memperkenalkan bug atau regresi halus yang dapat muncul karena kode tumbuh di luar skema integrasi berkelanjutan.

Tentu saja tidak semua perubahan mendukung pendekatan ini. Seperti yang ditunjukkan orang lain, tidak ada aturan yang mutlak. Namun, untuk perubahan yang diharapkan untuk tetap berada di luar jalur utama untuk waktu yang lama, buat jalur utama alternatif dengan skema integrasi berkelanjutannya sendiri dan ikuti pendekatan yang sama ke arah itu. Dengan VCS yang didistribusikan hari ini, hal itu cukup mudah dilakukan.

— Harald
sumber

+1: "Tentu saja tidak semua perubahan cocok untuk pendekatan ini." Saya pikir inilah intinya. Saya menemukan saran Fowler baik-baik saja, tetapi orang harus menilai dari kasus ke kasus. Sebaliknya, saran ini sering digeneralisasikan ke aturan absolut dan diikuti tanpa pertimbangan lebih lanjut.

— Giorgio

@Iorgio, saya sangat setuju dengan Anda tentang itu. Tidak ada saran yang harus diambil sebagai aturan absolut, tidak peduli siapa di belakangnya.

— Harald

Beberapa ide lagi tentang ini. "Kode yang tidak masuk (didorong / dipublikasikan / digabung) ke jalur utama tidak diuji.": Saya setuju bahwa ini adalah prinsip yang baik dan seseorang tidak harus menunggu berminggu-minggu sebelum check-in dan kode mereka diuji. Namun, aplikasi buta dari prinsip ini dapat menyebabkan aplikasi rusak yang bahkan tidak dapat diuji (saya telah melihat ini secara langsung: seluruh tim uji duduk diam selama berhari-hari dan tidak dapat menguji apa pun sampai kode tersebut dikembalikan ke keadaan yang dapat digunakan). Mungkin apa yang ditulis pengguna lain berlaku untuk beberapa situasi tetapi tidak secara umum.

— Giorgio

1

Memeriksa kode yang tidak stabil tidak pernah ok. Komit yang merusak CI harus dikembalikan. Jika Anda sering melakukan perubahan inkremental kecil, ada sedikit kesempatan untuk memperkenalkan kerusakan seperti itu daripada jika Anda memiliki perubahan besar yang tidak diuji dalam waktu yang lama. Mungkin juga lebih mudah untuk dikembalikan jika merusak bangunan. Tapi seperti yang Anda katakan, terkadang tidak ada cara di luar dari perubahan yang mengganggu. Kemudian dengan segala cara memolesnya sebaik mungkin, dan menguji secara menyeluruh sebelum melakukannya. Intinya bukan mengikuti aturan, tetapi memahami dari mana saran itu berasal.

— Harald

3

Argumen untuk check-in setiap hari:

Kode disimpan dan didukung terhadap kegagalan hard drive
Aktivitas dapat direkam dalam catatan komit ( apa yang saya lakukan pada hari Kamis ...? )
Integrasi dengan basis kode yang ada terjadi lebih awal dan dalam potongan yang lebih kecil, semoga mengidentifikasi konflik atau menggabungkan masalah lebih cepat
Tim Anda memiliki visibilitas dari apa yang telah Anda kerjakan
Kolega Anda dapat bekerja melawan antarmuka Anda lebih cepat, memberi mereka lebih banyak waktu untuk berintegrasi dengan 'kode kompleks Anda'
Kode Anda akan diuji di dunia nyata lebih cepat, atau setidaknya terkena lebih banyak penggunaan daripada yang Anda berikan, yang mengarah pada identifikasi bug atau kelalaian sebelumnya.

Argumen terhadap check-in setiap hari:

Tidak perlu atau tidak mau
Belum 'membersihkan' kode saya, ini berantakan
Tidak punya waktu

Saya tidak percaya ada alasan bagus untuk check in kurang dari setiap hari terlepas dari kemalasan atau kekacauan. Tidak ada yang lebih buruk daripada melihat kode yang berjalan di lingkungan pengembangan tidak cocok dengan kode di cabang pengembangan karena seseorang 'belum selesai' dan karenanya belum masuk.

Saya ingin salah dalam hal ini jadi tolong beri tahu saya argumen yang sah terhadap check-in harian.

— Kirk Broadhurst
sumber

"Saya tidak percaya ada alasan bagus untuk check in kurang dari setiap hari selain karena kemalasan atau kekacauan.": Saya percaya sebaliknya karena alasan yang persis sama. Saya dapat meluangkan waktu untuk melihat keadaan kode saat ini dan memutuskan apakah itu berisi beberapa informasi relevan yang perlu diingat, atau, jika saya malas dan tidak terorganisir, saya cukup memeriksanya (dan menghasilkan revisi tambahan dengan sedikit informasi konten) selama dikompilasi.

— Giorgio

1

Saya mengerti maksud Anda bahwa seseorang tidak boleh malas dan membersihkan kode mereka setiap hari sehingga dapat diperiksa. Di sisi lain, ketika mengerjakan beberapa kode kompleks, ini sulit dicapai karena pembersihan mungkin memakan waktu beberapa jam , dan Anda tidak dapat menghabiskan beberapa jam setiap hari hanya untuk membersihkan kode Anda.

— Giorgio

@Iorgio Jadi Anda menghabiskan beberapa hari membersihkan kode Anda? Saya telah memberikan beberapa alasan bagus untuk check-in setiap hari - alasan Anda adalah Anda harus membersihkan kode Anda? Cukup tulis kode bersih langsung.

— Kirk Broadhurst

Ini tidak selalu mungkin, misalnya jika saya mengembangkan dari awal beberapa kode kompleks (> 4000 LOC) yang memerlukan banyak percobaan untuk mendapatkan yang benar. Sangat mungkin bahwa pada akhir hari kodenya agak berantakan dan saya tidak ingin memperbaikinya sampai saya mencapai kondisi yang konsisten, yaitu beberapa hari kemudian. Sayangnya saya tidak begitu pintar sehingga selesai, bentuk kode sempurna dalam pikiran saya dan saya selalu dapat menuliskan semuanya dalam beberapa jam (yaitu pada akhir hari). Saya memiliki pengalaman seperti itu belakangan ini dan siklus pengembangan tipikal (dari satu keadaan konsisten ke berikutnya) adalah 2, 3 hari.

— Giorgio

@Iorgio apakah Anda tidak memiliki cabang pengembangan yang sedang Anda periksa? Kode harus diperiksa sehingga orang lain dapat meninjau dan mengujinya juga.

— Kirk Broadhurst

2

Jika Anda bermaksud "komit" sebagai "bergabung menjadi arus utama", maka Anda seharusnya tidak melakukan itu setiap hari pada proyek perangkat lunak yang dirilis ke pelanggan. Anda harus menggabungkan perubahan yang dilakukan dan diuji, sehingga garis utama selalu berfungsi dan dapat dirilis, dan tidak dalam kondisi rusak dengan fitur setengah jadi.

Namun, kemewahan bekerja dengan kontrol versi terdistribusi hari ini adalah bahwa Anda berdua dapat menjaga garis utama stabil, dan pada saat yang sama melakukan git/hg/whatever commitsetiap kali Anda merasa ingin mempertahankan keadaan. Saya melakukan ini sekali setiap beberapa jam dan pasti pada akhir setiap hari.

Dengan DVCS, Anda dapat mempublikasikan pekerjaan Anda, berkolaborasi dengannya dengan orang lain di tim Anda, dan tetap memperbarui dengan perubahan di cabang jalur utama. Anda dapat melakukan semua ini tanpa mencemari stabilitas kode yang diandalkan oleh pelanggan Anda dan / atau tim lain.

Pada saat Subversion adalah teknologi terbaru dan tidak ada cara untuk memotong dan menggabungkan cabang fitur tanpa rasa sakit yang luar biasa, memiliki garis utama di mana beberapa fitur berbeda dalam konstruksi simultan mungkin merupakan pendekatan terbaik. Tetapi superioritas ini tidak melampaui skala 2010.

— che
sumber

2

Di Team Foundation Server Anda dapat 'Shelve' yang tidak sama dengan check-in, tetapi hanya membuat cadangan kode Anda sehingga jika mesin Anda mati Anda tidak kehilangan perubahan.

Saya juga melihat rumah perangkat lunak yang memiliki 'garis pengembang' dan 'garis utama'. Pengembang bebas untuk masuk ke jalur pengembang kapan pun mereka anggap cocok dan hanya pemimpin tim yang memiliki akses ke jalur utama sehingga mereka bertanggung jawab untuk menyalin kode dari pengembang ke utama ketika sudah siap produksi.

— Matt Wilko
sumber