Decentralize Git
Hashing
Git sederhananya merupakan simple Key-Value datastore, dimana hash dari content akan menjadi key untuk content itu sendiri. Baik itu hash dari content yang berisi meta commit, tree hash dan blob file. Setiap hash dalam git disebut dengan ObjectID, dimana dalam satu kali melakukan commit, git akan mengkalkulasi tiga hash sekaligus, yaitu hash untuk Meta Commit yang berisi message commit, tanggal commit dsb, lalu Tree Hash, dan Blob hash.
Tulisan ini adalah bagian dari Git SCM Series, sehingga untuk bisa membaca secara menyeluruh dan berkesinambungan, alangkah lebih baik bisa membaca secara urut dari link series berikut.
Sebagai contoh, kita coba membuat file bernama README.md yang berisi Sample Content README.md. Lalu kita add dan commit file tersebut dengan message commit Sample Commit Message. Setelah commit berhasil maka git akan memberikan hash SHA-1 yang merupakan hash dari content Meta Commit. Sebagai contoh seperti ini output hash seperti ini df5496d7e785b44e2beef9349cef4bc3b4b9ddc7 atau bisa juga dengan 7 character awal dari hash tersebut (df5496d). Hash adalah key dari commit message yang kita buat. Cara mengetahui isi key tersebut adalah dengan menggunakan git cat-file . Sebagai contoh seperti ini
$ git cat-file -p df5496d
tree 5ffea0e1130ea4ecf542691c3e066e51d8628233
author Verri <verri@local.host> 1736952966 +0700
committer Verri <verri@local.host> 1736952966 +0700
Sample Commit Message
Seperti pada output dari hasil cat-file, key tersebut berisi Meta Commit.
Terlihat pada line pertama terdapat tree <hash> dimana hash tersebut berisi line permission file, type object lalu nama object. Jika menggunakan git-cat-file untuk membaca hash tersebut. Maka outputnya kurang lebih akan seperti ini.
$ git cat-file -p 5ffea0e1130ea4ecf542691c3e066e51d8628233
100644 blob 50e0aa820aae2d872340d0a13b94b129a9f589a8 README.md
Karena object berupa file, maka type object akan menjadi blob tapi jika object merupaka folder, maka type object akan menjadi tree.
Pada output dari hasil cat-file hash dari tree, terdapat hash yang merupakan key dari content README.md. Bisa menggunakan cat-file untuk mendapatkan content dari key hash tersebut.
$ git cat-file -p 50e0aa820aae2d872340d0a13b94b129a9f589a8
Sample Content README.md
Terlihat dari output bahwa hash tersebut berisi snapshoot dari isi file README.md yang di-commit.
Karena Git menggunakan metode hashing untuk melakukan snapshoot setiap perubahan yang di-commit yang secara default menggunakan algorithm SHA-1, maka akan membuat git lebih flexible ketika didistribusikan karena dengan menggunakan metode ini, Git tidak akan tergantung pada machine yang digunakan.
Shared Repository
Repository dalam Git merupakan kumpulan snapshoot dan history dari setiap perubahan yang di-commit. Ketika developer melakukan snapshooting dan commit dari perubahan code, Git akan me-hashing file-file yang terubah tersebut dan menyimpannya dalam bentuk blob file type pada folder .git/objects. Directory .git tersebutlah yang kita sebut Local Repository. Selanjutnya ketika developer perlu mendistribusikan perubahan-perubahan tersebut, maka diperlukan sebuah destinasi dimana nantinya git akan mendistribusikan file-file pada repository local tersebut ke destinasi yang dituju, dimana destinasi tersebut disebut sebagai Shared Repostiory. Seperti gambar di bawah ini.
Dari gambar mungkin terlihat bahwa Git terkesan terpusat atau centralized. Tapi pada dasarnya karena Git menggunakan hashing sebagai metode untuk meng-signature setiap perubahan, sehingga memberikan kelebihan kepada Git untuk dapat decentralize / tidak terpusat. Developer bisa menambah berapapun remote repository yang diperlukan. Tergantung dari pada kesepakatan antar developer itu sendiri.
Sebagai contoh di sini, misal setiap developer bisa memiliki remote repository sendiri, ditambah satu buah remote repository master yang hanya boleh di-pull oleh developer. Dimana remote repository master ini sebagai tempat dimana semua feature yang stable dan sudah live di production.
Seperti terlihat pada gambar di atas. Terdapat satu master repository sebagai master repository, dimana maintainer / developer tidak memiliki hak untuk melakukan push ke master repository. Tapi setiap maintainer / developer hanya diperbolehkan melakukan push remote repository khusus developer. Dengan workflow seperti ini, maka setiap code yang masuk ke master repository akan terjaga secara history dan perubahan. Sedangkan pada remote repository masing-masing maintainer / developer dibebaskan untuk melakukan push biasa ataupun force push.
Histories dan snapshoot pada setiap Shared Repository bisa saja berbeda-beda, tergantung pada masing-masing developer. Misal Developer A hanya akan meng-update branch feature/sidebar pada shared repository B, begitu juga sebaliknya. Developer B mungkin hanya meng-update branch feature/header. Tapi bisa juga Shared Repository A atau pun Shared Repository B identik yaitu memiliki history dan jumlah Branch yang bener-benar sama. Kembali lagi semua tergantung pada kesepatakan antar developer yang terlibat.
Dengan kemampuan Git yang tidak terpusat, maka akan mempermudah developer untuk saling sharing code tanpa perlu khawatir dengan downtime dari Server.
reference:
Subscribe to my newsletter
Read articles from Andriawan directly inside your inbox. Subscribe to the newsletter, and don't miss out.
Written by