Penggunaan Git sebagai Version Control (Tutorial Menggunakan Git)

 

VERSION CONTROL

(Tutorial Menggunakan Git & GitHub )

1. Tentang Kontrol Versi (Versioning Control )

Apa yang dimaksud dengan "kontrol versi", dan mengapa Anda harus peduli? Kontrol versi adalah sistem yang mencatat perubahan pada suatu berkas atau sekumpulan berkas dari waktu ke waktu sehingga Anda dapat mengingat versi tertentu nanti. Untuk contoh-contoh dalam buku ini, Anda akan menggunakan kode sumber perangkat lunak sebagai berkas yang dikontrol versinya, meskipun pada kenyataannya Anda dapat melakukannya dengan hampir semua jenis berkas di komputer.

Jika Anda seorang desainer grafis atau web dan ingin menyimpan setiap versi gambar atau tata letak (yang tentunya Anda inginkan), Sistem Kontrol Versi (VCS) adalah hal yang sangat bijaksana untuk digunakan. Sistem ini memungkinkan Anda untuk mengembalikan file yang dipilih ke keadaan sebelumnya, mengembalikan seluruh proyek ke keadaan sebelumnya, membandingkan perubahan dari waktu ke waktu, melihat siapa yang terakhir kali memodifikasi sesuatu yang mungkin menyebabkan masalah, siapa yang memperkenalkan masalah dan kapan, dan banyak lagi. Menggunakan VCS juga secara umum berarti bahwa jika Anda mengacaukan sesuatu atau kehilangan file, Anda dapat dengan mudah memulihkannya. Selain itu, Anda mendapatkan semua ini dengan biaya overhead yang sangat sedikit.

1.1. Sistem Kontrol Versi Lokal

Banyak orang memilih metode kontrol versi dengan menyalin file ke direktori lain (mungkin direktori dengan cap waktu, jika mereka pintar). Pendekatan ini sangat umum karena sangat sederhana, tetapi juga sangat rawan kesalahan. Sangat mudah untuk lupa direktori tempat Anda berada dan secara tidak sengaja menulis ke file yang salah atau menyalin file yang tidak Anda inginkan.

Untuk mengatasi masalah ini, sejak lama programmer mengembangkan VCS lokal yang memiliki basis data sederhana yang menyimpan semua perubahan pada file di bawah kendali revisi.

Gambar 1. Diagram kontrol versi lokal

Salah satu alat VCS yang paling populer adalah sistem yang disebut RCS, yang masih didistribusikan di banyak komputer saat ini. RCS bekerja dengan menyimpan kumpulan patch (yaitu, perbedaan antar file) dalam format khusus di disk; kemudian dapat membuat ulang tampilan file apa pun pada suatu waktu dengan menambahkan semua patch.

1.2. Sistem Kontrol Versi Terpusat

Masalah utama berikutnya yang dihadapi orang adalah mereka perlu berkolaborasi dengan pengembang di sistem lain. Untuk mengatasi masalah ini, Sistem Kontrol Versi Terpusat (CVCS) dikembangkan. Sistem ini (seperti CVS, Subversion, dan Perforce) memiliki satu server yang berisi semua file yang memiliki versi, dan sejumlah klien yang memeriksa file dari tempat terpusat tersebut. Selama bertahun-tahun, ini telah menjadi standar untuk kontrol versi.

Gambar 2. Diagram kontrol versi terpusat

Pengaturan ini menawarkan banyak keuntungan, terutama dibandingkan dengan VCS lokal. Misalnya, setiap orang mengetahui sampai tingkat tertentu apa yang dilakukan orang lain dalam proyek tersebut. Administrator memiliki kendali yang sangat ketat atas siapa yang dapat melakukan apa, dan jauh lebih mudah untuk mengelola CVCS daripada menangani basis data lokal pada setiap klien.

Namun, pengaturan ini juga memiliki beberapa kelemahan serius. Yang paling jelas adalah satu titik kegagalan yang diwakili oleh server terpusat. Jika server tersebut mati selama satu jam, maka selama jam tersebut tidak ada seorang pun yang dapat bekerja sama sama sekali atau menyimpan perubahan versi pada apa pun yang sedang mereka kerjakan. Jika hard disk tempat basis data pusat berada rusak, dan cadangan yang tepat belum disimpan, Anda benar-benar kehilangan segalanya — seluruh riwayat proyek kecuali snapshot tunggal apa pun yang kebetulan dimiliki orang-orang di mesin lokal mereka. VCS lokal mengalami masalah yang sama — setiap kali Anda memiliki seluruh riwayat proyek di satu tempat, Anda berisiko kehilangan semuanya.

1.3. Sistem Kontrol Versi Terdistribusi

Di sinilah Distributed Version Control Systems (DVCS) berperan. Dalam DVCS (seperti Git, Mercurial atau Darcs), klien tidak hanya memeriksa snapshot terbaru dari file; melainkan, mereka sepenuhnya mencerminkan repositori, termasuk riwayat lengkapnya. Jadi, jika ada server yang mati, dan sistem ini berkolaborasi melalui server tersebut, salah satu repositori klien dapat disalin kembali ke server untuk memulihkannya. Setiap klon sebenarnya adalah cadangan penuh dari semua data.

Gambar 3. Diagram kontrol versi terdistribusi

Lebih jauh lagi, banyak dari sistem ini dapat bekerja dengan baik dengan beberapa repositori jarak jauh, sehingga Anda dapat berkolaborasi dengan berbagai kelompok orang dengan cara yang berbeda secara bersamaan dalam proyek yang sama. Hal ini memungkinkan Anda untuk menyiapkan beberapa jenis alur kerja yang tidak mungkin dilakukan dalam sistem terpusat, seperti model hierarkis.

2. Memulai - Apa itu Git?

Jadi, apa itu Git secara singkat? Ini adalah bagian penting untuk dipahami, karena jika Anda memahami apa itu Git dan dasar-dasar cara kerjanya, maka menggunakan Git secara efektif mungkin akan jauh lebih mudah bagi Anda. Saat Anda mempelajari Git, cobalah untuk menjernihkan pikiran Anda dari hal-hal yang mungkin Anda ketahui tentang VCS lain, seperti CVS, Subversion, atau Perforce — dengan melakukan hal itu akan membantu Anda menghindari kebingungan kecil saat menggunakan alat tersebut. Meskipun antarmuka pengguna Git cukup mirip dengan VCS lain ini, Git menyimpan dan memikirkan informasi dengan cara yang sangat berbeda, dan memahami perbedaan ini akan membantu Anda menghindari kebingungan saat menggunakannya.

2.1. Gambaran Singkat, Bukan Perbedaan

Perbedaan utama antara Git dan VCS lainnya (termasuk Subversion dan sejenisnya) adalah cara Git memikirkan datanya. Secara konseptual, sebagian besar sistem lain menyimpan informasi sebagai daftar perubahan berbasis berkas. Sistem-sistem lain ini (CVS, Subversion, Perforce, dan sebagainya) menganggap informasi yang mereka simpan sebagai sekumpulan berkas dan perubahan yang dibuat pada setiap berkas dari waktu ke waktu (ini umumnya digambarkan sebagai kontrol versi berbasis delta ).

Gambar 4. Menyimpan data sebagai perubahan pada versi dasar setiap file

Git tidak memikirkan atau menyimpan datanya dengan cara ini. Sebaliknya, Git menganggap datanya lebih seperti serangkaian snapshot dari sistem berkas mini. Dengan Git, setiap kali Anda melakukan commit, atau menyimpan status proyek Anda, Git pada dasarnya mengambil gambar seperti apa semua berkas Anda pada saat itu dan menyimpan referensi ke snapshot tersebut. Agar efisien, jika berkas tidak berubah, Git tidak menyimpan berkas itu lagi, hanya tautan ke berkas identik sebelumnya yang telah disimpan. Git menganggap datanya lebih seperti aliran snapshot .

Gambar 5. Menyimpan data sebagai snapshot proyek dari waktu ke waktu

Ini adalah perbedaan penting antara Git dan hampir semua VCS lainnya. Hal ini membuat Git mempertimbangkan kembali hampir setiap aspek kontrol versi yang disalin oleh sebagian besar sistem lain dari generasi sebelumnya. Hal ini membuat Git lebih seperti sistem berkas mini dengan beberapa alat yang sangat canggih yang dibangun di atasnya, bukan sekadar VCS. Kami akan membahas beberapa manfaat yang Anda peroleh dengan memikirkan data Anda dengan cara ini saat kami membahas percabangan Git dalam Percabangan Git .

2.2. Hampir Setiap Operasi Bersifat Lokal

Sebagian besar operasi di Git hanya memerlukan berkas dan sumber daya lokal untuk beroperasi — umumnya tidak diperlukan informasi dari komputer lain di jaringan Anda. Jika Anda terbiasa dengan CVCS di mana sebagian besar operasi memiliki latensi jaringan yang tinggi, aspek Git ini akan membuat Anda berpikir bahwa dewa kecepatan telah memberkati Git dengan kekuatan yang luar biasa. Karena Anda memiliki seluruh riwayat proyek di sana di disk lokal Anda, sebagian besar operasi tampak hampir seketika.

Misalnya, untuk menelusuri riwayat proyek, Git tidak perlu pergi ke server untuk mendapatkan riwayat dan menampilkannya untuk Anda — Git cukup membacanya langsung dari basis data lokal Anda. Ini berarti Anda dapat melihat riwayat proyek hampir seketika. Jika Anda ingin melihat perubahan yang terjadi antara versi berkas saat ini dan berkas sebulan yang lalu, Git dapat mencari berkas sebulan yang lalu dan melakukan kalkulasi selisih lokal, alih-alih harus meminta server jarak jauh untuk melakukannya atau menarik versi lama berkas dari server jarak jauh untuk melakukannya secara lokal.

Ini juga berarti bahwa sangat sedikit yang tidak dapat Anda lakukan jika Anda sedang offline atau tidak terhubung ke VPN. Jika Anda naik pesawat atau kereta api dan ingin melakukan sedikit pekerjaan, Anda dapat dengan senang hati melakukan komitmen (pada salinan lokal Anda , ingat?) hingga Anda mendapatkan koneksi jaringan untuk mengunggah. Jika Anda pulang dan tidak dapat menjalankan klien VPN Anda dengan benar, Anda masih dapat bekerja. Di banyak sistem lain, melakukan hal itu tidak mungkin atau menyakitkan. Di Perforce, misalnya, Anda tidak dapat melakukan banyak hal saat Anda tidak terhubung ke server; di Subversion dan CVS, Anda dapat mengedit file, tetapi Anda tidak dapat melakukan komitmen perubahan ke basis data Anda (karena basis data Anda offline). Ini mungkin tidak tampak seperti masalah besar, tetapi Anda mungkin terkejut melihat betapa besar perbedaan yang dapat dibuatnya.

2.3. Git Memiliki Integritas

Segala sesuatu di Git diceksum sebelum disimpan dan kemudian dirujuk oleh checksum tersebut. Ini berarti mustahil untuk mengubah isi berkas atau direktori apa pun tanpa sepengetahuan Git. Fungsionalitas ini dibangun di Git pada level terendah dan merupakan bagian integral dari filosofinya. Anda tidak akan kehilangan informasi saat transit atau berkas rusak tanpa Git dapat mendeteksinya.

Mekanisme yang digunakan Git untuk checksumming ini disebut hash SHA-1. Ini adalah string 40 karakter yang terdiri dari karakter heksadesimal (0–9 dan a–f) dan dihitung berdasarkan isi struktur berkas atau direktori di Git. Hash SHA-1 terlihat seperti ini:

24b9da6552252987aa493b52f8696cd6d3b00373

Anda akan melihat nilai hash ini di mana-mana di Git karena sangat sering menggunakannya. Faktanya, Git menyimpan semuanya di basis datanya bukan berdasarkan nama berkas, melainkan berdasarkan nilai hash dari isinya.

2.4. Git Umumnya Hanya Menambahkan Data

Saat Anda melakukan tindakan di Git, hampir semuanya hanya menambahkan data ke basis data Git. Sulit untuk membuat sistem melakukan sesuatu yang tidak dapat dibatalkan atau membuatnya menghapus data dengan cara apa pun. Seperti halnya VCS apa pun, Anda dapat kehilangan atau mengacaukan perubahan yang belum Anda komit, tetapi setelah Anda mengkomit snapshot ke Git, sangat sulit untuk kehilangannya, terutama jika Anda secara teratur memindahkan basis data Anda ke repositori lain.

Hal ini membuat penggunaan Git menyenangkan karena kami tahu kami dapat bereksperimen tanpa risiko mengacaukan banyak hal. Untuk melihat lebih dalam tentang bagaimana Git menyimpan datanya dan bagaimana Anda dapat memulihkan data yang tampaknya hilang, lihat Membatalkan Sesuatu .

Tiga Negara

Perhatikan sekarang — berikut adalah hal utama yang perlu diingat tentang Git jika Anda ingin proses pembelajaran Anda berjalan lancar. Git memiliki tiga status utama tempat file Anda dapat berada: modified , staged , dan committed :

• Dimodifikasi berarti Anda telah mengubah berkas tetapi belum mengirimkannya ke basis data Anda.
• Dipentaskan berarti Anda telah menandai berkas yang dimodifikasi dalam versi saat ini untuk dimasukkan ke dalam snapshot komit Anda berikutnya.
• Berkomitmen berarti bahwa data tersimpan dengan aman di basis data lokal Anda.

Ini membawa kita ke tiga bagian utama proyek Git: pohon kerja, area pementasan, dan direktori Git.

Gambar 6. Pohon kerja, area pementasan, dan direktori Git

Pohon kerja adalah satu pemeriksaan tunggal dari satu versi proyek. File-file ini diambil dari basis data terkompresi dalam direktori Git dan ditempatkan pada disk untuk Anda gunakan atau modifikasi.

Area staging adalah berkas, yang umumnya terdapat di direktori Git Anda, yang menyimpan informasi tentang apa yang akan dimasukkan ke dalam commit Anda berikutnya. Nama teknisnya dalam bahasa Git adalah “indeks”, tetapi frasa “staging area” juga berfungsi dengan baik.

Direktori Git adalah tempat Git menyimpan metadata dan basis data objek untuk proyek Anda. Ini adalah bagian terpenting dari Git, dan inilah yang disalin saat Anda mengkloning repositori dari komputer lain.

Alur kerja dasar Git berjalan seperti ini:

1. Anda memodifikasi berkas di pohon kerja Anda.
2. Anda secara selektif mementaskan hanya perubahan-perubahan yang Anda inginkan menjadi bagian dari komitmen Anda berikutnya, yang hanya menambahkan perubahan-perubahan tersebut ke area pementasan.
3. Anda melakukan komit, yang mengambil berkas sebagaimana adanya di area pementasan dan menyimpan cuplikan itu secara permanen ke direktori Git Anda.

Jika versi tertentu dari suatu berkas ada di direktori Git, maka berkas tersebut dianggap commited . Jika berkas tersebut telah dimodifikasi dan ditambahkan ke staging area, maka berkas tersebut disebut staged . Dan jika berkas tersebut diubah sejak diperiksa tetapi belum disebut staged, maka berkas tersebut disebut modified . Dalam Dasar-Dasar Git , Anda akan mempelajari lebih lanjut tentang status-status ini dan bagaimana Anda dapat memanfaatkannya atau melewati bagian staged sepenuhnya.

3. Memulai - Menginstal Git

3.1. Download Git

Silakan buka website resminya Git ( git-scm.com. Kemudian unduh Git sesuai dengan arsitektur komputer kita. Kalau menggunakan 64bit, unduh yang 64bit. Begitu juga kalau menggunakan 32bit.

3.2. Langkah-langkah Install Git di Windows

Baiklah, mari kita mulai ritual instalnya. Silakan klik 2x file instaler Git yang sudah diunduh.

3.3. Verifikasi Instalasi Git

Setelah Git terpasang, pastikan Git telah terinstal dengan benar dengan menjalankan:

Setelah Terpasang coba cek versi Git dengan menjalankan "git --version di terminal anda.

4. Pengaturan Awal Git

4.1. Konfigurasi Git

Setelah instalasi, Anda perlu mengonfigurasi informasi pengguna di Git:

Perintah --global berarti pengaturan ini akan berlaku untuk semua repositori Git di komputer Anda.

Setelah instalasi adalah untuk menyetel identitas pengguna Anda, seperti nama dan alamat email, yang akan dikaitkan dengan setiap perubahan (commit) yang Anda buat di Git.

Git menggunakan informasi ini untuk melacak siapa yang membuat perubahan pada repositori, sehingga setiap perubahan bisa diketahui siapa yang melakukannya. Informasi ini sangat penting terutama saat bekerja dalam tim atau mengelola banyak repositori.

5. Membuat Repositori Git

5.1. Membuat Direktori untuk Proyek

Buat folder baru untuk proyek Anda, misalnya Project_Baru:

mkdir project_baru maksudnya adalah membuat sebuah folder baru di komputer Anda untuk menyimpan semua file dan data yang terkait dengan proyek tersebut. Direktori atau folder ini akan menjadi tempat Anda menyimpan seluruh kode sumber, file konfigurasi, dan berkas lain yang diperlukan untuk proyek.

Misalnya, jika Anda membuat proyek baru bernama "Project_Baru", Anda dapat membuat sebuah folder dengan nama tersebut untuk mengorganisasi file-file yang ada.

5.2. Inisialisasi Repositori Git

Inisialisasi repositori Git di dalam folder proyek:

Inisialisasi repositori Git di dalam folder proyek berarti Anda akan mengonfigurasi folder tersebut agar Git dapat melacak perubahan yang Anda buat pada file-file di dalamnya. Dengan melakukan inisialisasi repositori Git, Anda membuat folder tersebut menjadi "repositori Git", yang memungkinkan Anda menggunakan fitur Git seperti commit, branch, dan lainnya.

6. Menambahkan dan Mengelola File

6.1. Menambahkan File Baru

Buat file baru di dalam folder proyek, misalnya index.html

"Menambahkan File Baru" adalah membuat sebuah file baru di dalam folder proyek yang telah Anda buat sebelumnya. File tersebut nantinya akan berisi kode atau data yang Anda gunakan untuk proyek Anda. Dalam contoh ini, Anda diminta untuk membuat sebuah file bernama index.html, yang biasanya digunakan untuk menyimpan kode HTML (struktur dasar halaman web).


6.2. Menambahkan File ke Staging Area

Tambahkan file yang telah Anda buat ke staging area:

"Menambahkan File ke Staging Area" adalah untuk menyiapkan file yang telah Anda buat atau ubah, agar Git dapat melacak perubahan tersebut dan memasukkannya ke dalam commit berikutnya.

Di Git, ada dua langkah utama dalam menyimpan perubahan:

1. Staging (Memasukkan ke Staging Area): Anda memilih file yang ingin Anda masukkan ke dalam commit, dan file tersebut ditempatkan di "staging area" (area persiapan).

2. Committing: Setelah file berada di staging area, Anda membuat commit, yang menyimpan perubahan tersebut secara permanen dalam riwayat proyek.

Mengapa Staging Area itu Penting?

Staging area memberi Anda kesempatan untuk memilih perubahan mana yang ingin Anda masukkan dalam commit, memungkinkan Anda untuk mengorganisir dan mengelola perubahan dengan lebih teratur. Anda bisa menambahkan satu file, beberapa file, atau bahkan hanya bagian tertentu dari file sebelum membuat commit.

6.3. Commit Perubahan

Setelah file ditambahkan, lakukan commit pertama:

Apa itu Commit?

Commit di Git adalah snapshot atau salinan dari file-file yang ada di staging area pada saat tertentu. Commit berfungsi untuk melacak perubahan dalam proyek dari waktu ke waktu, dan setiap commit memiliki identitas unik (ID commit) serta pesan yang menjelaskan perubahan apa yang dilakukan.

Setiap kali Anda melakukan commit, Git menyimpan status proyek pada waktu tertentu, sehingga Anda bisa melacak, membandingkan, atau kembali ke versi sebelumnya dari proyek jika diperlukan.

7. Membuat dan Menghubungkan Repositori ke GitHub

7.1. Membuat Repositori di GitHub

• Buka GitHub.
• Klik tombol New untuk membuat repositori baru.
• Beri nama repositori, misalnya Project_Baru, dan pilih apakah repositori bersifat public atau private.

 

 

7.2. Menambahkan Remote ke GitHub

Setelah repositori GitHub dibuat, Anda perlu menghubungkannya ke repositori lokal. Gunakan URL repositori GitHub Anda:

"Menambahkan Remote ke GitHub" adalah menghubungkan repositori Git yang ada di komputer lokal (yang telah Anda buat dan inisialisasi sebelumnya) dengan repositori yang ada di GitHub, sehingga Anda bisa mengirim (push) dan mengambil (pull) perubahan antara keduanya.

Setelah Anda membuat repositori di GitHub, Anda perlu memberi tahu Git di komputer lokal Anda tentang lokasi repositori di GitHub (ini disebut "remote"). Remote adalah repositori yang berada di server (misalnya GitHub), sedangkan repositori lokal ada di komputer Anda.

8. Push ke GitHub

8.1. Push Commit ke GitHub

Jika Anda menggunakan branch master, gunakan:

"Push Commit ke GitHub" adalah mengirimkan perubahan yang telah Anda simpan di repositori lokal ke repositori yang ada di GitHub, sehingga perubahan tersebut dapat terlihat dan diakses di repositori online Anda.

Branch (atau cabang) adalah bagian penting dalam Git yang memungkinkan Anda bekerja pada fitur baru atau perbaikan tanpa mengubah bagian utama dari proyek. Secara default, Git membuat cabang master (sekarang sering diganti dengan nama main) untuk cabang utama. Ketika Anda melakukan commit di repositori lokal, Anda perlu mengirimkan (push) commit tersebut ke repositori GitHub pada cabang yang sesuai.

Mengapa Branch itu Penting?

• Branch master (atau main) adalah cabang default yang sering digunakan untuk kode yang stabil atau siap untuk diproduksi.
• Anda bisa membuat cabang lain untuk fitur baru atau eksperimen, namun master/main biasanya digunakan untuk versi stabil dari proyek.

8.2. Periksa di GitHub

Buka repositori di GitHub dan pastikan file index.html Anda sudah ter-upload dengan benar.

Dengan Tutorial sederhana di atas mudah-mudahan menambah pengetahuan dan pemahaman teman-teman memulai git dan github yah.

referensi :

https://git-scm.com/book/en/v2/Getting-Started-About-Version-Control

https://www.petanikode.com/git-install/

https://medium.com/@cecepahmadfauzi93/tutorial-penggunaan-git-github-791ba1472e72