Git untuk Pemula
Baiklah, akhirnya saya menyempatkan juga untuk menulis semacam panduan ini dalam satu tulisan itu. Biasanya saya hanya menulis panduan semacam ini pada obrolan-obrolan di beberapa grup di Telegram. Repotnya, bila di kemudian hari ada yang minta tolong lagi untuk diajari silat aliran Git ini, mau tidak mau saya mesti menjelaskan ulang dan mem-forward obrolan-oborolan sebelumnya. Melelahkan. Okay, mari kita mulai. Silakan pasang kuda-kuda.
Eh, bentar. Perlu ada penyangkalan di awal, bahwa tulisan ini barangkali tidak akan selengkap dan sedetail panduan-panduan lain. Mengapa? Karena gol dari tulisan ini adalah teman-teman yang awam terhadap Git minimal jadi tahu dan dapat menggunakannya untuk berkontribusi ke pelbagai proyek. Bila mengininkan panduan yang lebih lengkap, silakan jalan-jalan ke tempat lain :")
Sangat saya sarankan untuk benar-benar meluangkan waktu 30-60 menit apabila sungguh-sungguh ingin mempelajari ini. Mengapa? Dari yang saya alami, belajar sejenak dengan fokus dan konsentrasi yang penuh akan lebih cepat membuahakan hasil :"). Eh, tapi ya bebas ding, terserah.
Apa dan Mengapa Git?
Ini adalah pertanyaan paling mendasar. Dengan menjawab dua pertanyaan ini memang tidak akan bimsalabim membuat kita bisa mengusai jurus-jurus di dunia persilatan Git. Namun, setidaknya dengan menemukan jawaban dua pertanyaan tersebut, kita jadi mendapat pemahaman dasar dan alasan mengapa kita memerlukan Git.
Linus Torvald, yang bikin Git, menjelaskan bahwa Git adalah the stupid content tracker. Ya, sederhananya memang itu. Git tak lain hanyalah tool/perkakas yang memungkinkan kita untuk memanajemen perubahan pada sebuah direktori atau berkas. Hmmm sulit dipahami ya? Gampangnya, gini deh. Coba bayangkan kita punya satu folder berisi berkas kenangan-kenangan bersama si dia. Nah suatu hari, kita ingin banget melihat perubahan-perubahan apa saja sih yang terjadi pada folder tersebut, apakah ada yang terhapus (mungkin pas berantem), apakah ada yang ditambah, atau dimodifikasi, dll. Setelah melihat-lihat, timbul hasrat tiba-tiba muncul keinginan untuk mengembalikan keadaan folder tersebut ke waktu-waktu tertentu. Nah, itu semua bisa dilakukan kalau folder kenanganmu tadi sudah dilengkapi dengan git. Paham?
Bahasa seriusnya, Git adalah perkakas untuk melakukan manajemen versi pada suatu proyek (proyek ini bayangin folder tadi). Pertanyaan selanjutnya, mengapa kita menggunakan Git? Bukankah hal seperti itu bisa juga dilakukan, misal dengan layanan Gdrive dan sejenisnya? Mungkin iya, tapi Git lebih dari itu.
Dengan menguasai kemampuan Git, banyak hal yang dapat kita lakukan. Selain soal memanajemen folder atau proyek tadi. Memang benar, pada mulanya Git ini seolah-olah hanya digunakan oleh orang-orang yang berkutat pada pembuatan perangkat lunak, alias programmer. Namun kenyataan tersebut kini sudah berubah. Git bisa dimanfaatkan untuk banyak hal, dari mulai membuat cadangan berkas, membuat static site seperti halaman yang sedang kamu baca ini, dan lain-lain.
Di dunia open source, Git memang sangatlah populer. Tak heran pula, kalau kemapuan per-Git-an ini bisa menjadi salah satu item tambahan yang bisa kamu tulis di CV-mu :“p. Terlepas dari itu semua, dengan memahami Git, kita dapat ikut aktif untuk berkontribusi ke banyak proyek sumber terbuka di seluruh penjuru dunia. Hal inilah yang akan menjadi orientasi utama dalam tulisan ini.
Istilah-isitlah Umum
Hal yang tidak bisa dihindari apabila kita ingin mempelajari sesuatu, tentu saja adalah memahami istilah-isitilah terkait hal yang akan kita pelajari tersebut. Pada bagian ini kita akan membahas satu demi satu istilah-istilah yang umum digunakan dalam dunia per-Git-an.
Repository
Repository (repo), atau bahasa gampangnya lumbung, merujuk pada tempat untuk menyimpan sesuatu. Istilah ini akan sering muncul karena sejatinya Git memang digunakan untuk melakukan menajemen versi pada lumbung ini. Setidaknya ada dua jenis lumbung yang harus dipahami, (1) Repository Online dan (2) Repositori Lokal.
Online Repository
Online Repository merupakan lumbung penyimpanan daring tempat kita menyimpan berkas-berkas pekerjaan atau kenangan yang kita miliki. Hingga saat ini, yang saya ketahui, ada dua layanan yang sangat populer dan banyak digunakan serta dipilih oleh para pengguna Git, Github dan Gitlab. Bayangan gampangnya, lumbung daring ini mirip-mirip seperti penyimpanan online kita. Lumbung daring ini juga terbagi menjadi dua jenis, pertama private repository dan public repository. Private repository artinya lumbung tersebut hanya dapat dilihat dan diakases oleh pemilik dan orang-orang yang mendapat izin dari pemilik. Sedangkan public repository dapat diakses oleh siapapun. Proyek-proyek open source umumnya menggunakan jenis ini agar semua orang dapat ikut berkontribusi ke dalam proyek tersebut. Lumbung daring ini memiliki URL atau alamat khusus untuk dirujuk oleh Local Repository.
Local Repository
Local Repository merupakan lumbung lokal yang berada di penyimpanan pada komputer kita. Lumbung lokal ini dapat kita ubah-ubah (hapus, modifikasi, tambah) sesuai dengan keinginan kita sebelum akhirnya nanti di-push ke lumbung daring. Mengapa lumbung ini harus ada? Simpel, biar mudah aja kalau mau ngedit-ngedit. Menurut kamu, mengapa kemudian layanan semacam Gdrive dan Dropbox, misalnya, menyediakan versi desktop untuk layanan mereka? Yaps, supaya lebih mudah kan :”) Kurang lebihnya seperti itu.
Repo lokal ini terhubung ke Online Repository melalui remote URL. Lengkapnya apa itu remote URL akan dibahas di bawah. Sebuah repo lokal bisa dihubungkan ke lebih dari satu Repository Online, tentang bagaimana caranya, kita bahas nanti. Sabar.
Upstream & Downstream
Istilah ini sejujurnya agak sulit saya jelaskan dengan sederhana. Saya ilustrasikan saja. Suatu hari, saya membuat sebuah repositori publik bernama “Kenangan masa SMP” di Github. Lalu, ternyata ada teman saya yang tertarik untuk menyalin repositori saya tersebut dan ingin ikut berkontribusi dengan menambahkan beberapa foto yang mungkin saya tidak punya. Nah, dalam konteks ini, repo yang saya buat adalah Repo Upstream (hulu) sedangkan repo-repo yang merupakan hasil salinan (fork, akan dijelaskan nanti) merupakan Repo Downstream (hilir).
Sebenarnya istilah ini hanya untuk menandai mana repo utama dalam sebuah proyek. Dalam konteks berkontribusi, alur dasar sebenarnya hanyalah sebatas (1) kita menyalin repo upstream, (2) membuat perubahan pada downstream, (3) mengirim lagi perubahan ke upstream. Dengan demikian repo upstream ini merupakan titik untuk mengumpulkan perubahan-perubahan yang dibuat oleh para kontributor.
Fork
Fork merupakan istilah yang digunakan untuk menyalin sebuah repo online milik orang lain ke akun yang kita miliki di sebuah layanan repository (Github atau Gitlab). Aturan mainnya seperti ini. Apabila kita ingin ikut berkontribusi ke sebuah proyek, maka kita memerlukan akses untuk membuat perubahan ke repo proyek tersebut. Nah, cara formal agar kita punya akses untuk membuat perubahan pada proyek tersebut adalah dengan menyalinnya terlebih dulu untuk dikerjakan “di rumah sendiri”.
Remote Url
Remote URL, merupakan alamat yang merujuk pada lokasi repo online kita berada. Remote URL inilah yang menguhubungkan repo lokal kita dengan repo online sehingga memungkinkan untuk mengirim perubahan yang sudah kita lakukan di lokal ke repo online atau mengambil perubahan yang ada di repo online untuk memperbarui repo lokal kita.
Jangan dipikir pusing dulu, ini tidak serumit itu kok, tenang aja. Nanti kita buktikan :"). Sebagaimana yang sempat disinggung sebelumnya, satu repo lokal sangat meungkin terhubung memiliki banyak remote URL yang terhubung ke beberapa repo online. Umumnya, apabila proyek yang kita kerjakan adalah proyek hasil fork, maka setidaknya kita memerlukan dua remote URL dalam repo lokal kita, remote url ke repo kita (hasil fork) sendiri dan remote url ke repo upstream. Namun, apabila kita hanya mengerjakan proyek personal, satu remote url saja sudah cukup.
Secara default, apabila kita melakukan clone pada sebuah repository, maka secara otomatis git akan membuat remote URL bernama origin
di repo lokal kita yang langsung terhubung ke repo online yang kita clone. Btw, nama dari remote URL ini bisa kita tentukan sesuai dengan keinginan.
Clone
Clone merupakan tindakan untuk menyalin repo online ke repo lokal. Gampangnya clone ini adalah proses untuk mengunduh repo online, udah gitu doank :"). Clone, kalau dipelajari lebih dalam, memiliki beberapa teknik khusus. Secara default, ketika kita menjalankan clone tanpa parameter apapun, maka secara otomatis git akan mengunduh semua berkas yang ada di repositori tanpa terkecuali. Namun dengan parameter-parameter tertentu, kita bisa memilih kategori tertentu saja untuk di clone ke lokal (komputer kita). Biar apa? Biar nggak ngabisin kuota aja sih, heuheu.
Push
Push atau dorong dalam dunia Git merupakan tindakan untuk mengirim perubahan yang telah kita buat di lokal ke repo online. Push tidak dapat dilakukan apabila kita tidak memiliki akses ke repositori tersebut, jadi dengan kata lain kita harus memiliki akses terlebih dulu ke repo yang akan kirimi perubahan. Itulah mengapa tadi perlu tindakan fork :"). Lalu, kalau misal kita ingin mengirim perubahan ke repo upstream gimana dong? Kan ga punya akses push ke sana. Tenang itu nanti akan ada pembahasannya lagi.
Pull
Kebalikan dari push, pull merupakan tindakan untuk menarik perubahan yang ada di repo online ke repo lokal. Apa bedanya dengan clone. Beda, kalau clone yang kita unduh adalah satu repositori utuh, sedang kalau pull hanyalah perubahan yang terjadi pada repo itu saja. Sederhananya, untuk melakukan pull, kita harus memiliki repo online di lokal (komputer) kita dulu.
Mengapa kita perlu melakukan pull? Gambarannya gini, kalau misal kita mengerjakan proyek kolaboratif sangatlah mungkin kalau repo upstream menerima banyak perubahan dari repo-repo downstream lainnya. Jika itu terjadi, maka repo yang telah kita fork/clone tadi akan menjadi tertingal alias tidak up to date lagi. Repo yang tidak up to date ini tidak bisa mengirimkan perubahan ke repo yang lebih baru. Oleh karena itu, kita perlu untuk menyamakan tingkatannya terlebih dahulu dengan cara menge-pull ke repo upstream. Dengan demikian, keadaan repo lokal kita akan setara (sama-sama update) dengan repo upstream.
Saya sarankan selalu lakukan pull terlebih dahulu ke repo upstream (apabila kamu berkolaborasi), sebelum membuat perubahan di repo lokalmu.
Commit
Commit merupakan bagian terpenting dalam sebuah hubungan. Commit merupakan titik untuk menandai perubahan-perubahan yang terjadi para repository kita. Commit berisi catatan-catatan tentang apa saja yang berubah di dalam sebuah repo. Titik commit inilah yang nantinya akan menjadi acuan apabila kita ingin mengembalikan repository ke keadaan tertentu. Di dalam sebuah commit, kita bisa menambahkan deskripsi/komentar singkat untuk mempermudah kita mengingat apa isi commit tersebut.
Deskripsi commit yang asal-asalan akan membuat kita kesulitan di kemudian hari, oleh karena itu dalam membuat deskripsi commit sangat saya sarankan untuk menggunakan kalimat yang singkat dan jelas. Misal “edit foto mantan”. Selain itu, saya sarankan untuk membuat catatan commit ini per kategori tindakan. Gimana tuh? Entar saya jelasin detailnya.
Branch
Branch atau cabang kalau dibayangkan mirip ke bilik-bilik khusus yang ada di dalam sebuah lumbung. Oke supaya lebih mudah dibayangkan. Misal kita punya repo private bernama “Kenangan Bersama Mantan”. Nah di dalam repo tersebut kita ingin agar kenangan bersama mantan ini terpisah-pisah, asumsinya kita punya 5 mantan. Maka yang harus kita lakukan adalah membuatkan cabang dari repo kenangan tersebut, sehingga data-data kenangan bersama mantan ini dapat disimpan secara terpisah.
Apa branch ini mirip folder? Bukan, branch lebih dari itu. Branch ini mirip repo tapi di dalam repo, tapi masih dalam satu kategori yang sama (modyar, mumet kan, hahaha). Pada praktik realnya, branch ini biasanya digunakan untuk membedakan kode tiap versi dari sebuah proyek. Apabila di github atau gitlab kamu menemukan tulisan dengan format Kenangan-Bersama-Mantan:Alisa
misalnya, itu berarti terdapat cabang bernama Alisa dalam repo Kenangan-Bersama-Mantan.
Secara umum, biasanya ketika kita membuat sebuah repositori atau melakukan clone terhadap repositori, kita akan diarahkan langsung ke branch bernama master
.
*tentang branch ini nanti akan kita bahas lagi di bawah.
Pull request (PR) dan Merge request (MR)
Nah, menjawab pertanyaan sebelumnya, bagaimana kita bisa membuat perubahan ke repo proyek yang kita tidak memiliki akses untuk push ke sana, jawabannya adalah dengan mengajukan Pull Request (Github) atau Merge Request (Gitlab). PR/MR ini merupakan istilah untuk mengajukan perubahan yang telah kita push ke repo online kita kepada pemilik proyek, mirip seperti kita mengajukan usulan lengkap dengan contoh lah. Nah, kalau usulan kita disetujui, maka perubahan yang kita buat akan di-merge oleh pemilik/pengelola proyek. Kalau misal tidak disetujui, ya nasib ahahaha. Tapi tenang, biasanya kalau tidak disetujui akan diberikan komentar kok.
Ada beberapa alasan mengapa PR/MR tidak disetujui/di-merge oleh pengelola. Misalnya, karena mungkin perubahan yang kamu ajukan tidak diperlukan, perubahan yang kamu ajukan ternyata konflik dengan repo yang ada, atau karena dendam dan pengen iseng aja.
Issue
Issue ini sebenarnya tidak masuk dalam pembahasan teknis Git, tapi sangat baik kalau paham juga dengan istilah satu ini, terutama bila kamu adalah seorang pemilik/pengelola proyek. Issue merupakan catatan yang dapat dibuat oleh siapa saja terkait temuan mereka di repo proyekmu. Jadi misal, di proyekmu ada sebuah bug/sejenisnya atau misal mereka me-request suatu fitur di proyekmu, nah catatan itu ditaruh di Issue ini.
Ada lagi?
Sebenarnya masih ada beberapa hal yang teknis yang belum dibahas, misalnya stash, manajemen konflik, dst. Namun untuk seorang pemula, saya rasa memahami isitilah-istilah di atas sudah sangat cukup untuk modal belajar.
Bagan Siklus Cara Kerja Git
Persiapan menggunakan git
Okay, sekarang kita mulai masuk ke pembahasan teknis. Beberapa perintah git, seperti pull, push, dan clone, memerlukan koneksi internet. Jadi pastikan koneksimu aman ketika menjalan perintah ini. Tidak, saya tidak mau bagi-bagi voucher internet, silakan urus sendiri. #apasih
Oiya, Git ini menggunakan antarmuka berupa Command Line Interface (CLI), alias perintah-perintahnya dijalankan di terminal. Emang nggak ada ya, Git yang GUI itu? Ada, tapi tidak masuk pembahasan di sini.
Memilih layanan repositori
Secara umum, ada dua layanan daring untuk menyimpan repositori Git yang populer dan sudah kita singgung tadi, Github dan Gitlab. Masing-masing memiliki kekurangan dan kelebihan. Silakan untuk membuat akun ke salah satu layanan tersebut sebelum lanjut ke langkah berikutnya.
Memasang git pada sistem
Git bisa dijalankan di berbagai sistem operasi, Linux, Mac, dan bahkan Windows. Cara pasang Git ini bergantung masing-masing sistem operasi. Untuk pengguna Debian dan turunannya, biasanya cukup dengan menjalankan perintah:
|
|
Distro dan OS lain? Silakan cari sendiri yak :")
Setup awal git pada sistem
Setelah Git terpasang, selanjutnya adalah melakukan setup pengguna. Setup ini biasanya hanya perlu dilakukan sekali saja. Setup pengguna diperlukan untuk memberikan identitas pada tiap commit yang nantinya dibuat. Silakan jalankan beberapa perintah berikut untuk melakukan setup.
|
|
Ganti usernamekamu dan [email protected] dengan data yang sesuai.
Menggunakan Git
Yai, akhirnya masuk ke pembahasan inti. Fiyuh, panjang juga ya ternyata tulisan ini. Bentar, rebahan dulu.
Yak, lanjut! Sebagaiamana yang telah dibahas di atas, Git dapat kita gunakan untuk memanajemen proyek pribadi maupun untuk ikut kontribusi ke proyek yang sudah ada. Secara umum sebenarnya hampir sama sih alurnya, hanya ada sedikit perbedaan di awal memulainya saja.
Memulai Sebuah Proyek
- git init
Untuk memulai sebuah proyek dengan Git, silakan buat sebuah folder baru. Untuk alasan kerapian, saya sangat menyarankan untuk mengumpulkan pekerjaan-perkerjaan Git dalam satu folder bernama git
di home. Oke, saya asumsikan kita akan membuat proyek baru di folder tersebut (/home/namauser/git). Folder-folder proyek ini selanjutnya akan saya sebut dengan istilah work directory (workdir) supaya lebih mudah.
```bash mkdir -p ~/git/kisah-baru cd ~/git/kisah-baru git init . ``` Ok, sekarang satu folder proyek sudah dibuat. Selanjutnya adalah membuat sebuah perubahan ke dalam folder tersebut. Misalnya dengan menambahkan sebuah berkas ke dalam kisah baru. Dalam contoh ini, saya akan menambahkan satu foto ke dalam folder tersebut.
- Melihat Status Workdir
Git dapat merekam setiap perubahan yang terjadi di dalam workdir. Secara umum perubahan yang terjadi di dalam workdir ini terbagi menjadi dua jenis status, perubahan yang untracked dan perubahan yang tracked. Aturan mainnya, tiap perubahan yang ada di dalam folder git haruslah berstatus tracked agar dapat di dorong ke repo online. Untuk dapat melihat status berkas-berkas tersebut, cukup jalankan perintah berikut ini;
|
|
Karena sebelumnya saya telah menabahkan satu berkas gambar bernama “alisa.png” maka, output dari perintah di atas, kurang lebih seperti gambar berikut ini.
Tampak di dalam daftar *untracked files* nama-nama berkas (sebenarnya itu daftar path) yang belum dimasukkan dalam catatan Git. Nah, tugas kita selanjutnya adalah mencatatkan berkas tersebut ke dalam git.
- git add
Tahap ini merupakan tahap kita memeritahukan kepada Git kalau kita telah menambah, menghapus, memindah, atau memodifikasi berkas atau folder di workdir. Kalau misal dikalimatkan menjadi bahasa manusia, “Git aku barusan tadi nambah file alisa.png ke tempatmu. Catat ya!”, kira-kira seperti itu. Silakan jalankan perintah berikut untuk memberitahu git terkait perubahan yang kita buat.
|
|
format perintah add ini adalah git add /path/ke/file/atau/folder
, silakan lihat gambar berikut untuk lebih jelasnya.
Wait, katanya path, kok contoh di atas setelah `add` langsung nama berkas? Ya, karena kita menambahkan berkas alisa.png tadi di root workdir. Apaan tuh root workdir? Gampangnya sih berkas itu tidak di simpan di dalam folder. Kalau semisal alisa.png kita simpan di folder bernama *foto*, maka perintahnya menjadi: ```bash git add foto/alisa.png ``` Pertanyaan selanjutnya, bagaimana kalau misal kita menambahkan banyak berkas sekaligus ke dalam workdir kita? Apa iya harus jalanin git add satu per satu ke masing-masing berkas? O, tentu tidak. Berikut beberapa pilihan untuk menajalankan git add beserta keterangannya.
git add --all
ataugit add -A
Mencatat semua perubahan secara sekaligus (nggak saya rekomendasiin sih) perintah di atas akan mencatat semua perubahan di semua berkas dan folder di workdir.
git add .
Mencatat semua perubahan yang terjadi direktori saat ini, jadi kalau kondisi terminalmu berada di direktori ~/home/username/git/kisah-baru, maka semua perubahan dalam folder tersebut akan otomatis tercatat. Namun bila kondisi terminalmu misal pindah ke folder foto yang ada di direktori kisah-baru, maka hanya perubahan di folder foto saja yang tercatat. Istilah benernya, parent work directory.
git add foto/* video/*
perintah di atas akan mencatat semua perubahan yang ada di folder foto dan folder video
git add foto/alisa.*
Perintah di atas akan menambah semua nama berkas yang memiliki kombinasi nama ‘alisa.’ dalam folder foto. Perintah ini berarti secara tidak langsung juga berarti menambah semua yang memiliki ekstensi apapun dengan syarat bagian depannya mengandung kata ‘alisa.’
git add foto/*.png
perintah untu mencatat perubahan pada semua berkas berformat png (dengan nama apapun) di dalam folder foto
Perintah git add ini bisa divariasikan sedemikian rupa. Ah iya, untuk mencatat penghapusan sebuah berkas atau folder, perintah add
silakan diganti dengan rm
. Ini opsional sih, karena kadang saya tetep pakai git add untuk mencatat penghapusan berkas, wkwk.
- Memeriksa Kembali Status Workdir
Nah, sampai di sini, ceritanya kita sudah mencatatkan perubahan pada workdir kita ke Git nih. Cara untuk memastikan bahwa perubahan kita sudah tercatat atau belum seperti apa ya? Gampang, jalankan ulang git status
. Jika langkahmu benar, maka output terminalnya kurang lebih akan seperti ini
Ya, berkas yang sebelumnya *untracked* dengan warna merah, sekarang sudah berganti jadi hijau alias *tracked*.
- git commit
Ini adalah tahapan paling penting, membuat commit. Seperti yang dijelaskan sebelumnya, informasi-informasi perubahan (dari git add/rm
tadi) haruslah disimpan dalam sebuah commit. Commit inilah yang nantinya akan menjadi titik acuan kalau kita hendak melakukan revert.
Berikut merupakan perintah untuk membuat commit:
|
|
untuk lebih jelasnya, perhatikan tangkapan layar berikut.
Seperti yang sempat saya bilang, usahakan untuk membuat deskripsi atau keterangan commit sejelas mungkin agar sewaktu-waktu bila ingin melakukan *revert* jadi lebih mudah. Perlu diingat, dalam satu commit bisa berisi banyak catatan perubahan. Catatan yang akan dijadikan commit ketika kita menjalankan perintah ini hanyalah daftar pada `git status` yang berwarna hijau saja, jadi misalnya nanti masih ada *untracked list* di `git status` dan kamu langsung menjalankan perintah commit, maka *untracked list* (yang warna merah) tidak akan masuk ke dalam catatan commit.
- git remote
Setelah semua perubahan di-commit, langkah selanjutnya adalah menambahkan remote URL ke workdir Git kita saat ini. Untuk mendapatkan remote URL, kamu harus membuat sebuah repo terlebih dahulu di layanan Github/Gitlab. Pertama, silakan login ke akun github/gitlab-mu. Dalam tulisan ini saya akan memberikan contoh membuat repo di Github.
Klik ikon tambah di kanan atas halaman Github. Kemudian, pilih, New Repository. Selanjutnya, silakan lengkapi isian yang diminta.
Klik Create Repository apabila telah selesai. Pada halaman selanjutnya, kamu akan mendapatkan remote URL yang nantinya harus ditambahkan untuk menghubungkan repositori lokal dengan repo *online* di Github.
Remote URL terbagi menjadi dua jenis, yakni https dan ssh. Untuk contoh di sini, kita menggunakan https saja, karena untuk menggunakan remote ssh, perlu konfigurasi khusus, semoga nanti dikesempatan lain bisa kita bahas juga. Silakan salin remote URL yang ditampilkan. Dalam tangkapan di atas, remote URL saya adalah `https://github.com/raniaamina/kisah-baru.git`. Setelah disalin, kita kembali ke terminal lagi. Jalankan perintah berikut untuk menambahkan remote URL: ```bash # format perintah `git add namaremote remoteURL` git remote add rania https://github.com/raniaamina/kisah-baru.git ``` Untuk mengecek apakah remote URL sudah berhasil di tambahkan atau belum, silakan jalakan perintah ```bash git remote -v ``` Berikut tangkapan layar ketika telah menjalankan perintah-perintah di atas.
- git push
Yai, sekarang saatnya untuk mengirim perubahan yang telah kita buat di repo lokal ke repo online. Bisa dibilang ini adalah langkah terakhir untuk tahapan ini. Silakan jalankan perintah ini untuk melakukan push.
|
|
Dalam contoh ini kita mendorong repo lokal kita ke sebuah cabang di di repo online bernama master. Silakan tunggu hingga proses selesai. Berikut tangkapan layar bila proses push berhasil.
Berikut tangkapan layar ketika telah menjalankan perintah-perintah di atas.
Sebagai catatan, bila tadi Anda mencentang “add readme” ketika membuat repo di Github, maka sebelum melakukan git push
, harap lakukan git pull
terlebih dahulu. Detail perintah pull akan saya masukkan ke pembahasan pada langkah-langkah berkontribusi di bawah.
- Mengecek Hasil Push
Sampai pada tahap di atas, sebenarnya penduan memulai sebuah proyek sudah selesai. Silakan lihat ke repo Github apabila masih merasa belum yakin. Tada! Repo lokalmu sudah berhasil didorong. Untuk selanjutnya (update-update repo), kamu tak perlu lagi menjalankan perintah git init dan git remote add (kecuali memang mau menambah remote URL).
Berkontribusi ke Sebuah Proyek
Pada panduan sebelumnya, kita telah membahas langkah demi langkah memulai sebuah proyek dengan Git. Pada tahap ini, kita akan membahas langkah demi langkah apabila kita hendak berkontribusi ke sebuah proyek yang menggunakan Git.
Sebagai contoh, saya menggunakan repositori Gimpscape yang beralamat di: https://github.com/gimpscape/open-palette. Kontribusi yang ingin saya berikan pada repo ini misalnya adalah melengkapi tulisan pada berkas README.md.
Perlu diperhatikan, untuk perintah-perintah yang sudah di bahas pada panduan sebelumnya, tidak akan secara spesifik saya bahas pada langkah ini. Jadi, pastikan kamu sudah benar-benar memahami konsep yang saya sampaikan pada tiap-tiap langkah di panduan di atas.
- Melakukan Forking Repositori
Pertama silakan buka terlebih dahulu repo Github/Gitlab yang ingin fork. Dalam contoh ini, kita menggunakan repo: open-pallete. Tombol fork ada di kanan atas halaman tersebut. Klik Fork dan pilih akun Github kamu sebagai tujuan fork. Tunggu hingga proses selesai, dan yai! sekarang kamu sudah punya salinan repo open-palette milik Gimpscape.
- git clone
Sebagaimana sebelumnya, saya pun akan menyimpan folder repo ini dalam direktori git yang telah kita buat di awawl. Silakan jalankan perintah berikut untuk melakukan clone.
|
|
Lokasi folder dalam perintah di atas bisa ditentukan secara bebas oleh pengguna. Andai tidak ditentukan (hanya git clone remoteURL
), Git akan secara otomatis memberikan nama folder sesuai dengan nama repo.
Berikut tangkapan layar apabila proses clone berhasil.
- Membuat Perubahan pada Workdir
Dalam contoh ini, saya akan membuat perubahan pada berkas README.md. Silakan sesuaikan dengan keperluan kamu yak :")
- Melihat Status Workdir
Sama seperti panduan sebelumnya, gunakan perintah git status
untuk memeriksa mana saja untracked files yang nantinya perlu dicatatkan ke Git.
- git pull
Perintah pull ini sangat saya sarankan untuk dilakukan secara berkala apabila yang sedang kamu kerjakan adalah proyek kolaboratif. Mengapa? Karena bisa saja ada orang lain yang juga mengirimkan perubahan dan telah di merge oleh pemilik proyek. Sehingga kamu perlu mendapatkan pembaruan kondisi workdir agar nantinya tidak terjadi masalah apabila mengirim Pull Request.
Untuk dapat melakukan menarik (pull) ke repo upstream (repo utama yang kamu fork tadi), maka kamu perlu menambahkan remote URL repo tersebut. Silakan jalankan remote add
sebagaimana yang telah dijelaskan sebelumnya.
Tangkapan layar di atas merupakan *output* setelah saya menjalakan `git remote add` dan `git remote -v`. Remote URL repo upstream saya beri nama gimpscape. Dengan demikian perintah untuk melakukan pull ke repo tersebut adalah ```bash # format perintah pull: "git pull namaremote namacabang" git pull gimpscape master ``` Detail tentang cabang ini dapat dilihat di repo github di dekat tombol "New Pull Request".
Apabila sudah dinyatakan *up to date* seperti tangkapan layar di atas, maka mari kita lanjut ke langkah berikutnya.
- git add & git commit
Silakan catat perubahan-perubahan yang telah dibuat dengan menjalankan git add sebagaimana yang telah dijelaskan sebelumnya. Sekadar penekanan, kamu tidak mencatat semua perubahan sekaligus apabila ingin membedakan catatan commitnya. Ilustrasinya seperti ini. Kamu menambah folder foto dan video di workdir. Nah, apabila ingin membedakan catatan commit untuk foto dan video maka langkah-langkannya adalah:
git add folder-foto/*
git commit -m "add photos"
git add folder-video/*
git commit -m "add videos"
Dengan demikian kamu akan mempunyai dua catatan commit yang berbeda. Namun apabila hanya ingin membuat satu commit saja untuk mencatat semua perubahan, bisa menggunakan langkah yang telah dijelaskan sebelumnya.
- git push
Setelah semua perubahan di-commit, maka sekarang saatnya untuk mendorong perubahan pada repo lokal ke repo di Github. Repo lokal ini akan kita dorong ke Github kita sendiri, alias repo hasil Fork. Mengapa? Karena dalam kasus ini kita tidak memiliki akses untuk dapat push langsung ke repo upstream (gimpscape). Sesuai dengan list remote URL di atas, maka perintah pushnya adalah
|
|
Tunggu hingga proses selesai.
- Membuat Pull Request
Apabila telah selesai melakukan push. Silakan buka repo Githubmu. Kemudian klik tombol “New pull request” sehingga kamu akan diarahkan ke halaman berikut.
Apabila tombol di halaman tersebut berwarna hijau sebagaimana tangkapan layar di atas, maka itu berarti perubahan yang kamu buat tidak mengalami konflik dengan repo yang di-fork. Klik tombol tersebut sehingga memunculkan kolom isian. Ibarat sebuah proposal, pull request juga memerlukan judul dan keterangan yang baik dan jelas, silakan isi. Jika sudah, klik tombol Create Pull Request dan selesai! Yang penting untuk dipahami adalah tidak semua Pull Request akan diterima, jadi nggak perlu baper kalau ditolak atau dikacangin lama banget oleh pemilik/pengelola proyek. Namanya juga *ngajuin* proposal, kan bisa diterima bisa aja ditolak. --pukpukpuk
Sekilas Tentang Branch
Pembahasan tentang branch ini sebenarnya tidak untuk pemula sih, tapi tentu akan lebih baik kalau minimal kita memahami konsep branch ini. Saya ilustrasikan repositori adalah sebuah rumah, maka branch ini adalah kamar-kamar atau ruangan-ruangan di dalam rumah tersebut. Masing-masing kamar bebas diisi dengan perbotan yang berbeda-beda sesuai dengan kebutuhan. Nah, perabot ini merupakan folder dan berkas yang ada dalam repositori.
Dengan demikian, apabila sebuah repositori memiliki lebih dari satu branch, maka semisal kita ingin berkontribusi ke repo tersebut, kita harus tahu mana “kamar” yang akan kita renovasi (baca modfikasi). Setelah melakukan renovasi, maka ketika kita ingin mengirim perubahan tersebut ke repo online, maka tujuan push atau Pull Request pun harus diarahkan ke branch yang sesuai. Akan jadi sangat tidak sesuai apabila kita menaruh perabot-perabot kamar mandi di ruang makan. Iya nggak?
Untuk berpindah-pindah antarcabang biasanya saya menggunakan perintah
|
|
Untuk membuat cabang baru, ada beberapa perintah yang dapat dipilih
|
|
Fungsi lain dari fitur branch dari git ini, untuk saya, adalah bisa dijadikan tools untuk menyembunyikan berkas atau direktori dari orang yang tidak paham git, huehehe.
Sekilas Tentang Konsep Revert, dan Reset
Seperti disinggung di awal tulisan, dengan menggunakan Git kita bisa mengembalikan berkas atau direktori di workdir kita ke keadaan tertentu sesuai dengan catatan pada commit yang kita buat. Perintah revert dan reset ini dapat digunakan untuk mencapai tujuan tersebut. Berikut gambaran singkat tentang perintah tersebut.
-
git revert
git revert
digunakan untuk membuat sebuah commit baru yang berisi pembatalan perubahan dari commit sebelumnya. Gampangnya sih, ini kaya fitur undo commit gitulah.
-
git reset
Perintah git reset
ini yang menurut saya agak kompleks sih, karena dengan perintah ini kita dapat mengembalikan keadaan workdir ke keadan commit yang kita inginkan tanpa menambah commit baru sebagaimana perintah revert. Gambaran ekstrimnya sih, bisa digunakan untuk mengembalikan kondisi workdir bahkan seperti ketika pertama dibuat. Sayangnya ketika kita menggunakan perintah ini, kalau misal terjadi sesuatu kita tidak bisa lagi kembali ke keadaan sebelumnya karena begitu perintah ini dijalankan Git akan mengapus catatan-catatan commit yang ada setelah titik commit yang kita pilih.
Prasyarat untuk menggunakan kedua perintah di atas adalah harus tahu kode hash dari commit yang kita buat. Hah? Apa itu?
Jadi gini, ketika kita membuat commit, Git secara otomatis akan membuat kode hash guna menandai commit kita tersebut. Silakan cek dengan perintah git log
bila ingin melihat riwayat commit lengkap dengan kode hash yang menyertainya.
Penutup
Fyuh, panjang ya? Wkwkwk, maafin saya juga nggak nyangka bakal sepanjang ini. Anyway, kira-kira itulah materi dasar yang mesti dipahami oleh siapapun yang ingin belajar Git. Kalau hanya baca, saya yakin akan terkesan *njlimet *dan membingungkan, namun percayalah sesungguhnya ini mudah dan “cuma gitu-gitu aja” kok.
Kalau masih kesulitan, silakan berkabar via kolom komentar atau japri via Telegram, akan saya bantu semampu saya :")
Terima kasih
Git untuk Pemula