Bagaimana Git dirancang?


9

Tempat kerja saya baru-baru ini beralih ke Git dan saya telah mencintai (dan membenci!) Itu. Saya benar-benar menyukainya, dan ini sangat kuat. Satu-satunya bagian yang saya benci adalah bahwa kadang-kadang itu terlalu kuat (dan mungkin agak singkat / membingungkan).

Pertanyaan saya adalah ... Bagaimana Git dirancang? Hanya menggunakannya untuk waktu yang singkat, Anda merasa bahwa itu dapat menangani banyak alur kerja yang tidak diketahui oleh sistem kontrol versi lain. Tapi di bawahnya juga terasa elegan. Dan cepat!

Ini tidak diragukan lagi sebagian karena bakat Linus. Tapi saya bertanya-tanya, apakah keseluruhan desain git didasarkan pada sesuatu? Saya sudah membaca tentang BitKeeper tetapi akunnya kurang detail teknis. Kompresi, grafik, menghilangkan angka revisi, menekankan percabangan, menyembunyikan, remote ... Dari mana semua itu berasal?

Linus benar-benar mengetuk yang satu ini dari taman dan pada percobaan pertama! Ini cukup baik untuk digunakan setelah Anda melewati kurva belajar.


mungkin Anda bisa mendapatkan bantuan pada saluran IRC git (# git on freenode)
yati sagade


2
you get the feel that it can handle many obscure workflows that other version control systems could not: Itu mungkin karena itu dirancang untuk menangani kernel linux, sepotong kode terkenal besar, rumit dan rumit.
yannis

1
Pada peringatan 10 tahun Git, berikut adalah artikel dari wawancara dengan Torvalds: linux.com/news/featured-blogs/185-jennifer-cloer/…
Sridhar Sarnobat

Jawaban:


17

Git tidak dirancang sebanyak berevolusi .

Lihatlah sendiri. Kloning repositori git resmi , buka di gitk(atau viewer git log grafis favorit Anda), dan lihat revisi yang paling awal.

Anda akan melihatnya pada awalnya hanya memiliki fungsionalitas inti (database objek dan indeks). Segala sesuatu yang lain dilakukan dengan tangan . Namun, inti kecil ini dirancang agar mudah diotomatisasi melalui skrip shell. Pengguna awal git menulis skrip shell mereka sendiri untuk mengotomatisasi tugas-tugas umum; sedikit demi sedikit, skrip ini dimasukkan ke dalam distribusi git (lihat contoh awal 839a7a0 ). Setiap kali ada kebutuhan baru, skrip diadaptasi untuk memungkinkannya. Beberapa saat kemudian, beberapa skrip ini akan ditulis ulang dalam C.

Kombinasi dari inti yang bersih dan ortogonal (yang masih dapat Anda gunakan secara langsung jika Anda membutuhkannya), dengan lapisan atas yang tumbuh secara organik di atasnya, adalah yang memberi git kekuatannya. Tentu saja, itu juga yang memberikan sejumlah besar perintah dan opsi yang diberi nama aneh.


Kompresi, grafik, menghilangkan angka revisi, menekankan percabangan, menyembunyikan, remote ... Dari mana semua itu berasal?

Banyak yang tidak ada di awal.

Sementara setiap objek dikompresi secara individual, dan duplikat dihindari dengan penamaan mereka, file "paket" yang bertanggung jawab atas kompresi tinggi yang biasa kita lihat di git tidak ada. Filosofi pada awalnya adalah "ruang disk murah".

Jika dengan "grafik" yang Anda maksud seperti pemirsa grafis gitk, mereka muncul kemudian (AFAIK, yang pertama adalah gitk). AFAIK, BitKeeper juga memiliki penampil riwayat grafis.

Menyingkirkan nomor versi, sebenarnya konsep inti git menggunakan filesystem yang ditujukan untuk menyimpan objek, sebagian besar berasal dari monoton . Pada saat itu, monoton lambat; jika ini tidak terjadi, mungkin Linus akan menggunakannya alih-alih membuat git.

Menekankan percabangan agak tidak dapat dihindari pada sistem kontrol versi terdistribusi, karena setiap klon bertindak sebagai cabang terpisah.

Stashing ( git stash) adalah, IIRC, cukup baru. Reflog, yang digunakannya, tidak ada di awal.

Bahkan remote awalnya tidak ada di sana. Awalnya, Anda menyalin objek menggunakan tangan rsync.

Satu per satu, masing-masing fitur ini ditambahkan oleh seseorang. Tidak semua dari mereka - mungkin bahkan tidak sebagian besar dari mereka - ditulis oleh Linus. Setiap kali ada yang merasa kebutuhan yang tidak dipenuhi git, seseorang dapat membuat fitur baru di atas lapisan "plumbing" inti git, dan mengusulkannya untuk dimasukkan. Jika itu baik, itu mungkin akan diterima, meningkatkan utilitas git (dan kompleksitas baris perintahnya) lebih jauh.


"AFAIK, BitKeeper juga memiliki penampil riwayat grafis." Ya, benar. Ini tidak terlalu cantik, tetapi sangat fungsional. Lihat bitkeeper.com/Test.Using.Looking.html , meskipun itu menunjukkan pekerjaan yang buruk dalam menampilkan cabang.
Bryan Oakley

1
Juga bacaan yang menarik, beberapa email terpilih dari awal git, menunjukkan sedikit evolusi awal: kerneltrap.org/node/4982
CesarB

Apakah programmer dulu meniru beberapa fungsionalitas git dengan cvs + rsync + httpd? Saya tertarik mendengar solusi buatan sendiri apa yang mungkin.
Sridhar Sarnobat

8

Saya pikir poin utamanya adalah git dirancang oleh satu-satunya orang yang paling memenuhi syarat di planet ini untuk melakukannya. Dan saya tidak berbicara tentang bakat, saya berbicara tentang pengalaman: Saya ragu ada orang lain yang bertanggung jawab atas basis kode dengan kombinasi ukuran dan jumlah kontributor yang sebanding sebagai kernel Linux dan masih benar-benar berurusan dengan sebagian besar integrasi bekerja sendiri.

Jadi Linus tahu persyaratan dan kasus penggunaan untuk sistem kontrol versi terdistribusi lebih baik daripada orang lain. Dan tentu saja itu membantu bahwa sebagian besar pengkodean yang dihadapinya ada di C, dan sebagian besar kinerjanya kritis.

Pada dasarnya itu adalah contoh utama dari menggaruk gatal sendiri.


6
"Lajang yang paling berkualitas"? Saya kira tidak. Ada banyak orang pintar yang memenuhi syarat untuk menulis kontrol sumber terdistribusi. Orang-orang di BitMover (perusahaan di belakang BitKeeper) benar- benar tahu apa yang mereka lakukan. Linus bahkan memberikan penghargaan kepada Larry McVoy karena menunjukkan kepadanya bagaimana kontrol kode sumber harus bekerja. Tanpa Larry tidak akan ada git.
Bryan Oakley

1
@BryanOakley, saya pikir kita bisa menghindari bashing ketika seseorang melengkapi seseorang untuk sesuatu yang baik. Semua orang yang tahu bahwa persyaratan membuat pengembang hebat. Jadi, jika besok, Anda dihadapkan dengan masalah besar, kami mungkin mengingat Anda, seperti yang kita lakukan pada Dennis Ritchie. Tidak ada yang lebih baik dari yang lain, hanya saja mereka menemukan persyaratan yang diakui di seluruh dunia dan memberikan solusi terlebih dahulu.
Pankaj Upadhyay

2
@Bryan: Saya yakin pengalaman menggunakan BitKeeper juga banyak mengajar Linus, dan saya seharusnya menyebutkan itu. Dan tentu saja, ada banyak orang pintar dan berkualitas lainnya yang tahu apa yang mereka lakukan. Tetapi saya masih mempertahankan bahwa pengalaman Linus dalam memelihara kernel menjadikannya yang paling berkualitas, lebih bijaksana. Saya mungkin salah, tetapi dapatkah Anda menunjukkan proyek lain yang besar, dengan banyak kontributor, dan di mana orang yang bertanggung jawab atas semuanya masih sangat terlibat dalam mendapatkan kode aktual semua kontributor untuk bekerja bersama?
Michael Borgwardt

@Pankaj Upadhyay: Saya tidak memukul siapa pun, saya hanya menjelaskan mengapa saya menurunkan jawaban. Anda mengatakan sesuatu tentang "memberikan solusi terlebih dahulu" yang saya pikir berarti Anda berpikir git entah bagaimana "pertama" dalam beberapa hal. Menurut Anda apa yang pertama kali terjadi? Itu jelas bukan alat scm pertama yang didistribusikan oleh tembakan panjang.
Bryan Oakley

1
@DeadMG: Bagian yang lebih penting dari pernyataan itu muncul setelahnya "... dan sebagian besar kinerjanya kritis". Saya ragu Anda akan menemukan banyak yang akan berpendapat bahwa C tidak terlalu cocok untuk menerapkan kode kinerja tinggi overhead rendah jika Anda mengetahuinya dengan baik.
Michael Borgwardt

6

Itu dirancang cukup persis seperti yang dijelaskan dalam Perumpamaan Git .

Bayangkan Anda memiliki komputer yang tidak memiliki apa-apa selain editor teks dan beberapa perintah sistem file. Sekarang bayangkan Anda telah memutuskan untuk menulis program perangkat lunak besar pada sistem ini. Karena Anda adalah pengembang perangkat lunak yang bertanggung jawab, Anda memutuskan bahwa Anda perlu menemukan semacam metode untuk melacak versi perangkat lunak Anda sehingga Anda dapat mengambil kode yang sebelumnya Anda ubah atau hapus. Berikut ini adalah cerita tentang bagaimana Anda bisa merancang satu sistem kontrol versi (VCS) dan alasan di balik pilihan desain tersebut.

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.