Bukan Cuma Add Commit Push Cara Aku Pakai Git Biar Nggak Pusing

Photo by Natalia Sedova/Unsplash

Halo semua! Pernah nggak sih ngerasa pusing pas lagi ngoding terus berurusan sama Git? Awalnya sih enak, cuma git add, git commit, git push. Berasa paling jago deh. Tapi makin ke sini, proyek makin gede, tim makin rame, eh kok tiba-tiba Git jadi musuh? Konflik lah, salah commit lah, kerjaan belum selesai tapi harus ganti branch lah. Rasanya pengen lempar laptop aja, ya kan?

Tenang, kamu nggak sendirian! Aku juga dulu gitu kok. Tapi setelah coba-coba, baca sana-sini, dan sering kejeblos, aku nemu beberapa cara atau "trik" pakai Git yang bikin hidup ngoding jadi lebih santai. Ini bukan cuma soal hafal perintah, tapi lebih ke ngerti "jiwa"-nya Git dan pakai fitur-fitur lain selain si trio maut add-commit-push.

Yuk, kita bahas satu per satu!

1. Branching: Bukan Cuma main atau master

Pas awal pakai Git, mungkin kita cuma kerja di main atau master aja. Tapi ini big no no kalau proyeknya udah mulai serius, apalagi kerja tim. Branch itu kayak bikin jalur paralel dari kode utamamu. Tujuannya jelas: biar kamu bisa ngerjain fitur baru, benerin bug, atau eksperimen tanpa ngancurin kode utama yang udah stabil.

Kenapa Penting?

* Isolasi pekerjaan: Fitur A nggak ganggu fitur B atau kode yang udah rilis. Kolaborasi: Tiap orang bisa ngerjain di branch* masing-masing tanpa takut tumpang tindih langsung di kode utama. Percobaan: Mau nyoba sesuatu yang radikal? Bikin branch baru, eksperimen sepuasnya. Kalau gagal, tinggal hapus branch*-nya, kode utama aman.

Gimana Caranya Biar Nggak Pusing?

Kasih nama branch yang jelas: Jangan cuma fitur-baru atau fix. Pakai nama yang deskriptif, misalnya feat/login-google, bug/fix-payment-gateway, refactor/navbar-responsive. Ini bantu banget pas lihat branch di remote atau pas mau merge*. Jangan pernah kerja langsung di main/master: Bikin branch baru buat tiap tugas (fitur, bugfix*, dll.). Gunakan branching strategy (meski simpel): Nggak harus langsung pakai Git Flow yang rumit. Cukup mulai dengan "Feature Branching". Artinya, setiap kali mau nambah fitur atau benerin bug, bikin branch baru dari main/master. Setelah selesai, merge kembali ke main/master (biasanya lewat Pull Request/Merge Request*).

Perintah Dasar Branching:

Lihat semua branch yang ada ( artinya branch yang lagi aktif):

bash
        git branch

Bikin branch* baru (misalnya feat/user-profile):

bash
        git branch feat/user-profile

Pindah ke branch* lain:

bash
        git checkout feat/user-profile
        # Atau pakai yang lebih modern di Git versi baru:
        git switch feat/user-profile

Bikin branch baru sekaligus langsung pindah ke branch* itu:

bash
        git checkout -b feat/user-profile
        # Atau pakai yang lebih modern:
        git switch -c feat/user-profile

Hapus branch* (pastikan udah nggak dipakai dan udah di-merge kalau perlu):

bash
        git branch -d nama-branch-yang-mau-dihapus
        # Kalo mau hapus paksa (hati-hati!):
        git branch -D nama-branch-yang-mau-dihapus

Tips: Rajin-rajinlah pull atau fetch perubahan terbaru dari remote sebelum mulai kerja di branch baru, terutama kalau branch* barunya dicabang dari main/master.

2. git stash: Simpan Kerja Belum Selesai dengan Rapi

Ini nih penyelamatku pas lagi asyik ngoding di satu branch (misalnya lagi ngerjain fitur A), terus tiba-tiba ada bug di branch lain (misalnya di main) yang harus buru-buru dibenerin. Kerjaan fitur A belum di-commit, kodenya masih berantakan atau malah error. Kalau dipaksa commit nanti jadi commit yang jelek. Kalau nggak di-commit, nggak bisa pindah branch.

Nah, di sinilah git stash beraksi. stash itu kayak "menyimpan" perubahan (yang di-track dan untracked) di direktori kerja dan area staging-mu untuk sementara, bikin direktori kerjamu jadi bersih seperti terakhir kali kamu commit.

Kapan Dipakai?

Perlu pindah branch tapi belum siap commit*. Mau pull* perubahan terbaru tapi ada perubahan lokal yang bentrok. * Mau nyoba sesuatu sementara tanpa merusak kerjaan utama.

Gimana Caranya?

* Simpan perubahanmu (yang di-track dan untracked):

bash
        git stash

Secara default, git stash nggak menyimpan file baru yang untracked. Kalau mau ikut disimpan, pakai:

bash
        git stash -u # atau --include-untracked

Bagusnya lagi, kasih pesan biar nggak bingung stashing apa:

bash
        git stash save "Lagi ngerjain fitur A, simpan dulu"

Lihat daftar stash* yang kamu punya:

bash
        git stash list
        # Outputnya kira-kira gini:
        # stash@{0}: On feat/fitur-A: Lagi ngerjain fitur A, simpan dulu
        # stash@{1}: On main: WIP on main: abcdefg Initial commit

Kembalikan perubahan dari stash paling atas (stash@{0}), tapi stash*nya tetap ada di daftar:

bash
        git stash apply
        # Kalau mau apply stash yang spesifik, misal stash@{1}:
        git stash apply stash@{1}

Kembalikan perubahan dari stash paling atas (stash@{0}) dan hapus stash* itu dari daftar:

bash
        git stash pop
        # Kalau mau pop stash yang spesifik:
        git stash pop stash@{1}

Hapus satu stash* dari daftar:

bash
        git stash drop stash@{1} # Hapus stash@{1}

Hapus semua stash*:

bash
        git stash clear # Hati-hati!

Bikin branch baru dari stash tertentu dan langsung apply* perubahannya (ini keren banget!):

bash
        git stash branch new-branch-for-this-work stash@{1}

Perintah ini akan bikin branch baru, pindah ke branch itu, apply perubahan dari stash@{1}, dan drop stash@{1} dari daftar stashmu. Mantap!

3. Memperbaiki Kesalahan: amend, revert, reset

Namanya juga manusia, pasti pernah salah. Udah terlanjur commit eh ternyata ada yang lupa ditambahin, atau pesan commit-nya typo, atau malah commit yang udah di-push ternyata salah. Git punya beberapa cara buat ngatasin ini, tergantung seberapa parah kesalahannya dan apakah commit itu udah dibagikan ke orang lain atau belum.

git commit --amend: Ini buat ngubah commit terakhirmu yang belum kamu push ke remote*. Kapan Dipakai? Pesan commit typo, ada file yang lupa di-add, atau mau nambahin sedikit perubahan ke commit* terakhir. * Gimana Caranya? 1. Lakukan perubahan atau add file yang kelupaan. 2. Jalankan:

bash
            git commit --amend

Ini akan membuka editor pesan commit. Kamu bisa ubah pesannya atau biarkan saja kalau cuma mau nambahin file. Setelah disimpan, commit terakhirmu akan ditimpa dengan commit yang baru. ID commit-nya (SHA) akan berubah! Tips: Karena ID commit berubah, jangan pakai ini kalau commit terakhirmu udah di-push ke remote dan mungkin udah di-pull sama orang lain. Nanti mereka bakal punya commit yang beda sama kamu, bikin pusing pas pull atau push* lagi.

git revert: Ini cara "aman" buat membatalkan commit yang udah terlanjur di-push atau dibagiin. Git nggak menghapus commit yang salah, tapi bikin commit baru yang isinya kebalikan dari perubahan di commit* yang mau dibatalin.

Kapan Dipakai? Membatalkan commit yang udah di-push ke remote*. * Gimana Caranya? 1. Cari ID commit yang mau dibatalkan (bisa pakai git log --oneline). 2. Jalankan:

bash
            git revert abcdefg # ganti abcdefg dengan ID commit

Git akan membuat commit baru. Kamu bisa ubah pesan commitnya (biasanya otomatis dikasih awalan "Revert..."). Setelah ini, kamu bisa push commit "revert" ini ke remote. Sejarah commit-nya tetap ada, tapi perubahannya dibatalkan oleh commit "revert" tadi. Tips: Ini cara paling aman untuk membatalkan perubahan di branch yang dipakai bareng-bareng (misal main, develop, atau feature branch* yang dipakai lebih dari satu orang).

git reset: Ini cara buat memindahkan "kepala" branch (HEAD) ke commit sebelumnya. Ini bisa "menghapus" commit dari sejarah branch-mu secara lokal*.

Kapan Dipakai? Kamu bikin beberapa commit lokal dan baru sadar ada kesalahan fatal di commit terakhir atau beberapa commit terakhir sebelum di-push*. * Mode Reset: --soft: HEAD pindah ke commit yang dituju, tapi perubahan dari commit setelahnya (yang "dihapus") tetap ada di area staging (siap di-commit* lagi).

bash
            git reset --soft HEAD~1 # Kembali ke 1 commit sebelumnya, perubahan masuk staging

--mixed (Default): HEAD pindah, perubahan ada di working directory, tapi tidak di area staging. Kamu harus git add lagi kalau mau commit*.

bash
            git reset --mixed HEAD~1 # Kembali ke 1 commit sebelumnya, perubahan masuk working dir (un-staged)

--hard: HEAD pindah, dan semua perubahan dari commit setelahnya (yang "dihapus") hilang dari working directory*. Ini paling berbahaya!

bash
            git reset --hard HEAD~1 # Kembali ke 1 commit sebelumnya, semua perubahan setelahnya hilang!
            git reset --hard origin/main # Samain persis kayak remote main, HATI-HATI SEMUA PERUBAHAN LOKAL HILANG!

Tips: Gunakan reset dengan mode --hard hanya jika kamu yakin 100% perubahannya nggak penting. reset --soft atau --mixed lebih aman karena perubahannya masih ada. Jangan pernah reset --hard atau bahkan reset biasa (yang menghapus commit) commit yang udah di-push ke remote kalau branch itu dipakai orang lain. Sama kayak amend, ini bikin sejarah commit yang beda dan bikin konflik serius nantinya. revert adalah pilihan yang lebih baik untuk commit* yang sudah dibagikan.

4. Bersih-bersih Area Kerja: git clean dan git rm

Kadang, proyek kita punya banyak file nggak penting yang nggak perlu di-track sama Git (file hasil kompilasi, file log, dll.). Meskipun udah pakai .gitignore, kadang masih ada file "nyasar" atau file yang tadinya di-track tapi sekarang mau dihapus permanen.

.gitignore: Pastikan kamu punya file .gitignore di root proyekmu. Isinya daftar pola nama file/folder yang nggak perlu di-track Git. Contoh: node_modules/, .log, build/, .env. Git akan mengabaikan file-file ini.

git clean: Perintah ini buat menghapus file-file untracked (yang nggak masuk .gitignore dan belum pernah di-add) dari working directory*mu.

Kapan Dipakai? Area kerja berantakan sama file-file sementara atau hasil generate* yang nggak diinginkan. * Gimana Caranya? 1. Selalu coba mode dry run dulu buat lihat file apa aja yang bakal dihapus:

bash
            git clean -n # -n artinya dry run, simulate

2. Kalau udah yakin, baru hapus:

bash
            git clean -f # -f artinya force

3. Secara default, clean nggak menghapus folder untracked. Kalau mau hapus juga folder untracked:

bash
            git clean -fd # -d artinya include directories

Tips: git clean itu permanen, file yang dihapus nggak masuk "tempat sampah" Git. Jadi, selalu* pakai -n dulu!

git rm: Perintah ini buat menghapus file yang sudah di-track* oleh Git.

Kapan Dipakai? Kamu mau menghapus file dari proyekmu dan dari riwayat Git (setelah commit* perintah git rm). * Gimana Caranya?

bash
        git rm nama-file-yang-mau-dihapus

Ini akan menghapus file dari working directory dan memasukkannya ke area staging sebagai file yang siap dihapus di commit berikutnya. Kalau kamu cuma mau menghapus file dari riwayat Git (dari commit selanjutnya), tapi tetap membiarkan filenya ada di working directory (berguna kalau tadinya di-track tapi sekarang mau di-ignore):

bash
        git rm --cached nama-file
        # Jangan lupa tambahkan nama-file ke .gitignore setelah ini!

Tips: Setelah pakai git rm, jangan lupa di-commit* perubahan penghapusan ini.

5. Mengerti Sejarah Kode: git log dan git diff

Salah satu kekuatan utama Git adalah kemampuannya mencatat sejarah perubahan kode. Mengerti cara melihat dan membandingkan perubahan ini itu penting banget buat debugging, melacak siapa ngubah apa, atau sekadar nostalgia lihat commit lama.

git log: Melihat riwayat commit*.

Kapan Dipakai? Mau tahu siapa yang commit, kapan, pesannya apa, commit* ID-nya berapa. * Gimana Caranya? * Basic log (biasanya panjang banget):

bash
            git log

Versi ringkas, satu baris per commit*:

bash
            git log --oneline

Lihat log sebagai grafik (untuk visualisasi branching dan merging*):

bash
            git log --oneline --graph

Lihat semua commit di semua branch*:

bash
            git log --oneline --graph --all

Lihat commit dan branch* yang sedang aktif:

bash
            git log --oneline --graph --decorate

Lihat log dan diff perubahan di setiap commit*:

bash
            git log -p

* Lihat log milik user tertentu:

bash
            git log --author="Nama User Kamu"

* Lihat log dalam rentang waktu:

bash
            git log --since="2 weeks ago"
            git log --until="2023-01-01"

Tips: Kombinasikan flag*-nya! git log --oneline --graph --all --decorate adalah kombinasi favorit banyak orang. Bikin alias biar nggak ngetik panjang (git config --global alias.lg "log --oneline --graph --all --decorate").

git diff: Melihat perbedaan antara dua "kondisi" kode.

Kapan Dipakai? Mau lihat apa aja yang berubah sebelum di-staging, setelah di-staging tapi belum di-commit, antara dua commit, atau antara dua branch*. * Gimana Caranya? Perubahan di working directory yang belum di-add* (un-staged changes):

bash
            git diff

Perubahan di area staging yang belum di-commit*:

bash
            git diff --staged
            # atau
            git diff --cached

Perubahan antara working directory dan commit* terakhir (HEAD):

bash
            git diff HEAD

Perubahan antara dua commit*:

bash
            git diff commitidlama commitidbaru

Perubahan antara dua branch*:

bash
            git diff brancha branchb

Tips: git diff kasih output detail per baris mana yang ditambah (+) dan mana yang dihapus (-). Pahami outputnya, ini bantu banget pas lagi code review atau nyari bug*.

6. Menangani Konflik: git merge yang Berdarah-darah

Ini nih momen yang bikin deg-degan: pas mau gabungin (merge) perubahan dari satu branch ke branch lain, eh muncul pesan "CONFLICT". Artinya, Git nggak bisa otomatis gabungin perubahan karena ada baris kode yang sama-sama diubah di dua branch yang berbeda.

Kenapa Konflik Terjadi?

Kamu dan temanmu ngubah baris yang sama di file yang sama, tapi di branch yang berbeda. Pas branch itu digabung, Git bingung mau pakai perubahan yang mana.

Gimana Cara Menyelesaikannya?

1. Identifikasi: Git akan memberitahu file mana aja yang konflik. Kamu bisa lihat pakai git status. 2. Edit File yang Konflik: Buka file yang konflik. Kamu akan lihat penanda konflik kayak gini:

<<<<<<< HEAD
        Kode di branch kamu (branch yang lagi aktif)
        =======
        Kode di branch yang mau di-merge
        >>>>>>> nama-branch-yang-di-merge

HEAD itu nunjukkin kondisi di branch kamu saat ini. Bagian bawah ======= itu kondisi dari branch yang mau kamu merge. Kamu harus edit bagian ini, pilih kode mana yang mau dipakai, atau gabungkan keduanya secara manual sesuai kebutuhan. Hapus penanda <<<<<<<, =======, dan >>>>>>>. 3. Add File yang Sudah Diperbaiki: Setelah selesai edit dan konflik teratasi, add file itu ke area staging:

bash
        git add nama-file-yang-konflik

Lakukan ini untuk semua file yang konflik. 4. Commit Perubahan: Setelah semua file konflik di-add, selesaikan proses merge dengan commit:

bash
        git commit

Git biasanya udah nyiapin pesan commit otomatis buat merge. Kamu bisa ubah kalau mau, tapi biasanya nggak perlu. 5. Selesai! Konflik sudah teratasi dan proses merge selesai.

Tips:

Komunikasi itu kunci! Kalau kerja tim, sering-sering pull atau fetch perubahan terbaru dan merge ke branch* kerjamu biar konfliknya kecil dan gampang diatasi. * Jangan tunda resolve konflik. Begitu muncul, langsung sikat! Gunakan merge tool visual. Git bisa dikonfigurasi pakai tool* eksternal kayak VS Code, KDiff3, Meld, dll. buat bantu visualisasi dan selesaikan konflik. Ini sangat membantu buat konflik yang kompleks.

7. Bekerja dengan Remote: fetch vs pull

Pasti udah biasa pakai git push buat ngirim perubahan lokal ke remote repository (Kayak GitHub, GitLab, Bitbucket). Tapi gimana cara ambil perubahan dari remote? Kebanyakan orang langsung pakai git pull. Tapi tahukah kamu, git pull itu sebenarnya kombinasi dari dua perintah: git fetch dan git merge (atau git rebase, tergantung konfigurasi)?

git fetch: Mengambil semua commit, branch, dan tag terbaru dari remote ke repositori lokalmu, TAPI tidak menggabungkannya dengan branch lokalmu. Perubahan disimpan di branch remote tracking* (misal origin/main).

Kapan Dipakai? Mau lihat apa aja perubahan terbaru di remote tanpa langsung menggabungkannya ke branch* lokalmu. * Gimana Caranya?

bash
        git fetch origin # fetch dari remote 'origin'
        git fetch --all # fetch dari semua remote

Setelah fetch, kamu bisa lihat branch remote tracking (misalnya pakai git log --oneline --graph --decorate --all). Kamu bisa bandingkan main lokalmu dengan origin/main pakai git diff main origin/main.

git pull: Kombinasi git fetch diikuti dengan git merge (default) atau git rebase. Artinya, dia ambil perubahan dari remote dan langsung mencoba menggabungkannya ke branch* lokalmu saat ini.

Kapan Dipakai? Mau ambil perubahan terbaru dari remote dan langsung digabungin ke branch* kerjamu. * Gimana Caranya?

bash
        git pull origin main # Pull dari branch main di remote origin

Tips: git pull itu praktis, tapi kadang bisa bikin konflik yang tiba-tiba. Aku pribadi lebih suka pakai git fetch dulu, lihat perubahannya, baru kalau perlu merge manual (git merge origin/main) atau rebase* (git rebase origin/main). Ini kasih kontrol lebih. Tapi kalau yakin nggak bakal ada konflik besar dan cuma mau update cepat, git pull oke aja.

8. Merapikan Sejarah Commit: git rebase

Ini perintah sakti (dan kadang horor) buat ngubah sejarah commit. Kalau merge itu kayak "menggabungkan dua sejarah commit paralel", rebase itu kayak "menempelkan" commit dari satu branch di atas commit terakhir branch lain, bikin sejarahnya jadi lurus (linear).

Kapan Dipakai?

Kamu lagi kerja di feature branch dan mau update dengan perubahan terbaru dari main tanpa bikin merge commit. Tujuannya biar sejarah feature branch*mu terlihat lurus dan bersih. Mau menggabungkan beberapa commit kecil di feature branchmu jadi satu commit besar sebelum di-merge* (interactive rebase).

Gimana Caranya (Contoh Rebase dari main):

Misal kamu di branch feat/fitur-baru, dan ada update di main. 1. Pastikan kamu di branch feat/fitur-baru.

bash
        git switch feat/fitur-baru

2. Pastikan main lokalmu sudah update (bisa git pull origin main atau git fetch origin lalu git switch main dan git pull).

bash
        git fetch origin
        # Kalau belum switch ke main dan pull
        # git switch main
        # git pull
        # git switch feat/fitur-baru

3. Lakukan rebase:

bash
        git rebase main

Git akan "memundurkan" commit-commit kamu di feat/fitur-baru, update branch feat/fitur-baru ke commit terakhir main, lalu "memutar ulang" commit-commit kamu di atas commit terakhir main tadi. Hasilnya, commit-commit kamu di feat/fitur-baru sekarang berada setelah commit terakhir di main, dan ID commit-nya berubah! Kalau ada konflik saat rebase, Git akan berhenti, kamu harus selesaikan konfliknya (sama kayak merge conflict), git add file yang udah dibenerin, lalu lanjut rebase: git rebase --continue. Kalau mau batalin: git rebase --abort.

Interactive Rebase (git rebase -i): Ini buat ngubah sejarah commit branch yang lagi kamu pakai secara interaktif*.

Kapan Dipakai? Mau beresin commit lokalmu sebelum di-push atau di-merge*. Misalnya: Gabungin beberapa commit* kecil jadi satu (squash, fixup). Ngubah urutan commit* (reword). Ngubah pesan commit* lama (reword). Hapus commit* yang nggak perlu (drop). Memecah commit* jadi beberapa bagian (edit). * Gimana Caranya? Misal kamu mau beresin 3 commit terakhir di branch kamu:

bash
        git rebase -i HEAD~3

Git akan membuka editor dengan daftar 3 commit terakhirmu dan instruksi. Kamu bisa ubah kata pick jadi squash, reword, drop, dll. sesuai instruksi. Setelah disimpan, Git akan menjalankan perintah sesuai script yang kamu buat.

PERINGATAN PENTING TENTANG REBASE: Jangan pernah melakukan rebase pada commit yang sudah pernah di-push ke remote dan mungkin sudah di-pull oleh orang lain. Kenapa? Karena rebase mengubah ID commit. Kalau kamu rebase commit yang udah dibagikan, sejarah commit kamu dan temanmu jadi beda. Nanti pas mau push, Git akan nolak karena sejarahnya "bentrok". Kamu terpaksa git push --force, dan ini bisa menghapus perubahan temanmu kalau nggak hati-hati. rebase paling aman dipakai di branch* lokalmu sendiri yang belum dibagikan.

9. Mempersingkat Perintah: Aliases Git

Git commands bisa lumayan panjang, apalagi yang sering dipakai tapi punya banyak flag (kayak git log --oneline --graph --all --decorate). Git punya fitur alias buat bikin singkatan perintah.

Kapan Dipakai? Kamu sering ngetik perintah yang sama berulang-ulang.
Gimana Caranya?

Pakai perintah git config --global alias.alias>asli>

* Contoh alias favorit:

bash
        git config --global alias.st status # git st -> git status
        git config --global alias.ci commit # git ci -> git commit
        git config --global alias.co checkout # git co -> git checkout
        git config --global alias.br branch # git br -> git branch
        git config --global alias.di diff # git di -> git diff
        git config --global alias.lg "log --oneline --graph --all --decorate" # git lg -> git log ...

Tips: Bikin alias buat perintah-perintah yang paling sering kamu pakai. Ini kelihatan sepele tapi bisa hemat banyak waktu dan energi lho! Kamu bisa lihat semua alias yang udah diset di file konfigurasi Git globalmu (biasanya di ~/.gitconfig).

Penutup

Memahami Git itu kayak belajar bahasa baru. Awalnya kaku, banyak yang nggak ngerti, bikin pusing. Tapi kalau udah terbiasa dan kenal fitur-fitur lain di luar yang dasar, Git itu bener-bener powerful banget. Bisa bikin kerjaan kita lebih rapi, kolaborasi lancar, dan yang penting, nggak panik kalau ada kesalahan.

Tips-tips di atas cuma sebagian kecil dari apa yang bisa Git lakuin. Masih banyak lagi kayak git tag, git blame, git bisect, dll. Nggak perlu hafal semuanya langsung kok. Pelajari yang paling sering kamu butuhin dulu, coba di proyek personal, jangan takut eksperimen (di branch terpisah atau proyek dummy ya!).

Yang paling penting, jangan takut nyoba dan jangan sungkan tanya ke temen atau cari di internet kalau mentok. Komunitas Git itu besar banget, pasti ada aja yang pernah ngalamin masalah serupa.

Semoga abis baca ini, Git nggak lagi jadi momok yang bikin pusing, tapi jadi tool andalan yang bikin pengalaman ngodingmu makin enak! Selamat mencoba!