Mengapa semua orang menggunakan Git secara terpusat?


289

Saya telah menggunakan Git di dua perusahaan terakhir saya untuk kontrol versi. Tampaknya dari apa yang saya dengar bahwa sekitar 90% perusahaan menggunakan Git dibandingkan sistem kontrol versi lainnya.

Salah satu nilai jual terbesar dari Git adalah desentralisasi, yaitu semua repositori adalah sama; tidak ada pusat penyimpanan / sumber kebenaran. Ini adalah fitur yang diperjuangkan Linus Torvalds .

Tetapi tampaknya setiap perusahaan menggunakan Git secara terpusat, seperti halnya yang menggunakan SVN atau CVS. Selalu ada repositori pusat di server (biasanya di GitHub) yang orang tarik dan dorong. Saya belum pernah melihat atau mendengar tentang (dalam pengalaman saya yang diakui terbatas) orang menggunakan Git dengan cara yang benar-benar terdesentralisasi di mana ia dimaksudkan, yaitu mendorong dan menarik ke repositori rekan kerja lain yang mereka anggap cocok.

Pertanyaan saya adalah:

  1. Mengapa orang tidak menggunakan alur kerja terdistribusi untuk Git dalam praktiknya?
  2. Apakah kemampuan untuk bekerja secara terdistribusi bahkan penting untuk kontrol versi modern, atau apakah itu terdengar bagus?

Sunting

Saya menyadari bahwa saya tidak menemukan nada yang benar dalam pertanyaan awal saya. Kedengarannya seperti saya bertanya mengapa ada orang yang bekerja secara terpusat ketika sistem kontrol versi terdistribusi (DVCS) jelas lebih unggul. Sebenarnya, yang ingin saya katakan adalah, saya tidak melihat manfaat apa pun bagi DVCS . Namun saya sering mendengar orang mengabarkan keunggulannya, sementara dunia nyata tampaknya setuju dengan pandangan saya.


31
Saya merasakan hal yang persis sama, dan tidak mengerti ini.
Mengintip

57
Secara pribadi, saya tidak tahu ada kasus penggunaan untuk beberapa remote, selain garpu untuk membuat PRs ke remote utama. Hal yang didistribusikan masih berguna karena itu berarti saya mendapatkan riwayat lengkap pada mesin saya tanpa harus berbicara dengan jaringan, dan saya dapat melakukan beberapa pekerjaan offline jika saya benar-benar ingin, dan jauh lebih mudah untuk bermigrasi dari satu host repo online ke lain. Apa sebenarnya yang ada dalam pikiran Anda ketika Anda merujuk pada "alur kerja terdistribusi"?
Ixrec

43
Saya cukup yakin bahwa Torvalds sejak awal memiliki satu "sumber kebenaran" repositori Kernel Linux.
Steven Burnap

67
Pada akhirnya, perangkat lunak itu sendiri adalah terpusat. Pelanggan tidak membeli cabang atau remote, mereka membeli produk akhir, disatukan, dibangun. Selalu perlu ada jalan tengah ke depan.
Brandon

37
Bagi saya git "desentralisasi" adalah salah satu fitur paling tidak penting yang merekomendasikannya. Kemampuan untuk sering melakukan commit dan rollback secara lokal, tanpa memengaruhi orang lain, atau teknik hebat seperti rebasing adalah tempat git benar-benar bersinar dalam alur kerja saya. Mungkin (memang mungkin) bahwa semua ini dimungkinkan oleh desentralisasi, tetapi "D" dalam DVCS tidak begitu penting bagi saya.
Jay

Jawaban:


257

Ahh, tapi sebenarnya Anda sedang menggunakan git secara desentralisasi!

Mari kita bandingkan pendahulu git di mindshare, svn. Subversi hanya memiliki satu "repo", satu sumber kebenaran. Ketika Anda melakukan komit, itu untuk repo tunggal pusat, yang juga dilakukan oleh setiap pengembang lainnya.

Jenis pekerjaan ini berhasil, tetapi menyebabkan banyak masalah, yang terbesar adalah konflik gabungan yang ditakuti . Ini ternyata ada di mana saja dari menjengkelkan ke mimpi buruk untuk menyelesaikan. Dan dengan satu sumber kebenaran, mereka memiliki kebiasaan buruk untuk menghentikan pekerjaan semua orang sampai mereka terselesaikan. Menggabungkan konflik tentu ada dengan git, tetapi itu bukan kejadian yang menghentikan pekerjaan dan jauh lebih mudah dan lebih cepat untuk diselesaikan; mereka umumnya hanya memengaruhi pengembang yang terlibat dengan perubahan yang bertentangan, bukan semua orang.

Lalu ada seluruh titik kegagalan, dan masalah yang menyertainya. Jika repo pusat svn Anda mati, Anda semua kacau sampai dapat dikembalikan dari cadangan, dan jika tidak ada cadangan, Anda semua kacau dua kali lipat. Tetapi jika git repo "sentral" mati, Anda dapat memulihkan dari cadangan, atau bahkan dari salah satu salinan repo lain yang ada di server CI, workstation pengembang, dll. Anda dapat melakukan ini dengan tepat karena didistribusikan, dan setiap pengembang memiliki salinan repo kelas satu.

Di sisi lain, karena repo git Anda adalah repo kelas satu dengan haknya sendiri, ketika Anda berkomitmen, komit Anda pergi ke repo lokal Anda. Jika Anda ingin membaginya dengan orang lain, atau ke sumber kebenaran pusat, Anda harus secara eksplisit melakukan ini dengan mendorong ke remote. Pengembang lain kemudian dapat menarik ke bawah perubahan itu ketika nyaman bagi mereka, daripada harus memeriksa svn terus-menerus untuk melihat apakah seseorang melakukan sesuatu yang akan mengacaukannya.

Fakta bahwa, alih-alih mendorong langsung ke pengembang lain, Anda mendorong perubahan ke mereka secara tidak langsung melalui repo jarak jauh lain, tidak terlalu menjadi masalah. Bagian penting dari perspektif kami adalah salinan lokal repo Anda adalah repo sendiri. Dalam svn, sumber kebenaran sentral ditegakkan oleh desain sistem. Dalam git, sistem bahkan tidak memiliki konsep ini; jika ada sumber kebenaran, itu diputuskan secara eksternal.


15
Penggabungan SVN juga hanya memengaruhi pengembang yang terlibat dengan perubahan yang bertentangan. Satu komit berhasil masuk ke dalam repo, tidak ada penggabungan yang bertentangan dapat masuk ke dalam repo hingga konflik diselesaikan (Anda juga dapat melakukan komit secara paralel dengan cabang / jalur terpisah, tetapi itu tidak benar-benar bertentangan sekarang bukan?)
Ben Voigt

30
Saya menemukan perbedaan utama, ketika server pusat ada, yaitu bahwa GIT memungkinkan versi lokal yang sedang berlangsung saat jaringan sedang down, dan SVN tidak (beberapa sistem kontrol versi lainnya bahkan lebih buruk, dan menghentikan semua pekerjaan ketika jaringan tidak dapat dijangkau. , karena mereka tidak membiarkan Anda mengubah file sampai Anda memeriksanya).
Ben Voigt

17
@ BenVoigt Oh, ini sudah berhenti. Ingat Anda harus svn upup to date dengan repo sebelum Anda dapat check-in. Ketika orang lain terus memeriksa saat Anda sedang mencoba untuk menyelesaikan menggabungkan konflik, dan memberikan lain set menggabungkan konflik ... Anda baik menghentikan bahwa atau Anda kehilangan apa yang tersisa dari kewarasan Anda.
Michael Hampton

21
Tidak, orang-orang pasti dapat terus berkomitmen ke cabang tempat Anda menggabungkan perubahan, tanpa mengganggu alur kerja Anda.
Ben Voigt

29
Ben benar. Repo SVN dikelola dengan benar , dan digunakan oleh tim yang telah dididik dengan baik tentang cara mengembangkan perangkat lunak, seharusnya tidak pernah memiliki konflik yang menggabungkan pada trunk. Anda hanya akan mendapatkannya ketika seseorang melakukan kesalahan dan perlu dipecat (: P). inb4 lebih mudah ketika Anda tidak harus mendidik orang bagaimana menggunakan alat mereka. Ya, ada banyak hal untuk diajarkan tentang Git daripada tentang SVN!
Lightness Races dalam Orbit

118

Ketika Anda membangun server (Anda sedang menggunakan CI, kan?) Menciptakan membangun, mana itu menarik dari? Tentu, membangun integrasi yang Anda dapat berargumen tidak perlu "satu repo yang benar" tetapi pasti membangun distribusi (yaitu apa yang Anda berikan kepada pelanggan).

Dengan kata lain: fragmentasi. Jika Anda menetapkan satu repo sebagai "repo" dan menunjuk wali yang memeriksakan permintaan, Anda memiliki cara mudah untuk memenuhi permintaan "beri saya perangkat lunak" atau "Saya baru di tim, di mana kodenya?"

Kekuatan DVCS bukan terletak pada aspek peer-to-peer, tetapi fakta bahwa itu adalah hierarkis . Saya memodifikasi ruang kerja saya, lalu saya komit ke lokal. Setelah saya memiliki fitur yang lengkap, saya menggabungkan komit saya dan mendorong mereka ke remote saya. Lalu siapa pun dapat melihat kode sementara saya, memberikan umpan balik, dll. Sebelum saya membuat permintaan tarik dan admin proyek menggabungkannya ke dalam repo One True.

Dengan CVCS tradisional Anda berkomitmen atau tidak. Itu bagus untuk beberapa alur kerja (saya menggunakan kedua jenis VCS untuk proyek yang berbeda), tetapi jatuh pada wajahnya untuk proyek publik atau OSS. Kuncinya adalah DVCS memiliki beberapa langkah, yang lebih banyak berfungsi, tetapi memberikan cara yang lebih baik untuk mengintegrasikan kode dari orang asing melalui proses bawaan yang memungkinkan visibilitas yang lebih baik ke dalam apa yang sedang diperiksa. Menggunakannya secara terpusat berarti Anda masih bisa memiliki standar emas dari keadaan proyek saat ini sambil juga menyediakan mekanisme pembagian kode yang lebih baik.


2
Secara keseluruhan jawaban yang bagus, tapi saya cukup yakin bahwa Git digunakan secara luas sebelum Continuous Integration; Ngomong-ngomong, tim kami menggunakan CI, terima kasih sudah memeriksa: D.
gardenhead

5
@gardenhead: Anda melewatkan intinya: argumen yang sama berlaku jika seseorang membangun integrasi secara manual. "CI" hanyalah otomatisasi untuk proses yang jauh lebih tua dari Git.
Doc Brown

25
"siapa pun dapat melihat kode tentatif saya" - dan mereka juga dapat menarik kode tentatif Anda, menggabungkannya dengan kode tentatif mereka, dan menjalankan tes. Ini adalah rasa sakit di VCSes terpusat, karena memerlukan cabang dan perubahan dalam One True Copy. Didistribusikan, Anda hanya mengkonfigurasi remote tambahan, lalu mulai menggabungkan, menambal, dan memetik ceri. Anda telah melacak apa yang telah Anda lakukan tetapi tidak ada orang lain yang pernah melihat apa yang Anda inginkan kecuali Anda memilih untuk mempublikasikannya. Secara umum saya merekomendasikan tidak ada yang harus menyatakan DVCS sia-sia sampai mereka benar-benar menggunakan SVN untuk proyek besar ...
Steve Jessop

9
Karena tidak ada "one true build" dari kernel linux. Karena semua orang membangunnya sendiri, repo Linus tidak lebih kanonik daripada yang lainnya. Jika Anda menjual produk yang tidak berfungsi dengan baik.
Miles Budnek

2
@Superbest: banyak (jika tidak semua) desain git berbasiskan Bitkeeper. Git dibuat setelah kontroversi linux-bitkeeper meledak.
whatsisname

40

Saya tidak tahu bagaimana Anda mendefinisikan "semua orang", tetapi tim saya memiliki "repo sentral di server" dan juga dari waktu ke waktu kami menarik dari repo kolega lain tanpa melalui repo pusat itu. Ketika kita melakukan ini, kita masih pergi melalui server, karena kita memilih untuk tidak mengirim email tentang tempat itu, tetapi tidak melalui repo pusat. Ini umumnya terjadi ketika suatu kelompok berkolaborasi pada fitur tertentu dan ingin tetap up to date dengan satu sama lain, tetapi belum tertarik untuk menerbitkan fitur tersebut kepada semua orang. Tentu saja karena kami bukan pekerja silo yang tertutup, situasi itu tidak berlangsung lama, tetapi DVCS memberikan fleksibilitas untuk melakukan apa pun yang paling nyaman. Kami dapat menerbitkan cabang fitur atau tidak sesuai selera.

Tapi 90% lebih dari waktu, tentu, kami pergi melalui repo pusat. Ketika saya tidak peduli dengan perubahan tertentu atau pekerjaan kolega tertentu itu lebih mudah, dan itu skala yang lebih baik, untuk menarik "semua perubahan kolega saya yang telah diperiksa dalam repo pusat", daripada secara terpisah menarik perubahan dari masing-masing N kolega. DVCS tidak mencoba untuk mencegah "pull from main repo" menjadi alur kerja yang paling umum, itu mencoba untuk mencegahnya menjadi satu-satunya alur kerja yang tersedia.

"Terdistribusi" berarti bahwa semua repo secara teknis setara sejauh menyangkut gitperangkat lunak, tetapi tidak berarti bahwa semua repo memiliki arti yang sama sejauh menyangkut pengembang dan alur kerja kami. Ketika kami merilis ke klien atau ke server produksi, repo yang kami gunakan untuk melakukan itu memiliki arti yang berbeda dari repo yang hanya digunakan oleh satu pengembang di laptop mereka.

Jika "benar-benar desentralisasi" berarti "tidak ada repo khusus" maka saya tidak berpikir itu yang Linus berarti juara, mengingat bahwa dalam kenyataannya ia tidak mempertahankan repo khusus yang berada lebih penting dalam skema besar hal, daripada beberapa tiruan acak dari Linux yang saya buat kemarin dan berencana untuk digunakan hanya untuk mengembangkan beberapa tambalan kecil dan kemudian menghapusnya begitu dia menerima tambalan tersebut. gittidak istimewa repo di atas saya, tapi Linus tidak istimewa itu. "Nya adalah kondisi Linux saat ini", milikku tidak. Jadi secara alami perubahan cenderunguntuk pergi melalui Linus. Kekuatan DVCS atas VCS terpusat bukanlah bahwa tidak boleh ada pusat de facto, itu adalah bahwa perubahan tidak harus melalui pusat apa pun karena (konflik mengizinkan) siapa pun dapat menggabungkan apa pun.

Sistem DVCS juga dipaksakan , karena terdesentralisasi, untuk menyediakan fitur nyaman tertentu berdasarkan fakta bahwa Anda harus memiliki riwayat lengkap (yaitu repo) secara lokal untuk melakukan apa pun. Tetapi jika Anda memikirkannya, tidak ada alasan mendasar mengapa Anda tidak dapat mengonfigurasi VCS terpusat dengan cache lokal yang membuat seluruh riwayat operasi read-only diizinkan kedaluwarsa (saya pikir Perforce memiliki opsi untuk mode ini, tapi saya tidak pernah menggunakan Perforce). Atau pada prinsipnya Anda dapat mengkonfigurasi gitdengan Anda.git/direktori pada sistem file yang dipasang jarak jauh untuk meniru "fitur" dari SVN yang tidak berfungsi ketika Anda tidak memiliki koneksi jaringan. Akibatnya, DVCS memaksa pipa ledeng menjadi lebih kuat daripada yang bisa Anda dapatkan dengan VCS terpusat. Ini adalah efek samping (sangat disambut) dan membantu memotivasi desain DVCS, tetapi distribusi tanggung jawab di tingkat teknis ini tidak sama dengan desentralisasi penuh semua tanggung jawab manusia .


7
Mereka secara teknis setara, tidak setara secara sosial .
curiousdannii

3
Email tambalan cukup menyakitkan, kalau-kalau ada orang yang mempertimbangkannya, gunakan saja git format-patch dan kemudian git kirim-email . Apakah itu ketika saya tidak ingin bermain-main dengan kontrol akses Github dan itu sangat mudah, semua orang memiliki email.
Rudolf Olah

1
"tentu harus memiliki riwayat lengkap [...] secara lokal untuk melakukan apa pun" - tidak benar; DSCMs modern mendukung repositori parsial ("cek dangkal" dalam istilah bzr, "klon dangkal" dalam istilah git).
Charles Duffy

27

Hal yang menarik tentang sifat DVCS, adalah jika orang lain menggunakannya secara terdistribusi, Anda mungkin tidak akan mengetahuinya kecuali mereka berinteraksi langsung dengan Anda. Satu-satunya hal yang dapat Anda katakan secara pasti adalah bahwa Anda dan rekan tim langsung Anda tidak menggunakan git dengan cara ini. Ini tidak memerlukan kebijakan di seluruh perusahaan. Jadi saya akan bertanya, mengapa Anda tidak menggunakan git secara desentralisasi?

Untuk mengatasi hasil edit Anda, mungkin Anda perlu beberapa pengalaman bekerja dengan kontrol versi terpusat yang sebenarnya untuk menghargai perbedaan, karena meskipun mereka tampak halus, mereka meresap. Ini semua adalah hal yang sebenarnya dilakukan oleh tim saya di tempat kerja yang tidak dapat kami lakukan ketika kami memusatkan VCS:

  • Memiliki daftar pengembang inti yang sangat kecil dengan akses komit ke repo "pusat" untuk setiap layanan mikro. Semua orang dapat mengerjakan fork dan mengirimkan melalui permintaan tarik.
  • Dapat melakukan jauh lebih sering, biasanya beberapa kali per jam dibandingkan sekali atau dua kali per hari.
  • Dapat membuat cabang dengan alasan apa pun untuk berkoordinasi sementara dengan rekan kerja, dan mendorongnya dan menariknya beberapa kali per hari, lalu remas ketika siap untuk berbagi dengan grup yang lebih besar. Apakah Anda tahu betapa sulitnya mendapatkan izin untuk membuat cabang sementara untuk sesuatu seperti ini di CVCS tradisional?

Dengan risiko terdengar tua karena mengatakannya, Anda benar-benar tidak tahu betapa mudahnya Anda memilikinya.


1
Pertanyaan betapa sulitnya membuat cabang di CVCS tradisional sepenuhnya tergantung pada kebijakan: Saya kebetulan bekerja dengan repo SVN hulu (tentu saja melalui klon git-svn!), Dan saya memiliki hak untuk membuat cabang apa pun yang saya miliki. ingin, meskipun itu proyek yang cukup besar. Saya hanya tidak diizinkan menyentuh sejumlah cabang integrasi yang ditunjuk, apalagi bagasi, tanpa berbicara dengan atasan saya terlebih dahulu. Perusahaan lain mungkin memiliki kebijakan lain yang mungkin lebih ketat, tetapi tentu saja tidak harus.
cmaster

7
Anda benar, saya tidak tahu betapa mudahnya saya memilikinya. Saya berharap saya telah ada di masa dominasi SVN untuk menghargai seberapa jauh kita telah datang. Sebagai pengembang perangkat lunak yang sangat muda, saya menemukan pola yang sama ini cukup sering diulang: para dev yang lebih berpengalaman memberi tahu saya bahwa cara lama dalam melakukan sesuatu itu buruk, dan cara / teknologi baru ini jauh lebih mudah. Tetapi saya hanya harus mengambil kata mereka untuk itu; Saya tidak pernah bisa benar-benar menghargai kelebihannya. Saya selalu merasa disonansi ini sulit diatasi.
gardenhead

1
@gardenhead Anda selalu dapat membuat repo SVN Anda sendiri dan mencoba untuk memecahkannya;) (dan perhatikan betapa sulitnya daripada membuat git repo dan kloning itu ...) - Satu fitur utama lain yang saya perhatikan (setidaknya di lingkungan korporat khususnya) adalah bahwa file sharing agak canggung, atau itu dilakukan sedemikian rupa sehingga menumpuk repositori (karena pemindai virus mengunci pada drive jaringan, misalnya).
Wayne Werner

4
@ardenhead: baiklah, anggap diri Anda beruntung karena Anda tidak terjebak dalam proyek warisan, dengan pengembang perangkat lunak lama yang memberi tahu Anda cara lama dalam melakukan sesuatu baik-baik saja ... kadang-kadang Anda tidak dapat membantu tetapi merasa mereka hanya senang mereka tidak perlu mempelajari teknologi baru!
leftaroundabout

1
@gardenhead rupanya proyek sedang dirilis pada tingkat yang cukup gila. Kemampuan untuk terus belajar diperlukan jika Anda ingin dapat menemukan pekerjaan yang luar biasa.
Wayne Werner

19

Saya pikir pertanyaan Anda berasal dari pola pikir (dimengerti) selalu terhubung . yaitu server ci 'kebenaran' pusat selalu (atau dekat selalu) tersedia. Walaupun ini benar di sebagian besar lingkungan, saya telah bekerja di setidaknya satu yang jauh dari ini.

Sebuah proyek Simulasi Militer yang tim saya kerjakan beberapa tahun lalu. Semua kode (Kita berbicara dengan basis kode> US $ 1b) harus (berdasarkan hukum / perjanjian internasional, laki-laki berjas gelap datang jika Anda tidak) berada di mesin yang secara fisik terisolasi dari koneksi Internet apa pun . Ini berarti situasi yang biasa kita masing-masing memiliki 2 PC, satu untuk menulis / menjalankan / menguji kode, yang lain untuk hal-hal Google, memeriksa Email dan semacamnya. Dan ada jaringan lokal di dalam tim mesin-mesin ini, jelas tidak dengan cara apa pun terhubung ke Internet.

"Sumber kebenaran pusat" adalah sebuah mesin di pangkalan militer, di sebuah ruangan tanpa jendela semua-cinderblock bawah tanah (gedung bertulang, yada-yada). Mesin itu juga tidak memiliki koneksi internet.

Secara berkala, itu akan menjadi tugas seseorang untuk mengangkut (secara fisik) berkendara dengan git repo (berisi semua perubahan kode kami) ke pangkalan militer - yang berjarak beberapa ratus kilometer jauhnya, jadi, dapat Anda bayangkan.


Selain itu, dalam sistem yang sangat besar di mana Anda memiliki banyak tim. Mereka umumnya masing-masing akan memiliki repo "sentral" mereka sendiri, yang kemudian kembali ke repo sentral "sentral" yang sebenarnya. Saya tahu setidaknya 1 kontraktor lain yang melakukan git repo dasbor hard-drive yang sama dengan kode mereka juga.

Juga, jika Anda mempertimbangkan sesuatu pada skala kernel Linux ... Pengembang tidak hanya mengirim permintaan tarik ke Linus sendiri. Ini pada dasarnya adalah hierarki repo - yang masing-masing adalah "sentral" bagi seseorang / beberapa tim.

Sifat terputus dari git berarti dapat digunakan di lingkungan di mana alat kontrol sumber model yang terhubung ( yaitu SVN, untuk satu) tidak dapat digunakan - atau tidak dapat digunakan dengan mudah.


3
Saya anggota Mile High (Software) Club - Saya telah membuat kode pada ketinggian 35.000 kaki. Tentu, pesawat memiliki Wifi sekarang , tapi itu tidak selalu terjadi. Dan senang mengetahui bahwa setidaknya jika kita crash ada kemungkinan bahwa tim saya akan mendapatkan kode saya utuh.
Wayne Werner

@ WalkneWerner itu benar. Saya telah berpikir tentang menyediakan beberapa situasi yang lebih umum di mana tidak mungkin untuk selalu dekat. Misalnya di pesawat, berlayar di laut, stasiun luar angkasa, tempat-tempat terpencil di Afrika, dll.
Tersosauros

18

Pada akhirnya, Anda sedang membangun suatu produk. Produk ini mewakili kode Anda pada satu titik waktu. Karena itu, kode Anda harus menyatu di suatu tempat . Titik alami adalah server ci atau server pusat dari mana produk dibangun, dan masuk akal bahwa titik pusat ini adalah repositori git.


14

Aspek terdistribusi dari DVCS muncul dalam pengembangan sumber terbuka sepanjang waktu, dalam bentuk forking. Sebagai contoh, beberapa proyek yang saya berkontribusi ditinggalkan oleh penulis asli dan sekarang memiliki banyak percabangan di mana pengelola terkadang menarik fitur tertentu dari satu sama lain. Bahkan secara umum, proyek OSS mengambil kontribusi dari luar melalui permintaan tarik, bukan dengan memberikan orang secara acak mendorong akses ke repo ground-truth.

Ini bukan kasus penggunaan yang sangat umum ketika membangun produk konkret dengan rilis resmi spesifik, tetapi di dunia F / OSS itu adalah norma, bukan pengecualian.


4
Itu adalah jawaban yang tepat, juga dari sudut pandang historis. Kernel Linux telah memiliki beberapa repositori sumber untuk waktu yang lama (disebut "pohon" oleh pengembang, seperti "pohon Linus" atau "pohon Andrew"). Linux menginginkan sesuatu untuk mendukung jenis pengembangan terdistribusi ketika ia mengembangkan git.
sleske

@Luaan Setelah memikirkan hal ini sebentar, saya sadar Anda benar. Saya telah mengubah kata-katanya sedikit - apakah ini menangkap perbedaan sedikit lebih baik?
fluffy

@luffy Kedengarannya bagus untuk saya;)
Luaan

9

Mengapa semua orang menggunakan git secara terpusat?

Kami belum pernah bertemu, bagaimana bisa Anda mengatakan semua orang? ;)

Kedua, ada lebih banyak fitur lain yang Anda temukan di Git tetapi tidak di CVS atau SVN. Mungkin hanya Anda dengan asumsi bahwa ini harus menjadi satu - satunya fitur untuk semua orang .

Tentu banyak orang dapat menggunakannya secara terpusat seperti CVS atau SVN. Tapi jangan lupa fitur lain yang secara inheren datang dengan VCS yang terditribusi: semua salinan lebih atau kurang "lengkap" (semua cabang dan riwayat lengkap tersedia) dan semua cabang dapat diperiksa tanpa terhubung ke server.

Saya berpendapat ini adalah fitur lain yang tidak boleh dilupakan.

Meskipun Anda tidak dapat melakukan ini dengan CVS dan SVN di luar kotak, Git dapat digunakan secara terpusat seperti yang sebelumnya tanpa masalah.

Jadi saya bisa melakukan perubahan saya, mungkin squash work-in-progress melakukan bersama, lalu mengambil dan memulai kembali pekerjaan saya ke cabang pengembangan utama.

Fitur lain yang keluar dari kotak dengan Git:

  • tanda kriptografi berkomitmen
  • rebasing (menyusun ulang dan squash melakukan; mengedit melakukan, bukan hanya pesan)
  • memetik ceri
  • membagi dua sejarah
  • cabang lokal dan perubahan simpanan (disebut "rak" di Wikipedia)

Lihat juga tiga tabel ini di Wikipedia - Perbandingan perangkat lunak kontrol versi :

Jadi sekali lagi, mungkin cara yang terdesentralisasi bukan hanya fitur yang membuat orang menggunakannya.

  1. Mengapa orang tidak menggunakan alur kerja terdistribusi untuk Git dalam praktiknya?

Siapa pun yang berkontribusi atau meng-hosting proyek yang lebih besar di Bitbucked, GitHub dll. Akan melakukannya dengan tepat. Para pengelola menyimpan repositori "utama", klon kontributor, melakukan dan kemudian mengirimkan permintaan penarikan.

Di perusahaan, bahkan dengan proyek atau tim kecil, alur kerja terdistribusi adalah pilihan ketika mereka melakukan outsourcing modul dan tidak ingin eksternal untuk memodifikasi cabang pengembangan suci tanpa perubahan mereka ditinjau sebelumnya.

  1. Apakah kemampuan bekerja secara terdistribusi bahkan penting untuk kontrol versi modern, ...

Seperti biasa: itu tergantung pada persyaratan.

Gunakan VCS terdesentralisasi jika ada poin yang berlaku:

  • ingin mengkomit atau menavigasi riwayat secara offline (mis. menyelesaikan submodule di kabin gunung selama liburan)
  • menyediakan repo sentral tetapi ingin memisahkan repositori "yang sebenarnya" untuk meninjau perubahan (mis. untuk proyek besar atau tim yang didistribusikan)
  • ingin memberikan (salinan) seluruh sejarah dan cabang sesekali sambil mencegah akses langsung ke repo pusat (mirip dengan yang kedua)
  • ingin versi sesuatu tanpa harus menyimpan yang jauh atau menyiapkan repositori khusus (terutama dengan Git hanya git init .akan cukup untuk siap untuk versi sesuatu)

Ada beberapa lagi tetapi empat sudah cukup.

... atau apakah itu terdengar bagus?

Tentu saja kedengarannya bagus - untuk pemula.


Bukankah SVN mendapat keuntungan svn initdi beberapa titik?
immibis

5

Fleksibilitas adalah kutukan sekaligus berkah. Dan seperti Git sangat fleksibel, hampir selalu jauh terlalu fleksibel untuk situasi khas. Secara khusus, sebagian besar proyek Git bukan Linux.

Sebagai hasilnya, pilihan cerdas adalah menghapus sebagian dari fleksibilitas teoretis tersebut ketika mengimplementasikan Git. Secara teori repositori dapat membentuk grafik apa pun, dalam praktiknya pilihan yang biasa adalah pohon. Kita dapat melihat manfaat yang jelas menggunakan teori grafik: di pohon repositori, setiap dua repositori berbagi persis satu leluhur. Dalam grafik acak, gagasan tentang leluhur bahkan tidak ada!

Namun klien git Anda hampir pasti default ke model "leluhur tunggal". Dan grafik di mana node memiliki leluhur tunggal (kecuali untuk node root) adalah pohon. Jadi klien git Anda sendiri default ke model tree, dan karenanya repositori terpusat.


1
Saya setuju bahwa fleksibilitas Git perlu dikurangi untuk sebagian besar kasus penggunaan. Di pekerjaan terakhir saya, kami tidak memiliki pedoman tentang cara menggunakan git, dan ada konflik dan kerusakan yang konstan karena ini. Di perusahaan baru saya, kami menggunakan model Git Flow, dan itu membuat pengembangan jauh lebih ramping dan bebas stres.
gardenhead

1
Ini bukan "fleksibilitas teoretis" untuk memungkinkan non-pohon. Batasi diri Anda menjadi "hanya pohon" dan Anda tidak akan pernah bisa menggabungkan perubahan Anda, sehingga membuat seluruh VCS Anda agak tidak berguna.
Wildcard

2
@ Kartu Memori: Penggabungan sama sekali tidak ada masalah dengan pohon, mengapa demikian? Anda tidak dapat menggabungkan antara node acak, tentu saja, hanya antara orangtua / anak.
MSalters

1
Jelas saya tidak cukup jelas. Saya merujuk ke pohon komit, bukan pohon sistem file. Menurut definisi, komit gabungan memiliki lebih dari satu orangtua, dan karena itu grafik riwayat Anda bukan lagi pohon, melainkan DAG.
Wildcard

2
@Wildcard: MSalters mengatakan bahwa repositori biasanya terhubung sebagai pohon, bukan komit. Dia mengatakan bahwa repo biasanya hanya memiliki satu "upstream" remote yang mereka dorong (atau mengeluarkan permintaan tarik ke). Saya tidak memiliki statistik tentang apakah itu benar atau tidak, tetapi ini merupakan klaim yang sepenuhnya terpisah dari apa pun yang berkaitan dengan berapa banyak orang tua yang dimiliki oleh gabungan.
Steve Jessop

4

Logika bisnis menghargai server yang terpusat. Untuk hampir semua skenario bisnis yang realistis, server terpusat adalah fitur mendasar dari alur kerja.

Hanya karena Anda memiliki kapasitas untuk melakukan DVCS, bukan berarti alur kerja utama Anda adalah DVCS. Ketika saya menggunakan git di tempat kerja, kami menggunakannya secara terpusat, kecuali untuk kasus aneh aneh di mana bit yang didistribusikan sangat penting untuk menjaga hal-hal bergerak bersama.

Sisi terdistribusi adalah rumit. Biasanya Anda ingin menjaga semuanya lancar dan mudah. Namun, dengan menggunakan git Anda memastikan bahwa Anda memiliki akses ke sisi terdistribusi untuk menangani situasi degil yang mungkin timbul di jalan.


3

Untuk seorang rekan kerja untuk menarik dari repo git pada mesin saya berarti saya perlu memiliki daemon git berjalan di tingkat root sebagai tugas latar belakang. Saya sangat curiga terhadap daemon yang berjalan di komputer saya sendiri, atau di laptop yang disediakan perusahaan saya. Solusi termudah adalah "TIDAK"! Bagi seorang rekan kerja untuk menarik dari repo git pada komputer saya juga berarti alamat internet saya perlu diperbaiki. Saya bepergian, saya bekerja dari rumah, dan saya kadang-kadang bekerja dari kantor saya.

Di sisi lain, VPNing ke situs perusahaan dan mendorong cabang ke repo pusat membutuhkan waktu kurang dari satu menit. Saya bahkan tidak perlu VPN jika saya di kantor. Rekan kerja saya dapat dengan mudah menarik dari cabang itu.

Di pihak ketiga, repo git lokal saya adalah repositori berfitur lengkap. Saya dapat melakukan pekerjaan baru, membuat cabang baru untuk pekerjaan eksperimental, dan mengembalikan pekerjaan ketika saya mengacaukan banyak hal, bahkan ketika saya sedang bekerja di pesawat terbang dengan ketinggian 30.000 kaki di tengah-tengah dari mana. Coba lakukan itu dengan sistem kontrol versi terpusat.


"Saya sangat curiga terhadap daemon yang berjalan di komputer saya sendiri, atau di laptop yang disediakan perusahaan saya." - karena selain dari hal lain, menjalankan layanan di laptop saya berarti bahwa layanan tidak tersedia ketika saya menutup penutupnya! DynDNS mungkin membantu dengan beberapa lokasi (sampai batas tertentu, Anda masih bisa terjebak di belakang NAT), tetapi tidak membantu mematikan kartu jaringan Anda ...
Steve Jessop

Ada banyak cara untuk membuat git repo terlihat tanpa menjalankan daemon khusus; itu dapat diakses melalui hampir semua berbagi file (seseorang, sshfs, dll), dan bahkan dapat dibuat tersedia sebagai toko HTTP polos juga.
fluffy

2

Kompleksitas:

Dengan repositori pusat, alur kerja khas mungkin

branch off from the central master branch
change the code
test
possibly go back to changing the code
commit
merge any new changes from the central master branch
test
possibly go back to changing the code
merge changes into the central master branch and push

Kompleksitas sehubungan dengan jumlah pengembang di O (1).

Jika sebaliknya masing-masing pengembang memiliki cabang utama sendiri, untuk pengembang 0:

branch off from master branch 0
merge from master branch 1
...
merge from master branch N-1
change the code
test
possibly go back to changing the code
commit
merge any changes from master branch 0
merge any changes from master branch 1
...
merge any changes from master branch N-1
test
possibly go back to changing the code
merge changes into master branch 0

Pendekatan peer-to-peer adalah O (N).

Konsistensi:

Sekarang pertimbangkan jika ada konflik gabungan antara cabang utama Alice dan cabang utama Bob. Setiap pengembang N dapat menyelesaikan konflik secara berbeda. Hasil: kekacauan. Ada cara untuk mencapai konsistensi akhirnya, tetapi sampai itu terjadi, semua jenis waktu pengembang dapat terbuang sia-sia.


Jika Anda akan memilih, bisakah Anda memberikan komentar mengapa?
Theodore Norvell

Bukannya aku keberatan dengan downvotes. Saya hanya ingin tahu apakah jawabannya salah.
Theodore Norvell

1

Sederhana:

Perusahaan adalah organisasi yang terpusat, dengan alur kerja yang terpusat.

Setiap programmer memiliki bos dan bosnya, dll hingga CTO. CTO adalah sumber utama kebenaran teknis. Apa pun alat yang digunakan perusahaan, itu harus mencerminkan rantai komando ini. Sebuah perusahaan seperti tentara - Anda tidak bisa membiarkan prajurit mengalahkan seorang jenderal.

GIT menawarkan fitur yang berguna bagi perusahaan (mis. Menarik permintaan untuk meninjau kode) dan itu saja membuat mereka beralih ke GIT. Bagian desentralisasi hanyalah fitur yang tidak mereka butuhkan - sehingga mereka mengabaikannya.

Untuk menjawab pertanyaan Anda: Bagian yang didistribusikan memang unggul dalam lingkungan terdistribusi, misalnya sumber terbuka. Hasil bervariasi tergantung pada siapa yang berbicara. Linus Torvalds sebenarnya bukan tikus bilik Anda, itu sebabnya fitur berbeda dari GIT penting baginya daripada untuk perusahaan github-centric Anda.


-2

Mungkin itu karena pemrosesan penggajiannya terpusat, jadi kita harus membuat orang pusat senang jika kita ingin dibayar.

Mungkin itu karena kami menciptakan satu produk, jadi kami membutuhkan salinan utama perangkat lunak untuk pelanggan.

Mungkin itu karena jauh lebih mudah bagi seorang programmer untuk pergi ke satu tempat untuk mendapatkan perubahan semua orang, daripada harus terhubung ke banyak mesin yang berbeda.

Mungkin itu karena database bug terpusat, dan harus tetap disinkronkan dengan kode .

Terpusat itu bagus, sampai ada masalah .....

Git menjadi sistem terdistribusi memungkinkan pusat baru dibuat dengan biaya rendah dari repositori terkini (cukup tampilkan repositori ke jaringan). Git juga memungkinkan cadangan yang kedaluwarsa diperbarui dari repositori pada mesin pengembang, sehingga membuatnya lebih mudah untuk memulihkan pusat.

Mampu melakukan penggabungan dll pada salinan lokal dari repositori ketika jaringan sedang buruk, tetapi tidak memerlukan sistem terdistribusi; itu hanya membutuhkan sistem yang menyimpan salinan lokal dari semua data. Begitu juga dengan memeriksa kode dengan terbang dll.

Pada akhirnya, ada sedikit biaya untuk didistribusikan dan beberapa manfaat. Sebagian besar biaya distribusi ada di area yang diperlukan jika Anda ingin pelacakan cabang yang bagus, dll. Jika Anda merancang sistem untuk digunakan di sebagian besar perusahaan, Anda tidak akan mendesainnya untuk didistribusikan, karena kontrol terpusat dari kode sumber jelas merupakan "kasus penggunaan" utama.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.