Git dan Github 101

Bayangkan kalau setiap revisi tugas pemrogramanmu bisa dilacak, dibandingkan, bahkan dikembalikan ke versi sebelumnya hanya dengan satu perintah. Itulah keajaiban dari version control! Dengan Git dan GitHub, kamu tidak hanya bisa menyimpan kode dengan rapi, tapi juga berkolaborasi dengan teman satu tim tanpa takut file tertimpa atau hilang.

Tulisan ini akan menjadi panduan praktis untuk memahami cara kerja Git dan GitHub, khususnya bagi mahasiswa yang ingin mulai belajar pengelolaan proyek secara profesional.

1 Apa Itu Version Control?

Sederhananya, version control adalah sistem yang mencatat setiap perubahan yang kamu buat pada sebuah file atau proyek dari waktu ke waktu. Dengan sistem ini, kamu bisa tahu siapa mengubah apa, kapan perubahan terjadi, dan bahkan mengembalikan proyek ke versi sebelumnya jika ada kesalahan. Bayangkan seperti fitur “riwayat revisi” di Google Docs, tapi jauh lebih canggih dan dirancang khusus untuk pengembangan perangkat lunak. Version control membantu tim tetap sinkron, terutama saat banyak orang bekerja pada proyek yang sama.

2 Mengenal Git: Mesin di Balik Version Control

Git adalah salah satu sistem version control paling populer di dunia. Ia diciptakan oleh Linus Torvalds, sosok di balik kernel Linux. Git bekerja secara terdistribusi — artinya setiap orang yang mengerjakan proyek memiliki salinan lengkap dari repositori di komputernya. Dengan cara ini, kamu bisa:

• Melacak perubahan kode secara detail
  
• Mencoba fitur baru tanpa mengganggu versi utama (dengan branch)
  
• Menggabungkan hasil kerja tim dengan mudah (melalui merge)

Git berperan seperti “mesin catatan perubahan”, mencatat setiap commit atau penyimpanan versi yang kamu buat saat menulis kode.

3 GitHub: Tempat Kolaborasi Developer

Kalau Git adalah mesin version control, maka GitHub adalah tempat di mana kamu bisa menyimpan dan membagikan hasil kerjamu secara online. GitHub berfungsi seperti media sosial untuk programmer — kamu bisa:

• Menyimpan proyek (repository) secara publik atau privat
  
• Bekerja bersama orang lain melalui pull request dan issues
  
• Menunjukkan portofolio proyekmu ke calon rekan tim atau perekrut

Bagi mahasiswa, GitHub bisa jadi tempat yang sangat berguna untuk menyimpan tugas, proyek mata kuliah, atau bahkan kontribusi ke proyek open source.

4 Mengapa Mahasiswa Perlu Belajar Git dan GitHub?

1. Meningkatkan Profesionalisme: Hampir semua perusahaan teknologi menggunakan Git. Menguasainya berarti kamu sudah selangkah lebih siap menghadapi dunia kerja.
   
2. Kolaborasi Lebih Mudah: Tidak perlu lagi kirim file lewat chat — cukup push dan pull dari repositori bersama.
   
3. Belajar Cara Kerja Tim Developer Nyata: Kamu akan memahami bagaimana software dikembangkan secara kolaboratif.
   
4. Mendokumentasikan Perjalanan Belajar: Setiap commit bisa menjadi jejak perkembangan skill-mu dari waktu ke waktu.

5 Memulai Proyek Baru

Sampai di sini, kamu sudah memahami mengapa Git dan GitHub penting untuk mengelola proyek. Sekarang saatnya masuk ke bagian praktik — bagaimana memulai pekerjaan baru dengan Git, membuat repositori, dan mulai mencatat perubahan yang kamu buat.Bayangkan kamu baru saja memulai proyek pemrograman atau tugas kelompok. Di sinilah Git akan membantu mengatur semua file dan revisi dengan cara yang lebih terstruktur.

6 Repositories

Dalam Git, repositori (repository) adalah tempat penyimpanan seluruh berkas proyek — termasuk kode sumber, riwayat perubahan, dan konfigurasi. Repositori bisa berada di komputer lokal maupun di server jarak jauh.

• Repositori Lokal (Local Repository)
  Adalah repositori yang tersimpan di komputer Anda sendiri. Di sinilah Anda bekerja, menulis kode, dan mencatat perubahan sebelum dibagikan ke orang lain.

• Repositori Jarak Jauh (Remote Repository)
  Adalah repositori yang disimpan di server di Internet, seperti di GitHub atau GitLab. Repositori ini bisa diakses dan digunakan bersama oleh banyak orang, sehingga memungkinkan kolaborasi tim.

Dengan kata lain, repositori lokal adalah ruang kerja pribadi Anda, sedangkan repositori jarak jauh adalah tempat berbagi hasil kerja dengan tim.

Sebelum mulai bekerja, pastikan Anda sudah menyiapkan lingkungan pengembangan di komputer Anda.
Langkah pertama adalah menentukan di mana direktori kerja Anda akan berada — bisa di folder “Documents”, “Projects”, atau lokasi lain yang biasa Anda gunakan.

Selanjutnya, Anda perlu menyalin (mengambil) repositori yang sudah ada dari server jarak jauh ke komputer lokal Anda.
Proses ini disebut cloning, dilakukan dengan perintah:

git clone https://github.com/username/nama-proyek.git

7 Working Directory

Setelah Anda menyalin repositori ke komputer lokal, kini saatnya mulai bekerja di dalam working directory.
Istilah ini mengacu pada folder tempat Anda melakukan perubahan pada berkas proyek — menambah, menghapus, atau memperbarui kode.

Setiap kali Anda membuka proyek Git di komputer, sebenarnya Anda sedang berada di dalam working directory.
Git akan memantau semua perubahan yang terjadi di sini dan menandai berkas mana yang diubah, ditambahkan, atau dihapus dibandingkan versi sebelumnya.

8 Perubahan dan Penambahan File (Change and Add Files)

Setelah Anda berada di dalam working directory, langkah berikutnya adalah mulai mengubah atau menambahkan berkas proyek.
Misalnya, Anda menulis kode baru, memperbaiki bug, atau menambahkan file README sebagai dokumentasi awal.

Setiap perubahan yang Anda lakukan akan terdeteksi oleh Git. Untuk melihat berkas mana yang telah berubah, gunakan perintah:

git status

Perintah ini akan menampilkan daftar berkas yang dimodifikasi, ditambahkan, atau dihapus sejak commit terakhir. Namun, perlu diingat bahwa perubahan tersebut belum tersimpan secara permanen dalam riwayat Git, berkas tersebut masih berada di working directory. Untuk memberi tahu Git bahwa Anda ingin menyimpan perubahan tersebut, gunakan perintah:

git add nama_file

Atau, jika Anda ingin menandai semua file yang berubah sekaligus, gunakan:

git add .

Tahap ini disebut staging, di mana file yang telah diubah akan berpindah ke staging area tempat persiapan sebelum disimpan ke repositori lokal dengan perintah git commit. Sebagai contoh:

git add second.txt

git commit -m "Menambahkan fungsi baru untuk menghitung rata-rata"

Dengan begitu, setiap perubahan yang Anda lakukan terekam rapi dalam riwayat proyek. Langkah-langkah kecil seperti ini penting untuk menjaga versi proyek Anda tetap terorganisir, terutama saat bekerja dalam tim. Untuk memahami perbedaan antara working directory, staging area, dan repository secara visual, Anda bisa menonton video berikut:

9 Beradaptasi dengan Repositori Jarak Jauh (Adapt to Remote Repositories)

Setelah Anda memahami cara menambah dan mencatat perubahan di repositori lokal, langkah berikutnya adalah berinteraksi dengan repositori jarak jauh (remote repository). Repositori ini biasanya berada di layanan seperti GitHub, GitLab, atau Bitbucket, dan berfungsi sebagai tempat utama untuk berbagi kode serta berkolaborasi dengan orang lain. Repositori lokal di komputer Anda dan repositori jarak jauh di server dapat diibaratkan seperti dua lemari arsip: satu berada di meja kerja pribadi Anda (lokal), dan satu lagi berada di ruang bersama yang bisa diakses oleh seluruh tim (remote). Untuk melihat apakah repositori lokal Anda sudah terhubung ke repositori jarak jauh, gunakan perintah berikut:

git remote -v

Jika hasilnya menampilkan alamat seperti ini:

origin  https://github.com/username/nama-proyek.git (fetch)
origin  https://github.com/username/nama-proyek.git (push)

berarti repositori lokal Anda sudah terhubung dengan baik ke repositori di GitHub. Apabila belum terhubung, Anda bisa menambahkannya secara manual menggunakan:

git remote add origin https://github.com/username/nama-proyek.git

Setelah terhubung, Anda bisa mengirim (push) perubahan dari komputer ke GitHub menggunakan:

git push origin main

Atau, untuk mengambil (pull) perubahan terbaru dari GitHub agar repositori lokal Anda tetap sinkron:

git pull origin main

Dengan dua perintah penting ini push dan pull Anda dapat menjaga agar pekerjaan di komputer lokal selalu selaras dengan repositori tim di GitHub. Inilah inti dari kolaborasi menggunakan Git: setiap anggota tim bekerja secara mandiri, namun tetap bisa menyatukan hasilnya dalam satu repositori yang sama.

10 Melihat Perbedaan (View Differences)

Ketika Anda sering melakukan perubahan pada proyek, mungkin sulit mengingat bagian mana saja yang sudah diubah. Di sinilah fitur melihat perbedaan (diff) dalam Git menjadi sangat membantu. Git menyediakan perintah untuk menampilkan perbedaan antara versi sebelumnya dan versi yang sedang Anda kerjakan di working directory. Dengan begitu, Anda bisa meninjau kembali perubahan sebelum menyimpannya ke dalam commit. Untuk melihat perubahan yang belum ditandai dengan git add, gunakan perintah:

git diff

Perintah ini akan menampilkan baris demi baris perubahan dalam format teks. Baris yang dihapus ditandai dengan warna merah dan tanda - Baris yang ditambahkan ditandai dengan warna hijau dan tanda + Sebagai contoh, jika Anda menambahkan satu fungsi baru pada file second.txt, Git akan menampilkan perbedaan antara versi lama dan versi baru file tersebut. Jika Anda sudah menambahkan file ke staging area menggunakan git add, namun belum melakukan commit, gunakan perintah berikut untuk melihat perubahan yang sudah “siap” disimpan:

git diff --staged

Melihat perbedaan ini penting untuk memastikan bahwa semua perubahan yang Anda buat memang sesuai harapan, dan tidak ada baris kode yang terhapus atau berubah tanpa sengaja. Sebagai ilustrasi, bayangkan Git seperti kamera pengawas proyek Anda — setiap kali ada perubahan, Git mencatatnya dengan detail, dan git diff adalah cara Anda untuk meninjau rekaman tersebut sebelum menetapkan hasil akhirnya dengan commit.

11 Catatan Tambahan: Staging Area

Seiring perkembangan proyek, Anda akan sering melakukan banyak perubahan dalam satu working directory — menambah fitur, memperbaiki bug, atau mengubah beberapa file sekaligus. Nah, apa yang terjadi jika semua perubahan itu langsung dimasukkan ke repositori lokal dalam satu kali commit?

Hasilnya, riwayat proyek Anda akan menjadi sulit dibaca. Ketika nanti Anda atau rekan tim mencoba menelusuri kembali siapa yang menambahkan fitur tertentu, semuanya akan bercampur dalam satu commit besar tanpa konteks yang jelas.

Di sinilah staging area berperan penting. Git merekomendasikan agar Anda melakukan satu commit untuk setiap fitur atau perubahan logis (one commit per feature). Dengan staging area, Anda bisa memilah dan menyiapkan perubahan secara bertahap sebelum benar-benar disimpan ke dalam riwayat proyek.vSebagai contoh:

git add main.py        # Menambahkan perubahan fitur baru
git add readme.md      # Menambahkan pembaruan dokumentasi
git commit -m "Menambahkan fitur perhitungan rata-rata"

Jika ternyata Anda ingin memisahkan pembaruan dokumentasi ke commit lain, Anda bisa menundanya dan hanya menambahkan file main.py ke staging area terlebih dahulu. Setelah itu, barulah menambahkan readme.md dalam commit berikutnya.

12 Ringkasan

Setelah mempelajari langkah-langkah dasar di atas, kini Anda telah memahami alur kerja utama dalam Git. Secara sederhana, alurnya bisa dirangkum seperti ini:

Clone sekali, lalu lakukan add, commit, dan push setiap kali Anda bekerja.

Artinya:

1. Clone — ambil repositori dari server jarak jauh (misalnya GitHub) ke komputer lokal Anda.

2. Add — tandai file yang mengalami perubahan dan siap disimpan

3. Commit — simpan perubahan tersebut ke dalam repositori lokal dengan pesan yang menjelaskan maksudnya.

4. Push — kirim hasil kerja Anda ke repositori jarak jauh agar dapat diakses atau dikolaborasikan dengan orang lain.

Alur sederhana ini adalah fondasi dari semua kegiatan pengembangan dengan Git. Dengan membiasakan diri menjalankan langkah-langkah tersebut secara teratur, Anda akan terbiasa bekerja dengan versi kode yang teratur, aman, dan mudah dilacak.

13 Branch

Dalam pengembangan proyek menggunakan Git, branch (cabang) berfungsi sebagai jalur pengembangan yang terpisah dari cabang utama (main atau master). Branch memungkinkan beberapa orang atau bahkan diri kita sendiri untuk bekerja pada fitur, perbaikan bug, atau eksperimen tanpa mengganggu kode utama yang sudah stabil. Ketika kita membuat sebuah branch, Git akan menyalin kondisi terbaru dari repositori (commit terakhir) ke cabang baru tersebut. Perubahan yang dilakukan di cabang ini bersifat terpisah, sehingga kita dapat melakukan uji coba atau pengembangan fitur baru secara bebas. Jika hasilnya sudah siap, kita bisa menggabungkannya kembali ke cabang utama melalui proses yang disebut merge. Sebagai analogi, bayangkan proyek Git seperti jalan besar dengan banyak percabangan. Setiap branch adalah jalur alternatif untuk mencapai tujuan yang sama, tetapi dengan rute yang berbeda. Kita bisa bekerja di cabang terpisah tanpa mengganggu jalur utama.

Secara default, saat kita membuat repositori Git baru, Git akan otomatis membuat cabang pertama bernama main (atau master pada versi lama).
Namun, kita dapat membuat cabang lain seperti feature-login, bugfix-header, atau experiment-ui sesuai kebutuhan pengembangan.

# Menampilkan daftar branch yang ada
git branch

# Membuat branch baru bernama feature-login
git branch feature-login

# Berpindah ke branch feature-login
git checkout feature-login

Note

Bekerja dengan branch adalah salah satu fitur paling berguna pada Git. Dengan sistem ini, setiap pengembang dapat bekerja secara paralel tanpa saling mengganggu, dan hasil akhirnya dapat digabungkan secara rapi ke dalam repositori utama.

14 Membuat Branch Baru (Create New Branch)

Sebelumnya, kita telah membahas bahwa branch (cabang) digunakan untuk memisahkan jalur pengembangan dalam satu repositori Git. Sekarang, mari kita pelajari bagaimana cara membuat cabang baru untuk mengerjakan fitur atau perbaikan tertentu.

Saat membuat branch baru, Git akan menyalin seluruh isi dan riwayat commit dari branch aktif (biasanya main) ke cabang baru tersebut.
Dengan begitu, kita dapat memulai pengembangan tanpa mengubah kode yang ada di branch utama. Untuk membuat branch baru, gunakan perintah berikut:

git branch nama-branch

Contoh:

git branch feature-login

Perintah ini akan membuat sebuah cabang baru bernama feature-login. Namun, kita belum berpindah ke cabang tersebut. Untuk mulai bekerja di branch baru, gunakan perintah:

git checkout feature-login

Sekarang Anda berada di branch feature-login, dan semua perubahan file yang dilakukan akan tersimpan di cabang ini.

15 Bekerja di Dalam Branch

Setelah berhasil membuat branch baru, langkah berikutnya adalah mulai bekerja di dalam branch tersebut. Setiap branch di Git memiliki ruang kerja (working directory) sendiri yang dapat berisi versi file yang berbeda dari branch lainnya. Dengan cara ini, kita dapat bereksperimen, menambahkan fitur, atau memperbaiki bug tanpa mengganggu kode utama di branch main atau develop.

Misalnya, setelah berpindah ke branch feature-login:

git checkout feature-login

16 Git-Flow dan GitHub-Flow

Setiap tim pengembang memiliki cara berbeda dalam mengelola branch selama proses pengembangan proyek. Namun, seperti halnya naming convention dalam pemrograman, terdapat beberapa pola umum (workflow) yang sering digunakan sebagai panduan dalam mengatur alur kerja Git. Dua model yang paling populer adalah Git-Flow dan GitHub-Flow. Tujuannya sama — yaitu untuk menjaga agar proses pengembangan tetap terstruktur dan mudah dikelola, terutama ketika bekerja dalam tim.

17 Git-Flow

Git-Flow adalah model cabang yang lebih kompleks dan terperinci, diperkenalkan oleh Vincent Driessen. Model ini sangat cocok untuk proyek besar dengan siklus rilis yang teratur dan banyak fitur yang dikembangkan secara paralel. Berikut struktur utama cabang pada Git-Flow:

Nama Branch	Fungsi	Catatan
master	Menyimpan versi rilis produk yang sudah stabil.	Tidak digunakan untuk pengembangan langsung.
develop	Cabang utama untuk pengembangan.	Semua fitur baru digabung ke sini sebelum dirilis.
feature/*	Digunakan untuk menambahkan fitur baru.	Setelah selesai, digabungkan ke develop.
release/*	Untuk persiapan rilis produk.	Dibuat dari develop, lalu digabung ke master dan develop setelah rilis.
hotfix/*	Untuk perbaikan darurat setelah rilis.	Dibuat dari master, lalu digabung kembali ke master dan develop.

Model ini membantu tim besar agar setiap tahap — pengembangan, pengujian, hingga rilis — dilakukan secara terpisah dan terorganisir.

18 GitHub-Flow

Berbeda dengan Git-Flow, GitHub-Flow adalah model yang lebih sederhana dan fleksibel, cocok untuk proyek modern dengan proses continuous integration atau continuous deployment (CI/CD).

Pada GitHub-Flow, biasanya hanya ada dua jenis branch utama:

1. main (atau master) — cabang utama yang berisi kode yang siap dirilis.
2. feature/* — cabang untuk pengembangan fitur baru, yang nantinya akan digabung ke main.

19 Merge (Menggabungkan branch)

Setelah bekerja di dalam branch terpisah dan melakukan beberapa commit, pada akhirnya kita perlu menggabungkan hasil pekerjaan tersebut ke branch utama (misalnya main atau develop). Proses ini disebut merge.

Dalam Git, merge berfungsi untuk menggabungkan riwayat commit dari satu branch ke branch lain, sehingga seluruh perubahan yang telah dilakukan di branch pengembangan ikut tercatat di branch tujuan. Contohnya, kita telah mengembangkan fitur baru di branch feature-login dan ingin menggabungkannya ke develop. Langkah-langkahnya adalah sebagai berikut:

# Pastikan berada di branch tujuan (develop)
git checkout develop

# Gabungkan branch feature-login ke develop
git merge feature-login

(main) ----●----●
              \
             (feature-login) ----●----●

(main) ----●----●--------●
              \        /
             (feature-login)

Titik merge (●) yang baru terbentuk menunjukkan bahwa perubahan dari feature-login telah digabung ke main.

Note

Selalu pastikan kode di branch tujuan dalam keadaan up to date sebelum melakukan merge. Jika Anda bekerja dalam tim, lakukan git pull terlebih dahulu untuk mengambil perubahan terbaru dari remote repository sebelum menggabungkan.

20 Fast Forward (Penggabungan Langsung)

Ketika kita melakukan merge dan branch tujuan tidak memiliki commit baru sejak cabang sumber dibuat, Git dapat menggabungkan perubahan dengan cara yang sangat sederhana. Metode ini disebut Fast Forward Merge. Pada mode fast forward, Git cukup memindahkan pointer branch tujuan ke posisi commit terakhir dari branch sumber tanpa membuat commit merge baru. Dengan kata lain, riwayat commit dari kedua branch akan tampak seperti satu garis lurus. Jika selama pengembangan di feature-login, branch main tidak berubah sama sekali, maka ketika kita menjalankan perintah berikut:

git checkout main
git merge feature-login

::: callout-note Kapan menggunakan Fast Forward? Gunakan fast forward jika: Branch fitur hanya dikerjakan oleh satu orang. Tidak ada perubahan di branch utama selama pengembangan. Anda ingin riwayat commit tetap bersih dan linear. :::

21 No Fast Forward

Berbeda dengan Fast Forward Merge yang menyatukan riwayat secara linear, No Fast Forward Merge digunakan ketika kita ingin mempertahankan jejak cabang pengembangan secara eksplisit dalam riwayat proyek. Dengan metode ini, Git akan membuat satu commit merge baru yang menandakan penggabungan dua riwayat berbeda. Ini berguna ketika proyek dikerjakan oleh banyak orang atau memiliki beberapa cabang fitur yang aktif secara bersamaan.

Misalkan struktur branch sebelum merge seperti ini:

git checkout main
git merge --no-ff feature-login

(main) ----●----●----------●
              \           /
             (feature-login) ----●----●

Note

Gunakan --no-ff jika Anda ingin menjaga dokumentasi riwayat pengembangan. Untuk proyek kecil atau percobaan pribadi, fast forward bisa lebih sederhana dan efisien.

22 Menangani Konflik (Deal with Conflicts)

Terkadang, ketika kita melakukan merge, Git tidak bisa secara otomatis menggabungkan perubahan dari dua branch. Hal ini disebut merge conflict (konflik penggabungan). Konflik biasanya terjadi ketika dua branch memodifikasi bagian kode yang sama pada file yang sama. Misalnya, kita memiliki dua branch: main dan featureA. Kedua branch ini mengubah baris ke-5 dari file index.html, tetapi dengan isi yang berbeda. Ketika kita menjalankan perintah berikut:

git checkout main
git merge featureA

Git akan memberi peringatan seperti ini:

Auto-merging index.html
CONFLICT (content): Merge conflict in index.html
Automatic merge failed; fix conflicts and then commit the result.

Git akan menandai bagian yang bermasalah dalam file, misalnya:

<<<<<<< HEAD
<h1>Selamat Datang di Website Kami</h1>
=======
<h1>Welcome to Our Website</h1>
>>>>>>> featureA

Bagian di antara <<<<<<< HEAD dan ======= menunjukkan versi dari branch yang aktif (main). sedangkan bagian di bawah ======= hingga >>>>>>> featureA menunjukkan versi dari branch lain (featureA). Untuk menyelesaikan konflik, lakukan langkah-langkah berikut:

1. Buka file yang mengalami konflik.
2. Periksa perbedaan antara kedua versi.
3. Pilih versi yang benar atau gabungkan keduanya secara manual.
4. Hapus tanda konflik (<<<<<<<, =======, >>>>>>>) setelah selesai.
5. Jalankan perintah:

git add index.html
git commit

23 Menghapus Branch yang Tidak Diperlukan (Delete Unnecessary Branches)

Setelah proses merge selesai dan perubahan dari branch sudah digabungkan ke branch utama,
branch lama sering kali tidak lagi diperlukan.
Untuk menjaga agar repositori tetap bersih dan mudah dikelola, sebaiknya branch yang sudah tidak digunakan dihapus.

24 Menghapus Branch Lokal

Untuk menghapus branch yang sudah selesai di-merge ke main di repositori lokal, gunakan perintah:

git branch -d nama_branch

Perintah -d berarti delete (hapus) tetapi aman, karena Git tidak akan menghapus branch jika belum di-merge ke branch utama. Jika kamu yakin ingin menghapus branch meskipun belum di-merge, gunakan opsi paksa:

git branch -D nama_branch

Note

Perintah -D akan langsung menghapus branch tanpa konfirmasi. Pastikan perubahan di dalamnya sudah tidak dibutuhkan atau telah disimpan di tempat lain.

25 Menghapus Branch di Remote Repository (GitHub)

git push origin --delete nama_branch

Setelah perintah dijalankan, branch featureA akan hilang dari repositori remote.

26 Apa Itu Rebase?

git rebase adalah perintah di Git yang digunakan untuk memindahkan atau mengatur ulang basis (dasar) dari satu branch ke branch lain. Dengan kata lain, rebase memungkinkan kamu untuk “menyusun ulang” riwayat commit agar terlihat lebih bersih dan linear. Secara sederhana, rebase mengambil semua commit di satu branch dan meletakkannya di atas (on top of) branch lain.

27 Ilustrasi Sederhana

Bayangkan kamu sedang mengembangkan fitur baru di branch featureA sementara branch utama main terus diperbarui oleh anggota tim lain.
Sebelum kamu melakukan merge, kamu ingin memastikan branch featureA mengikuti perkembangan terbaru dari main. Kamu dapat menjalankan:

git checkout featureA
git rebase main

Artinya: “Ambil semua commit dari featureA dan letakkan di atas commit terbaru dari main”

28 Perbandingan antara Merge dan Rebase

Aspek	Merge	Rebase
Tujuan	Menggabungkan dua riwayat commit	Menyusun ulang riwayat commit
Hasil Riwayat	Riwayat bercabang (branching history)	Riwayat linear (lebih rapi)
Commit Baru	Menambahkan commit merge baru	Tidak menambah commit merge baru
Risiko	Aman untuk kolaborasi	Berisiko jika dilakukan pada branch publik

Melalui pembahasan panjang ini, kita telah mengenal konsep dasar Version Control menggunakan Git dan GitHub, mulai dari pembuatan repositori, manajemen perubahan, penggunaan branch, hingga penggabungan dengan merge dan rebase. Git bukan hanya alat teknis, tetapi juga cara berpikir terstruktur dalam mengelola proyek. Dengan memahami alur kerja Git, kamu tidak sekadar menyimpan kode — kamu sedang belajar berkolaborasi, menjaga histori kerja, dan membangun kebiasaan profesional yang sangat dibutuhkan di dunia pengembangan perangkat lunak modern.

Jadi, jangan takut untuk bereksperimen!
Cobalah membuat proyek kecil, berlatih dengan perintah dasar seperti add, commit, push, branch, merge, dan rebase.
Semakin sering kamu berlatih, semakin alami pula kamu akan memahami bagaimana Git bekerja di balik layar.

“Belajar Git adalah seperti belajar bermain alat musik — di awal terasa rumit, tapi setelah menguasainya, kamu akan menikmati setiap alur dan harmoni kerjanya.”

Selamat bereksperimen dan selamat berkolaborasi dengan Git dan GitHub! 🎸💻