Git
Chapters ▾ 2nd Edition

4.1 Git di Server - Protokol

Pada tahap ini, seharusnya Anda sudah mampu melakukan sebagian besar tugas sehari-hari yang akan Anda kerjakan dengan menggunakan Git. Namun, untuk melakukan kolaborasi di Git, Anda harus memiliki repositori remote Git. Walaupun secara teknis Anda dapat mendorong dan menarik perubahan dari dan ke repositori seseorang, namun hal itu sangat tidak dianjurkan karena Anda akan kebingungan terhadap apa yang sedang mereka kerjakan jika Anda tidak berhati-hati. Selanjutnya, Anda mengharapkan kolaborator Anda dapat mengakses repositori meskipun komputer Anda sedang luring - memiliki repositori umum yang dapat diandalkan seringkali berguna dalam hal ini. Oleh karena itu, metode yang dianjurkan untuk berkolaborasi dengan seseorang adalah dengan cara membuat repositori perantara dimana Anda berdua memiliki akses untuk mendorong dan menarik perubahan dari repositori tersebut.

Menjalankan server Git cukup mudah dilakukan. Pertama, Anda memilih protokol yang diinginkan untuk berkomunikasi dengan server Anda. Bagian pertama dari bab ini akan membahas protokol-protokol yang tersedia beserta pro dan kontra dari masing-masing protokol. Bagian selanjutnya akan menjelaskan beberapa pengaturan khusus menggunakan protokol-protokol tersebut dan bagaimana manjalankan server Anda dengannya. Terakhir, kita akan membahas beberapa pilihan tempat penyimpanan, jika Anda tidak keberatan menyimpan kode Anda pada server orang lain dan tidak ingin rumit-rumit mengatur dan merawat server Anda sendiri.

Jika Anda tidak tertarik untuk menjalankan server sendiri, Anda dapat melewatinya dan langsung ke bagian terakhir bab ini untuk melihat beberapa pilihan untuk pengaturan penyimpanan akun dan kemudian beralih ke bab berikutnya, di mana kami membahas berbagai seluk beluk tentang bekerja dalam lingkungan sumber kontrol yang terdistribusi.

Sebuah repositori remote pada umumnya merupakan sebuah repositori kosong - sebuah repositori Git yang tidak memiliki direktori kerja. Karena repositori tersebut hanya digunakan sebagai titik kolaborasi, tidak ada alasan untuk memeriksa setiap gambarannya pada disk; itu hanya data Git. Dalam istilah yang paling sederhana, sebuah repositori kosong merupakan isi dari direktori .git proyek Anda dan tidak ada yang lain.

Protokol

Git dapat menggunakan empat protokol utama untuk mentransfer data: Lokal, HTTP, Secure Shell(SSH) dan Git. Di sini kita akan membahas apa saja itu dan dalam keadaan dasar seperti apa Anda ingin (atau tidak ingin) menggunakannya.

Protokol Lokal

Hal yang paling mendasar adalah Protokol lokal, di mana repositori remote berada dalam direktori lain pada disk. Ini sering digunakan jika semua orang dalam tim Anda memiliki akses bersama terhadap filesistem seperti mount NFS, atau pada kasus yang sering terjadi setiap orang masuk ke komputer yang sama. Tidak masalah siapa yang terakhir, karena semua contoh kode repositori Anda akan tetap berada pada komputer yang sama, yang lebih mungkin terjadi adalah kerugian dan kehilangan data.

Jika Anda memiliki filesistem yang terpasang bersama, Anda dapat melakukan kloning, push, pull dari dan ke repositori lokal yang berbasis berkas. Untuk melakukan kloning sebuah repositori seperti ini atau menambahkannya sebagai remote kedalam proyek yang sudah ada, gunakan jalur ke repositori sebagai URL. Sebagai contoh, untuk mengkloning sebuah repositori lokal, Anda dapat melakukannya dengan cara seperti ini:

$ git clone /opt/git/project.git

Atau dapat dilakukan dengan cara:

$ git clone file:///opt/git/project.git

Git bekerja dengan cara yang sedikit berbeda jika Anda menentukan file:// di awal URL secara eksplisit. Jika Anda hanya menentukan jalurnya, Git akan mencoba menggunakan hardlink atau menyalin berkas-berkas yang diperlukan secara langsung. Jika Anda menentukan file://, Git akan mengaktifkan proses-proses yang biasanya digunakan untuk memindahkan data melalui jaringan yang umumnya merupakan metode yang kurang efisien dalam memindahkan data. Alasan utama untuk menentukan awalan file:// adalah jika Anda menginginkan sebuah salinan repositori yang bersih dengan meninggalkan referensi dan objek asing - biasanya setelah diimpor dari sistem kontrol versi lain atau yang serupa dengannya (lihat Git Internals untuk tugas-tugas perawatan). Kita akan menggunakan jalur normal di sini karena hal ini akan menjadikannya lebih cepat.

Untuk menambahkan repositori lokal kedalam proyek Git yang sudah ada, Anda dapat menjalankan perintah seperti ini:

$ git remote add local_proj /opt/git/project.git

Lalu, Anda dapat melakukan push dan pull dari dan ke repositori remote seperti Anda melakukannya melalui jaringan.

Pro

Repositori berbasis file ini didukung karena terlihat lebih sederhana dan menggunakan hak akses berkas dan akses jaringan yang ada. Jika Anda sudah memiliki sebuah sistem file bersama di mana seluruh tim Anda memiliki akses, mudah sekali membuat sebuah repositori. Simpan salinan repositori kosong di suatu tempat yang dapat diakses secara bersama dan atur hak akses baca/tulis seperti yang Anda inginkan untuk direktori bersama lainya. Kita akan membahas bagaimana mengekspor salinan repositori kosong untuk tujuan ini pada Getting Git on a Server.

Ini juga merupakan pilihan yang bagus untuk mengambil pekerjaan dari repositori kerja orang lain dengan cepat. Jika Anda dan rekan kerja sedang mengerjakan proyek yang sama dan mereka ingin Anda memeriksa sesuatu, menjalankan perintah seperti git pull /home/john/project seringkali lebih mudah dari pada harus melakukan pushing ke server remote dan mengharuskan Anda untuk melakukan pulling ke komputer lokal.

Kontra

Yang menjadi kontra dari metode ini bahwa akses bersama pada umumnya lebih sulit pada pengaturan dan untuk akses dari berbagai lokasi daripada akses jaringan dasar. Jika Anda ingin melakukan push dari laptop saat berada di rumah, Anda harus melakukan mounting disk remote, yang bisa lebih sulit dan lambat jika dibandingkan dengan akses berbasis jaringan.

Penting juga untuk menyebutkan bahwa ini bukan merupakan pilihan tercepat jika Anda menggunakan mount bersama. Repositori lokal cepat hanya jika Anda memiliki akses yang cepat terhadap data. Sebuah repositori pada NFS seringkali lebih lambat jika dibandingkan dengan repositori yang diakses melalui SSH pada server yang sama, yang memungkinkan Git untuk menjalankan disk lokal pada setiap sistem.

Protokol HTTP

Git dapat berkomunikasi melalui HTTP dalam dua mode yang berbeda. Sebelum Git 1.6.6 hanya ada satu cara yang bisa dilakukan untuk melakukan hal ini dengan cara yang sangat sederhana dan umumnya hanya bisa dibaca. Pada versi 1.6.6 sebuah protokol baru yang lebih cerdas diperkenalkan yang melibatkan kemampuan cerdas Git dalam melakukan transfer data dengan cara yang serupa ketika dilakukan melalui SSH. Dalam beberapa tahun terakhir, protokol HTTP baru ini menjadi sangat terkenal karena lebih mudah bagi pengguna dan lebih pintar dalam cara berkomunikasi. Versi yang lebih baru sering disebut sebagai protokol “Smart” HTTP dan yang lama disebut sebagai protokol “Dumb” HTTP. Kami akan membahas protokol “Smart” HTTP terlebih dahulu.

Smart HTTP

Protokol “Smart” HTTP beroperasi dengan cara yang sama seperti protokol SSH atau Git namun berjalan melalui port standar HTTP/S dan dapat menggunakan bermacam mekanisme otentikasi HTTP, artinya seringkali lebih mudah bagi si pengguna dari pada menggunakan SSH, karena Anda dapat menggunakan hal-hal seperti otentikasi dasar nama pengguna/kata sandi dari pada harus mengatur kunci SSH.

Mungkin ini telah menjadi cara yang paling populer dalam menggunakan Git sekarang ini, karena keduanya dapat diatur untuk berfungsi secara anonim seperti protokol git://, dan juga dapat dilakukan pushing dengan otentikasi dan enkripsi seperti protokol SSH. Daripada harus menyiapkan URL yang berbeda untuk hal-hal seperti ini, sekarang Anda dapat menggunakan satu URL untuk keduanya. Jika Anda melakukan push sedangkan repositori mengharuskan otentikasi (yang memang begitu seharusnya), server dapat meminta nama pengguna dan kata sandi. Hal ini juga berlaku untuk akses baca.

Sebenarnya, untuk layanan seperti GitHub, URL yang Anda gunakan untuk melihat sebuah repositori yang daring (contohnya, “https://github.com/schacon/simplegit”) merupakan URL yang sama yang dapat Anda gunakan untuk mengkloning, dan jika Anda memiliki akses terhadapnya, Anda dapat melakukan push ke repositori tersebut.

Dumb HTTP

Jika server tidak menanggapi layanan smart HTTP Git, maka klien akan mencoba untuk kembali menggunakan protokol “dumb” HTTP yang lebih sederhana. Protokol Dumb mengharapkan repositori Git yang kosong disajikan seperti berkas yang normal dari server web. Yang menarik dari protokol HTTP Dumb adalah kesederhanaan pengaturannya. Pada dasarnya, yang harus Anda lakukan adalah meletakkan sebuah repositori Git kosong di bawah root dokumen HTTP Anda dan mengaitkannya dengan post-update tertentu, dan selesai (Lihat Git Hooks). Pada tahap itu, siapa saja yang dapat mengakses server web tempat Anda meletakkan repositori juga dapat mengkloning repositori Anda. Untuk mengizinkan akses baca ke repositori Anda mealui HTTP, lakukanlah seperti ini:

$ cd /var/www/htdocs/
$ git clone --bare /jalur/ke/proyek_git gitproject.git
$ cd gitproject.git
$ mv hooks/post-update.sample hooks/post-update
$ chmod a+x hooks/post-update

Itu saja. Kaitan post-update yang hadir bersama Git secara default menjalankan perintah yang tepat (git update-server-info) untuk membuat fetching dan cloning HTTP bekerja dengan semestinya. Perintah ini dijalankan saat Anda melakukan push ke repositori ini (mungkin melalui SSH); maka orang lain dapat melakukan clone dengan cara seperti ini

$ git clone https://example.com/gitproject.git

Pada kasus ini, kami menggunakan jalur /var/www/htdocs yang umum digunakan untuk pengaturan Apache, namun Anda dapat menggunakan server web statis - cukup dengan meletakkan repositori kosong di jalurnya. Data Git berfungsi sebagai file statis dasar (lihat Git Internals untuk rincian tentang bagaimana cara kerjanya).

Umumnya Anda akan memilih untuk menjalankan server Smart HTTP dengan akses baca/tulis atau hanya memiliki file yang dapat diakses sebagai baca-saja pada kondisi Dumb HTTP. Jarang sekali menjalankan perpaduan dari dua layanan ini.

Pro

Kami akan berkonsentrasi pada dukungan dari versi Smart dari protokol HTTP.

Salah satu kesederhanaan memiliki satu URL untuk semua jenis akses dan mengharuskan pengguna untuk mengisi kembali data untuk otentikasi yang ditampilkan oleh layar server membuat semuanya sangat mudah bagi pengguna akhir. Mampu mengotentikasi dengan menggunakan nama pengguna dan kata sandi juga merupakan keuntungan besar dari SSH, karena pengguna tidak perlu menghasilkan kunci SSH secara lokal dan mengunggah kunci publik mereka ke server sebelum dapat berinteraksi dan bekerja dengannya. Untuk pengguna yang kurang berpengalaman, atau pengguna sistem di mana SSH kurang umum digunakan, kegunaan ini merupakan keuntungan yang utama. Juga merupakan protokol yang sangat cepat dan efisien, mirip dengan SSH.

Anda juga dapat menjalankan repositori Anda dengan status baca-saja melalui HTTPS, yang berarti Anda dapat memindahkan konten data dalam keadaan terenkripsi; atau lebih lanjut dapat dilakukan dengan membuat klien menggunakan sertifikat SSL yang ditandatangani khusus.

Hal menarik lainnya adalah bahwa HTTP/S merupakan protokol yang umum digunakan sehingga firewall-firewall yang digunakan pada perusahaan sering dibuat untuk memungkinkan lalu lintas jaringan melalui port ini.

Kontra

Penggunaag Git melalui HTTP/S bisa sedikit lebih rumit dalam pengaturannya jika dibandingkan dengan SSH pada beberapa server. Selain itu, protokol-protokol yang lain memiliki sedikit sekali keuntungan jika dibandingkan dengan protokol “Smart” HTTP dalam menjalankan Git.

Jika Anda menggunakan HTTP untuk melakukan pushing yang terotentikasi, memberikan kredensial Anda terkadang menjadi lebih rumit jika dibandingkan dengan menggunakan kunci melalui SSH. Namun ada beberapa perkakas caching kredensial yang dapat Anda gunakan, termasuk akses Keychain pada OSX dan Credential Manager di Windows, untuk menjadikannya lebih mudah. Baca Credential Storage untuk melihat bagaimana menyiapkan caching kata sandi HTTP yang aman di sistem Anda.

Protokol SSH

Protokol transportasi yang umum digunakan untuk Git jika melakukan hosting sendiri adalah melalui SSH. Hal ini dikarenakan akses melalui SSH ke server sudah diatur pada kebanyakan sistem - dan jika tidak, cukup mudah untuk melakukannya. SSH juga merupakan sebuah protokol jaringan yang terotentikasi; dan karena itu ada di mana-mana, umumnya mudah untuk dipasang dan digunakan.

Untuk melakukan clone sebuah repositori Git melalui SSH, Anda dapat menentukan ssh:// URL seperti ini:

$ git clone ssh://user@server/project.git

Atau Anda dapat menggunakan sintaks yang lebih singkat seperti sintaks secure copy untuk protokol SSH:

$ git clone user@server:project.git

Anda juga dapat tidak mencantumkan nama pengguna, dan Git akan menganggap pengguna yang saat ini masuk sebagai Anda.

Pro

Ada banyak keuntungan menggunakan SSH. Pertama, SSH relatif mudah diatur - daemon SSH sudah biasa digunakan, banyak administrator jaringan juga memiliki pengalaman menggunakannya, dan kebanyakan distribusi Sistem Operasi disiapkan untuk menggunakan SSH atau memiliki perkakas untuk mengelolanya. Selanjutnya, akses melalui SSH lebih aman - semua transfer data terenkripsi dan terkonfirmasi. Terakhir, seperti halnya protokol HTTP/S, Git dan Lokal, SSH lebih efisien, menjadikan data serapi mungkin sebelum mentransfernya.

The Cons

Aspek negatif dari menggunakan SSH adalah Anda tidak dapat menjalankan akses anonim repositori Anda melaluinya. Pengguna harus memiliki akses ke komputer Anda melalui SSH untuk mengaksesnya, bahkan dalam bentuk baca-saja, sehingga membuat akses SSH tidak kondisif untuk proyek sumber terbuka. Jika Anda hanya menggunakannya dalam jaringa perusahaan Anda, SSH mungkin satu-satunya protokol yang perlu Anda tangani. Jika Anda ingin mengizinkan akses baca-saja bagi pengguna anonim terhadap proyek Anda dan juga ingin menggunakan SSH, Anda harus mempersiapkan SSH bagi Anda agar dapat melakukan push dan sesuatu yang lain bagi pengguna lain untuk melakukan fetch.

Protokol Git

Berikutnya adalah protokol Git. Ini merupakan daemon khusus yang dikemas bersamaan dengan Git; tugasnya melakukan listening pada port khusus (9418) yang menyediakan layanan yang serupa dengan protokol SSH, namun tanpa otentikasi sama sekali. Agar repositori dapat dijalankan melalui protokol Git, Anda harus membuat berkas git-daemon-export-ok - daemon tidak akan menjalankan repositori tanpa berkas ini di dalamnya - tapi selain itu tidak ada keamanan. Repositori Git tersedia bagi semua orang baik untuk dikloning atau tidak. Ini berarti bahwa secara umum protokol ini tidak dapat melakukan pushing melalui protokol ini. Anda dapat mengaktifkan akses push; namun mengingat kurangnya masalah otentikasi, jika Anda mengaktifkan akses push, setiap orang di internet yang menemukan URL proyek Anda dapat melakukan pushing terhadap proyek Anda. Cukup untuk dikatakan bahwa hal ini jarang terjadi.

Pro

Protokol Git seringkali merupakan protokol transfer jaringan tercepat yang tersedia. Jika Anda melayani banyak lalu lintas data untuk proyek umum atau melayani proyek yang sangat besar yang tidak mengharuskan pengguna melakukan otentikasi untuk akses baca, kemungkinan Anda ingin menyiapkan daemon untuk menjalankan proyek Anda. Protokol ini menggunaka mekanisme transfer data yang sama seperti protokol SSH namun tanpa melalui enkripsi dan otentikasi.

Kontra

Kelemahan dari protokol Git adalah kurangnya otentikasi. Secara umum hal ini tidak diinginkan untuk menjadikan protokol Git sebagai satu-satunya protokol akses ke proyek Anda. Umumnya, Anda akan menggabungkannya dengan akses melalui SSH atau HTTPS untuk beberapa pengembang yang memilikik akses push (tulis) dan meminta pengguna lain untuk menggunakan git:// untuk akses hanya-baca. Ini juga mungkin merupakan protokol yang paling sulit untuk dipersiapkan. Protokol ini harus menjalankan daemon sendiri, yang membutuhkan konfigurasi xinetd atau sejenisnya, yang tidak selalu mudah untuk dilakukan. Protokol ini juga memerlukan akses firewall ke port 9418, yang bukan merupakan port standar yang selalu diizinkan untuk diakses oleh firewall perusahaan. Pada firewall perusahaan besar, port yang tidak dikenal ini biasanya diblokir.

scroll-to-top