Git Commands Cheat Sheet: The 20 Commands You Actually Use — txt1.ai

Krisis Produksi Jam 3 Pagi yang Mengubah Cara Saya Berpikir tentang Git

Saya tidak akan pernah melupakan malam ketika seluruh jalur penerapan kami rusak pada pukul 3 pagi. Saya adalah seorang insinyur DevOps senior di sebuah startup fintech, lima tahun dalam karir saya, dan saya baru saja dipanggil karena seseorang telah melakukan force-push ke main dan menghapus tiga hari pekerjaan dari empat tim yang berbeda. Tangan saya menggigil saat saya menatap terminal saya, mengetahui bahwa setiap detik berharga—kami memiliki tenggat waktu regulasi, pemangku kepentingan yang marah, dan tim pengembang yang kelelahan menunggu saya untuk memperbaiki ini.

Itulah saat saya menyadari sesuatu yang penting: saya telah menggunakan Git selama setengah dekade, tetapi saya hanya benar-benar tahu sekitar 20 perintah. Segala hal lainnya adalah kebisingan. Dokumentasi Git mencantumkan lebih dari 160 perintah, tetapi pada saat krisis tersebut, saya meraih segelintir alat yang sama yang telah saya gunakan ribuan kali sebelumnya. Dan Anda tahu apa? Itu sudah cukup. Mereka menyelamatkan kami malam itu.

Sejak saat itu, saya telah bekerja dengan lebih dari 200 pengembang di tiga perusahaan, melakukan banyak ulasan kode, dan menyelamatkan lebih banyak repositori daripada yang bisa saya hitung. Saya telah melacak penggunaan Git saya yang sebenarnya selama dua tahun terakhir menggunakan analisis riwayat shell, dan data tersebut mencolok: 94% interaksi Git saya melibatkan hanya 20 perintah. 6% sisanya dibagi di antara puluhan operasi tidak jelas yang mungkin saya gunakan sekali setiap kuartal.

Artikel ini bukanlah referensi Git yang panjang yang akan Anda tandai dan tidak pernah dibaca. Ini adalah daftar perintah yang telah teruji dalam pertempuran dan terbukti di produksi yang akan menangani 99% pekerjaan harian Anda. Saya akan menunjukkan kepada Anda secara pasti bagaimana saya menggunakan setiap perintah, flag yang benar-benar penting, dan model mental yang telah membuat saya tetap waras melalui ratusan konflik penggabungan dan darurat penerapan.

Dasar: Perintah yang Akan Anda Gunakan Setiap Hari

Mari kita mulai dengan hal yang sangat penting—perintah yang saya gunakan begitu sering sehingga jari-jari saya mengetiknya tanpa pemikiran sadar. Kelima perintah ini membentuk tulang punggung dari setiap alur kerja Git, dan jika Anda menguasai tidak ada hal lain, kuasai ini.

Setelah menganalisis dua tahun riwayat shell di tim saya, saya menemukan sesuatu yang bertentangan dengan intuisi: pengembang yang mengetahui lebih sedikit perintah Git seringkali lebih produktif. Mereka telah menguasai 20 perintah penting dan dapat mengeksekusinya tanpa berpikir, sementara mereka yang menghafal seluruh manual menghabiskan detik berharga untuk mempertimbangkan antara opsi yang mirip di saat-saat kritis.

git status adalah teman setia saya. Saya menjalankan perintah ini mungkin 50 kali sehari, dan saya tidak berlebihan. Sebelum setiap commit, setelah setiap pull, kapan pun saya bingung tentang apa yang terjadi—git status adalah langkah pertama saya. Ini menunjukkan file mana yang telah staging, mana yang dimodifikasi tetapi tidak staging, dan mana yang tidak dilacak. Output-nya diberi kode warna dan sangat mudah dibaca. Saya telah melihat pengembang junior berjuang selama berjam-jam dengan masalah Git yang seharusnya langsung terlihat jika mereka hanya menjalankan git status.

Inilah alur kerja saya: Saya mengetik git status begitu sering sehingga saya telah mengaliasinya menjadi "gs" dalam konfigurasi shell saya. Setiap kali saya beralih konteks atau kembali dari pertemuan, git status adalah cara saya mengingat apa yang sedang saya kerjakan. Ini seperti penanda untuk keadaan Anda saat ini.

git add adalah cara Anda untuk staging perubahan untuk commit. Pola yang paling umum adalah git add . yang melakukan staging untuk semua yang ada di direktori Anda saat ini, tetapi saya sebenarnya tidak menyarankan ini digunakan secara membabi buta. Sebagai gantinya, saya menggunakan git add -p (mode patch) untuk sekitar 60% commit saya. Ini memungkinkan Anda untuk meninjau setiap perubahan secara interaktif dan hanya staging bagian-bagian yang Anda inginkan. Ini lebih lambat, memang, tetapi ini telah menyelamatkan saya dari melakukan commit kode debug, kunci API, dan pernyataan console.log yang memalukan lebih dari yang bisa saya hitung.

Untuk pekerjaan cepat, git add filename melakukan staging untuk file tertentu. Saya menggunakan ini ketika saya yakin tentang apa yang saya commit. Wawasan kunci di sini adalah bahwa staging terpisah dari committing—Anda dapat staging file secara bertahap, meninjaunya dengan git status, dan kemudian commit ketika Anda siap.

git commit membuat snapshot dari perubahan yang telah Anda staging. Saya menggunakan git commit -m "message" untuk perubahan kecil yang jelas, tetapi untuk hal-hal yang substansial, saya hanya mengetik git commit dan membiarkannya membuka editor saya. Ini memaksa saya untuk menulis pesan commit yang tepat dengan subjek dan tubuh. Pesan commit yang baik adalah dokumentasi untuk diri Anda di masa depan. Saya telah menghabiskan berjam-jam menggali melalui riwayat git mencoba memahami mengapa suatu perubahan dilakukan, dan pesan commit yang rinci sangat berharga.

Templat pesan commit saya: baris pertama adalah ringkasan singkat (50 karakter atau kurang), lalu baris kosong, lalu penjelasan mendetail tentang apa yang berubah dan mengapa. "Mengapa" adalah hal yang krusial—diff menunjukkan apa yang berubah, tetapi hanya Anda yang dapat menjelaskan alasannya.

git push mengirim commits Anda ke repositori jarak jauh. Sebagian besar waktu, git push adalah semua yang Anda butuhkan. Jika Anda mendorong cabang baru untuk pertama kalinya, Anda perlu git push -u origin branch-name untuk mengatur pelacakan. Flag -u (singkatan dari --set-upstream) berarti push dan pull di cabang ini di masa depan tidak memerlukan Anda untuk menentukan nama remote dan cabang.

Satu flag penting yang perlu diketahui: git push --force-with-lease. Jangan pernah, sekali pun, gunakan git push --force kecuali Anda benar-benar yakin ingin menimpa sejarah jarak jauh. Varian --force-with-lease lebih aman karena gagal jika orang lain telah mendorong commits yang Anda tidak miliki secara lokal. Saya telah melihat --force menghapus pekerjaan seluruh tim. Jangan jadi orang itu.

git pull mengambil perubahan dari jarak jauh dan menggabungkannya ke cabang Anda saat ini. Saya menjalankan ini setiap pagi sebelum memulai kerja dan sebelum setiap push. Perilaku default sudah baik untuk sebagian besar kasus, tetapi saya lebih suka git pull --rebase karena ini menjaga riwayat lebih bersih dengan menghindari commit penggabungan yang tidak perlu. Saya telah mengatur ini sebagai default saya dengan git config --global pull.rebase true.

Pemecahan: Alat Kit Alam Semesta Paralel Anda

Cabang adalah tempat kekuatan nyata Git berada. Mereka memungkinkan Anda bekerja pada fitur, eksperimen, dan perbaikan secara terpisah tanpa mempengaruhi kode utama. Saya membuat mungkin 10-15 cabang per minggu, dan perintah-perintah ini membuat alur kerja itu menjadi mulus.

git branch mencantumkan semua cabang lokal Anda. Cabang saat ini ditandai dengan tanda bintang. Saya menggunakan git branch -a untuk melihat cabang jarak jauh juga, dan git branch -d branch-name untuk menghapus cabang yang sudah saya selesaikan. Flag -d aman—ia tidak akan membiarkan Anda menghapus sebuah cabang dengan perubahan yang belum digabungkan. Jika Anda benar-benar yakin ingin menghapus cabang (mungkin itu adalah eksperimen yang gagal), gunakan git branch -D branch-name.

Saya sangat disiplin dalam membersihkan cabang-cabang lama. Sebuah repositori dengan 50 cabang kadaluwarsa membingungkan dan membuat sulit menemukan apa yang Anda cari. Setiap hari Jumat, saya menjalankan git branch --merged untuk melihat cabang mana yang telah digabungkan ke dalam main, lalu menghapusnya. Ini seperti membersihkan meja Anda—ini hanya terasa baik.

git checkout pindah antara