Bagian pertama dari wawancara.
Sistem kontrol versi terdistribusi Git
JA: Linux hanyalah proyek pertama Anda yang berdampak global pada dunia open source. Pada tahun 2005, Anda juga membuat Git, sistem kontrol versi terdistribusi yang sangat populer. Anda dengan cepat memindahkan pohon sumber kernel Linux Anda dari repositori Bitkeeper berpemilik ke Git yang baru dibuat, yang Anda buat sebagai sumber terbuka, dan pada tahun yang sama Anda mentransfer dukungan Git ke Junio Hamano . Sejarah peristiwa ini sangat menarik, beri tahu kami apa yang mendorong Anda untuk menyerahkan proyek ini begitu cepat, dan bagaimana Anda menemukan dan memilih Junio?
LT: Jadi jawaban atas pertanyaan ini ada dua bagian.
Pertama, saya sama sekali tidak ingin membuat sistem kendali sumber baru. Linux dibuat karena saya sangat tertarik dengan antarmuka tingkat rendah antara perangkat keras dan perangkat lunak - pada prinsipnya, pekerjaan ini dilakukan karena kecintaan pada subjek dan minat pribadi. Sebaliknya, Git dibuat karena kebutuhan: bukan karena saya tertarik dengan kontrol sumber, tetapi karena sebagian besar sistem kontrol versi yang tersedia pada saat itu membuat saya sangat jijik, dan yang menurut saya paling dapat diterima dan pada saat yang sama benar-benar bekerja sangat baik dengan model pengembangan Linux (BitKeeper) menjadi bangkrut.
Intinya: Saya telah bekerja di Linux selama lebih dari 30 tahun ( masih ada beberapa bulan sebelum ulang tahun rilis pertama , tetapi saya mulai mengerjakan apa yang kemudian menjadi Linux lebih dari 30 tahun yang lalu), dan selama ini saya telah mendukungnya. Tapi Git? Saya bahkan tidak berpikir tentang bagaimana mempertahankannya dalam jangka panjang. Saya benar-benar menyukainya, dan tentu saja menurut saya ini adalah sistem kendali sumber terbaik yang tersedia, tetapi itu bukan cinta dan hasrat saya yang besar, jika Anda tahu apa yang saya maksud.
Jadi saya selalu ingin menemukan seseorang untuk memelihara sistem kendali sumber ini untuk saya; sebenarnya, saya akan senang jika tidak menulisnya sama sekali.
Inilah konteksnya.
Adapun Junio - sebenarnya, dia adalah salah satu orang pertama yang benar-benar terlibat dalam pengembangan Git. Perubahan pertama darinya datang kepada saya dalam beberapa hari setelah saya membuat versi Git yang pertama (dan sangat kasar) tersedia untuk umum. Oleh karena itu, Junio telah terlibat dalam proyek ini, bisa dibilang, dari masa-masa awal Git.
Tetapi jangan berpikir bahwa saya baru saja menyerahkan proyek itu kepada orang pertama yang saya temui. Saya telah mempertahankan Git selama beberapa bulan, dan yang mendorong saya untuk bertanya kepada Junio apakah dia ingin mengambil alih dukungan ini adalah perasaan halus dari "selera yang baik". Memang, saya tidak bisa menggambarkannya lebih tepat: pemrograman direduksi menjadi pemecahan masalah teknis, tetapi intinya adalah bagaimanaAnda menyelesaikannya, dan ini adalah salah satu hal yang mulai dikenali dari waktu ke waktu: orang-orang tertentu memiliki "selera yang baik" dan karena itu memilih solusi yang "tepat".
Saya tidak ingin berpura-pura bahwa pemrograman adalah seni, karena pada kenyataannya pemrograman pada dasarnya adalah rekayasa yang baik. Saya sangat percaya pada mantra Thomas Edison tentang "satu persen bakat dan sembilan puluh sembilan persen ketekunan"; Hampir seluruh inti kesuksesan terletak pada detail-detail kecil dan pekerjaan rutin sehari-hari. Namun, bagaimanapun, terkadang Anda harus menunjukkan “inspirasi” dan “selera yang baik” itu, yaitu, tidak hanya menyelesaikan masalah, tetapi menyelesaikannya dengan rapi, akurat dan, ya, bahkan dengan indah.
Junio memiliki "selera yang bagus".
Kapan pun terkait Git, saya ingat untuk menjelaskannya dengan sangat jelas: Saat saya memelopori Git dan merancang ide intinya, saya sering mendapatkan pengakuan yang luar biasa untuk itu. Ini sudah lebih dari 15 tahun yang lalu, dan saya baru benar-benar tenggelam dalam Git untuk tahun pertama. Junio adalah teladan dalam mendukung Git, dan karena dialah Git menjadi seperti sekarang ini.
Omong-omong, keseluruhan cerita ini dengan "selera yang bagus" dan mencari orang-orang yang memilikinya, serta dengan kemampuan untuk mempercayai orang-orang ini - berlaku tidak hanya untuk Git, tetapi juga pada seluruh sejarah Linux. Tidak seperti Git, Linux adalah produk yang masih saya dukung. Saya secara aktif terlibat, tetapi Linux dalam banyak hal mirip dengan Git adalah keterlibatan banyak orang dalam proyek ini. Menurut saya, salah satu pencapaian paling luar biasa dari Linux adalah terdapat ratusan kontributor aktif yang mendukungnya, dan semuanya, yang bertanggung jawab atas berbagai bagian kernel, mengalami kesulitan untuk mendefinisikan "indra perasa".
JA: Pernahkah Anda mendelegasikan dukungan kepada seseorang dan kemudian menyadari bahwa keputusan ini salah?
LT: Struktur pekerjaan dukungan kami tidak pernah begitu hitam dan putih atau tidak fleksibel sehingga memberi kami masalah. Faktanya, kecil kemungkinan kami akan mencoba mendokumentasikan prosedur dukungan secara menyeluruh. Ya, kami memiliki file PEMELIHARA, tetapi dibuat agar Anda bisa menemukan orang yang tepat sebenarnya bukan merupakan tanda kepemilikan eksklusif.
Oleh karena itu, seluruh struktur “siapa yang memiliki apa” sebagian besar adalah plastik dan dimaksudkan untuk orientasi, itu berarti “orang ini aktif dan melakukan pekerjaannya dengan baik”, dan bukan “ups, kami mempercayakan orang tersebut dengan proyek, tetapi dia mengambilnya dan mengacaukan semuanya ”.
Situasinya juga plastis dalam arti bahwa mungkin Anda mendukung satu subsistem, tetapi Anda perlu mengambil sesuatu dari sistem lain - jadi, batas-batas ini dapat ditembus. Biasanya hal-hal seperti itu pertama kali dibicarakan secara aktif dengan orang-orang, dan baru kemudian selesai, tetapi intinya adalah ada praktik seperti itu, dan tidak ada aturan yang tegas dan cepat seperti “Anda hanya boleh menyentuh file ini”.
Faktanya, di sini kami meninjau kembali topik lisensi yang diangkat di Bagian 1 dan menyoroti salah satu prinsip yang mendisain Git, yaitu "setiap orang memiliki pohonnya sendiri, dan secara teknis tidak ada pohon yang istimewa."
Karena begitu banyak proyek lainnya telah menggunakan alat seperti CVS atau SVN - fundamental beberapa orang yang menjadi khusus dan mengambil keuntungan dari "kepemilikan" yang datang dengan status itu. Di dunia BSD, fenomena ini disebut "bit komit": ini adalah bit, yang pemiliknya memiliki hak untuk memasukkan kode ke repositori pusat (atau setidaknya beberapa bagiannya).
Saya selalu membenci model ini, karena model ini pasti mempengaruhi politik dan menghasilkan "klik" di komunitas pengembang, di mana beberapa orang menjadi istimewa, dan mereka dipercaya secara default. Masalahnya bukan karena mereka "percaya secara default", tetapi hanya di sisi lain mata uang: mereka tidak mempercayai seseorang, orang lain , dan mereka, menurut definisi, berubah menjadi orang luar yang perlu melalui salah satunya. dari "penjaga" untuk menyelesaikan pekerjaan. ".
Sekali lagi, ini tidak terjadi di Git. Setiap orang sama. Setiap orang dapat mengkloning cabang, memulai pengembangan mereka sendiri, dan jika mereka melakukan pekerjaan dengan baik, maka ketika mereka bergabung, cabang mereka dapat kembali ke cabang utama, dan jika sangat baik, maka mereka dipercayakan dengan dukungan, dan merekalah orang-orangnya. yang mulai bertanggung jawab untuk menggabungkan kode di pohon tersebut. yang menjadi tanggung jawab mereka;).
Oleh karena itu, tidak perlu memberikan hak khusus kepada orang-orang, seperti "sedikit konfirmasi". Ini juga berarti bahwa tidak ada kebijakan komit yang muncul, tidak ada yang harus "percaya secara default". Jika ternyata seseorang melakukan pekerjaan yang buruk, atau, lebih sering, orang tersebut kehilangan minat pada proyek dan menganggap pekerjaan itu lebih menarik - pekerjaan mereka tidak akan masuk ke cabang utama saat bergabung, dan mereka tidak akan bingung dengan kaki orang lain yang dapat menawarkan ide-ide baru dan segar.
JA: Pernahkah Anda terkesan dengan fitur-fitur baru Git, dan pernahkah Anda memasukkannya ke dalam alur kerja Anda? Dapatkah Anda menyebutkan fitur-fitur yang menurut Anda masih hilang di Git?
LT: tentu saja, pertama-tama, keinginan saya akan fungsionalitaslah yang terpenuhi, jadi saya jarang memikirkan tentang fitur baru.
Git pasti telah meningkat selama bertahun-tahun, dan beberapa peningkatan ini telah tercermin dalam alur kerja saya juga. Misalnya, Git selalu sangat cepat - lagipula, itu adalah salah satu tujuan desain yang ingin saya lakukan, tetapi banyak pekerjaan yang awalnya dilakukan dalam skrip shell yang diatur di sekitar beberapa program pembantu dasar. Selama bertahun-tahun, sebagian besar skrip shell ini telah hilang, yang berarti saya dapat menerapkan kit patch Andrew Morton lebih cepat daripada yang saya lakukan sebelumnya. Ini sangat menggembirakan, karena kecepatan bekerja dengan tambalan itulah yang saya gunakan sebagai salah satu tolok ukur pertama dalam pengujian kinerja.
Jadi, bagi saya, Git selalu bagus, tetapi semakin baik seiring berjalannya waktu.
Penting peningkatan tersebut terkait dengan seberapa nyaman bagi "pengguna biasa" untuk bekerja dengan Git. Sebagian besar karena fakta bahwa orang mengetahui cara kerja alur tugas di Git, dan baru saja terbiasa dengannya ( sangat berbeda dari CVS dan analog lain yang biasa digunakan orang sebelumnya), tetapi Git sendiri telah menjadi jauh lebih menyenangkan untuk digunakan. menggunakan.
Server cloud dari Macleod cepat dan aman.
Daftar menggunakan tautan di atas atau dengan mengklik spanduk dan dapatkan diskon 10% untuk bulan pertama menyewa server dengan konfigurasi apa pun!
