# 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](https://verri.andriawan.web.id/series/git-scm) Series, sehingga untuk bisa membaca secara menyeluruh dan berkesinambungan, alangkah lebih baik bisa membaca secara urut dari link series [berikut](https://verri.andriawan.web.id/series/git-scm). Sebagai contoh, kita coba membuat file bernama [`README.md`](http://README.md) yang berisi `Sample Content` [`README.md`](http://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 ```bash $ git cat-file -p df5496d tree 5ffea0e1130ea4ecf542691c3e066e51d8628233 author Verri 1736952966 +0700 committer Verri 1736952966 +0700 Sample Commit Message ``` Seperti pada output dari hasil cat-file, key tersebut berisi **Meta Commit**. Terlihat pada line pertama terdapat `tree ` 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. ```bash $ 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](http://README.md). Bisa menggunakan cat-file untuk mendapatkan content dari key hash tersebut. ```bash $ git cat-file -p 50e0aa820aae2d872340d0a13b94b129a9f589a8 Sample Content README.md ``` Terlihat dari output bahwa hash tersebut berisi snapshoot dari isi file [`README.md`](http://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. ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1737470429560/8a5882d6-c0e5-4227-af94-1c058654869e.png align="center") 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. ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1737470548648/c473bf23-e397-47a6-b7f4-817ceda8c0b5.png align="center") 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: * [https://www.geeksforgeeks.org/introduction-to-hashing-2/](https://www.geeksforgeeks.org/introduction-to-hashing-2/) * [https://git-scm.com/docs/hash-function-transition](https://git-scm.com/docs/hash-function-transition) * [https://git-scm.com/book/en/v2/Distributed-Git-Distributed-Workflows](https://git-scm.com/book/en/v2/Distributed-Git-Distributed-Workflows)