Tip dan Trik Git

• Bahkan pengguna yang sudah lama memakai Git pun mudah melewatkan fitur yang kurang dikenal, sehingga anggapan bahwa pengetahuan command line tingkat lanjut sudah umum menjadi goyah
• Berbeda dengan generasi yang bermigrasi dari SVN atau CVS, pengembang yang hanya pernah memakai Git punya lebih sedikit kesempatan untuk mempelajari cara penggunaan tingkat lanjut
• Seiring waktu, Git terus menambahkan fitur-fitur kecil namun berguna, dan perubahan seperti ini bisa punya nilai praktis dalam situasi tertentu
• Untuk pengguna menengah hingga mahir, topik tentang fitur lama namun berguna, fitur yang baru ditambahkan, serta repositori besar dan monorepo dibagi menjadi seri singkat 3 bagian
• Jika meninjau kembali fitur-fitur yang tidak terlihat dari kebiasaan penggunaan Git yang sudah akrab, pekerjaan harian di repositori bisa ditangani dengan lebih efisien

---

Alasan melihat kembali Git

• Saat baru-baru ini membawakan presentasi tentang Git dan GitButler, terkonfirmasi bahwa banyak pengembang masih punya bagian yang belum mereka ketahui tentang Git
• Dulu saya sering membawakan presentasi Git tingkat lanjut, tetapi sekitar 10 tahun terakhir saya menganggap orang-orang sudah mengetahui fitur command line tingkat lanjut
• Generasi pengembang yang hanya pernah memakai Git tidak perlu berpindah dari alat seperti SVN atau CVS ke Git, atau mempelajari ulang konsep-konsep sebelumnya
• Git juga mempelajari fitur-fitur baru seiring waktu, dan meskipun kebanyakan perubahan itu halus atau ditujukan untuk penggunaan tertentu, semuanya tetap bisa membantu pekerjaan nyata
• Seri blog ini disusun berdasarkan presentasi FOSDEM 2024 little known Git stuff

Seri tip Git dalam 3 bagian

• Ditujukan untuk pengguna Git tingkat menengah hingga mahir, membahas fitur-fitur yang mungkin terlewat bahkan oleh mereka yang sudah lama memakai Git
• Alih-alih dimuat semuanya dalam satu tulisan, isinya dibagi menjadi tiga tulisan singkat berdasarkan beberapa topik
• Topik yang dibahas:
  • Oldies but Goodies: fitur Git lama tetapi tetap berguna
  • Some Subtle New Things: perubahan halus yang baru ditambahkan ke Git
  • Really Large Repositories and Monorepos: pembahasan tentang repositori yang sangat besar dan monorepo
• Tulisan pertama berlanjut ke Oldies but Goodies

[GN⁺]

Komentar Hacker News

• Sebagai penulis, ia mengakui bahwa cukup banyak dari hal-hal ini baru dipelajarinya belakangan ini. Fitur terkait repositori besar adalah sesuatu yang selama beberapa tahun terakhir dimasukkan sedikit demi sedikit oleh Microsoft dan GitHub ke dalam core Git, sehingga sulit menemukan materi yang merangkum pekerjaan mereka di satu tempat
  Ia juga melakukan percakapan menarik dengan orang-orang Mercurial, dan mereka mengatakan belakangan ini mendapatkan peningkatan kecepatan yang mengejutkan dengan menulis sebagian internal Hg dalam Rust
  Ia juga sedang mempertimbangkan Pro Git edisi ke-3, jadi ia meminta orang-orang memberi tahu hal-hal yang mereka pelajari dengan susah payah saat mempelajari Git, atau hal-hal yang ingin mereka ketahui
  • Mungkin Anda sudah tahu, tetapi difftastic bagus dipakai sebagai pengganti diff Git: https://difftastic.wilfred.me.uk/
    Alias gitconfig yang sering dipakai adalah fza, gone, dan root. git fza menampilkan file yang dimodifikasi/baru di jendela fzf lalu meneruskan file yang dipilih ke git add: https://github.com/junegunn/fzf
    git gone menghapus branch lokal yang tidak ada di remote, dan git root mencetak root repositori sehingga enak untuk kembali ke root dari direktori yang dalam. Belakangan ini jadi lebih jarang dipakai karena menggunakan zoxide: https://github.com/ajeetdsouza/zoxide
  • Di bagian terkait perbedaan whitespace, sebaiknya ignore-revs-file juga dimasukkan. Commit file ignore-revs ke repositori, lalu orang yang melakukan reformat besar menambahkan SHA terkait agar git blame tidak rusak
    https://git-scm.com/docs/git-blame#Documentation/git-blame.txt---ignore-revltrevgt
  • Salah satu hal yang dipelajari dengan susah payah tentang Git adalah bahwa operasi seperti merge, cherry-pick, dan rebase tidak bekerja sebagai snapshot, melainkan sebagai perbedaan dan patch—lebih tepatnya merge 3-arah. Pro Git memang menekankan model penyimpanan snapshot Git dengan baik, tetapi jika hanya memikirkan model ini, terutama saat rebase, hal itu bisa membingungkan
    Misalnya, saat rebase, ia tidak paham mengapa semua commit berikutnya berubah padahal hanya satu commit yang dihapus. Pada akhirnya, rebase baru bisa dipahami setelah menyadari bahwa penyimpanannya berbasis snapshot, tetapi operasinya berbasis perbedaan; menekankan bagian ini lebih kuat saat mengajar juga akan membantu
• Saya tidak ingin mempelajari trik-trik Git; saya ingin memakainya sesederhana mungkin. Saya hanya ingin push kode, selesai dengan Git, lalu lanjut bekerja
  Saya menghormati orang-orang yang menyukai Git, tetapi bagi saya itu hanyalah alat yang harus dipakai
  • Sebagian kompleksitas Git berasal dari fakta bahwa Git awalnya dirancang sebagai plumbing tingkat rendah. Harapannya, di atas model data Git akan muncul permukaan pengguna (porcelain) yang lebih ramah, jadi untuk mendapatkan UI yang sederhana dan konsisten, mungkin arah itu masih lebih baik. Jujutsu dan Got (game of trees) bisa menjadi contoh seperti itu
  • Saya memahami perasaan itu, tetapi Git tidak sesulit itu. Di luar checkout/commit/push dasar, mengetahui beberapa hal—terutama penulisan ulang histori—bisa sangat meningkatkan kualitas riwayat commit dan memudahkan engineer lain di proyek memahami alurnya
    Git tampaknya akan tetap menjadi semacam konstanta jangka panjang di industri, dan karena ini salah satu alat yang paling sering disentuh dalam pengembangan sehari-hari, layak untuk sedikit dipelajari
  • Ada detail yang memang melekat pada masalahnya sendiri, dan ada yang tidak. Saya rasa orang cenderung meremehkan kesulitan yang memang inheren
    Karena itu saya pikir tidak masalah jika kompleksitas Git ada sampai tingkat tertentu
  • Kedengarannya mirip seperti mengatakan tidak ingin belajar pemrograman dan ingin memakai komputer sesederhana mungkin. Seolah-olah hanya ingin mengatakan apa yang harus dilakukan lalu selesai
  • Antarmuka Git terasa seperti abstraksi yang bocor. Saya tidak ingin mempelajari trik-trik Git, tetapi akhirnya jadi tahu lebih banyak daripada yang saya inginkan
• Saya baru belajar tentang core.fsmonitor. Dari sudut pandang monorepo besar, saya berharap git clone punya opsi resume
  Pada tahun 2000-an saya mengalami masalah yang sama ketika mencoba meng-clone repositori kernel dengan koneksi ber-bandwidth rendah; setelah meminta bantuan di mailing list, barulah saya bisa mendapatkannya karena seseorang mengunggah seluruh repositori sebagai tar terkompresi di situs pribadinya
  Bahkan sekarang, jika VPN perusahaan terputus sebentar, masalah yang sama kadang terjadi saat meng-clone repositori besar. Bayangkan sudah mengunduh 95% dari repositori Windows sebesar 300GB lalu Wi-Fi terputus sebentar
  Aneh rasanya dua alat besar yang banyak memakai bandwidth dalam stack pengembangan modern, Git dan Docker, tidak mendukung resume unduhan dengan baik
  • Yang Anda inginkan tampaknya mendekati git bundle. Namun syaratnya, sejak awal harus ada seseorang yang membuat bundle tersebut
    https://git-scm.com/docs/git-bundle
  • Sepertinya bisa dilakukan dengan shallow clone lalu memperluasnya beberapa kali. Meski begitu, protokol fetch/push pada dasarnya cenderung mengasumsikan repositori yang lebih kecil atau koneksi internet dan server yang sangat bagus
• Sangat menarik. Saya ingin melihat siapa yang bisa memecahkan masalah ketika banyak orang berkontribusi pada rilis, fitur, dan hotfix yang berbeda, memberi tag pada rilis, serta kembali ke masa lalu untuk mencari bug, dengan antarmuka yang lebih mudah
  Ini mirip dengan mengatakan menginginkan bahasa tingkat rendah yang menyembunyikan kompleksitas sistem; keduanya pada dasarnya saling eksklusif. Git memuaskan dan tidak terlalu sulit dipelajari, jadi sebagian orang memang perlu belajar Git saja
  • Karena itu saya sangat merekomendasikan GitKraken. Saya agak berhati-hati karena ini produk berbayar, tetapi saya sudah mencoba berbagai alat, dan tidak ada yang membuka kekuatan Git sebaik GitKraken
    Ia menyingkirkan kotak hitam yang dirasakan banyak developer di terminal, menempatkan graf di depan, dan menampilkan operasi rebase secara visual dengan alami sehingga Git menjadi menyenangkan
    Kemahiran CLI tetap bernilai, tetapi menyebalkan melihat developer dengan pengalaman 10 tahun tersandung saat menyelesaikan masalah dasar, atau merusak histori proyek karena suasana bahwa “engineer sejati harus memakai Git CLI saja”
    Sekarang, meskipun memakai CLI, saya menyarankan agar sepanjang hari tetap melihat graf di jendela lain. Itu bisa dilakukan gratis di VS Code, JetBrains, bahkan CLI

Ketika anggota tim menggabungkan PR, saya langsung melihatnya dan me-rebase branch saya, sehingga branch selalu mutakhir berbasis main dan tidak meninggalkan neraka merge atau commit “fix conflicts” yang mengerikan

• Saat mencari 10 file teratas yang paling banyak diubah sejak dibuat kemarin, saya menemukan https://github.com/tj/git-extras/blob/main/Commands.md
  Ada banyak perintah tambahan Git yang berguna

  • git-extras itu bagus. Alat lain yang juga oke adalah git absorb: https://github.com/tummychow/git-absorb

• Klien UI modern seperti GitKraken cukup layak dipakai dan membantu, jadi saya kurang paham kenapa kebanyakan developer bersikeras tetap memakai Git CLI: https://www.gitkraken.com/

  • Pengetahuan CLI berujung pada penulisan skrip, dan pengetahuan Git yang dipelajari dari skrip kembali berguna dalam pemakaian sehari-hari. Saya tidak ingin merasa tidak berdaya hanya karena harus memakai CLI saat masuk via SSH ke Raspberry Pi yang dipakai sebagai server
    Saya tidak sepenuhnya menentang GUI, tetapi saat ini CLI lebih efisien, dan saya tidak ingin menghabiskan waktu mencari GUI yang memenuhi syarat berikut
    Tampilannya bagus, berupa aplikasi native dan bukan sekadar browser web lawas yang disisipkan, tanpa telemetri atau dimatikan secara default, sepenuhnya open source, dan bisa diharapkan masih ada 5 tahun lagi
    Selain itu, jangan sampai malah membuat lebih membingungkan. Di perusahaan lama saya pernah harus memakai Visual Studio, dan ada tombol yang sebenarnya berarti “tandai sebagai konflik sudah diselesaikan”, tetapi secara menyeramkan tertulis “Accept merge”
    Jangan membingungkan orang yang sudah mengharapkan kata tertentu punya arti tertentu, dan perilaku seperti tombol “Commit changes” yang katanya ramah tetapi sekalian melakukan push ke remote juga sulit dipercaya
  • CLI juga cukup layak dipakai. Saya juga memakai plugin editor, tetapi kalau sudah berada di command line, saya selesaikan dari sana
    Kalau harus berpindah ke program lain hanya untuk membuat satu commit, motivasi untuk sering commit jadi berkurang
  • Kecuali ada masalah yang sangat spesifik, saya meminimalkan hal-hal yang saya lakukan dengan Git. Dalam kasus saya praktis hanya sekitar push, pull, checkout, jadi memakai GUI terasa berlebihan
  • Kelihatannya rapi, tetapi antarmuka grafis terlalu mudah membuat terdistraksi. Pada akhirnya ini tampak seperti soal preferensi pribadi, dan CLI itu cepat tetapi kurva belajarnya besar
    Saat memakai Git di CLI pun, sebagian besar bukan hal istimewa, hanya beberapa perintah; tips atau trik yang jarang dipakai saya catat di file teks

• Saya sudah tahu -committerdate, tetapi tidak tahu itu bisa diatur sebagai pengurutan default, dan ini sangat berguna. Ada beberapa catatan
  git columns cukup membingungkan kalau tidak muat di layar dan harus menggulir, jadi akan bagus kalau ada angka
  git maintenance terlihat bagus, tetapi saya khawatir karena banyak melakukan rebase. Saya penasaran apakah objek loose akan hilang lebih cepat dibanding gc. Terlihat gc dimatikan, tetapi tidak jelas
  Terkait git blame, ada skrip yang kurang dikenal tetapi berguna: https://github.com/gnddev/git-blameall. Saking kurang terkenalnya, saya harus mem-porting sendiri ke Python 3, padahal saya bukan developer Python

  • Dalam maintenance terjadwal, gc dinonaktifkan. Saat menjalankan maintenance run secara eksplisit, itu diaktifkan sebagai task
    Objek loose tidak dikumpulkan lebih cepat dibanding gc. Pada akhirnya itu hanya karena menjalankan gc
  • Saya penasaran apakah pengurutan terbalik bisa dilakukan. Solusi sederhana untuk masalah branch terdorong keluar layar tampaknya adalah menaruh branch terbaru di bagian akhir. Saya melakukannya dengan skrip pengguna
  • Tidak akan hilang lebih cepat. Ia hanya lebih sering mengambil data dari remote dan me-repack data. Jika GC dimatikan, data tidak dihapus
    git-blameall terlihat oke, jadi sepertinya perlu saya coba

• Saya menyederhanakan alur Git secara signifikan dengan beberapa alias yang bekerja di berbagai environment
  git synced menyinkronkan branch saat ini dengan rebase ke upstream jika ada, atau ke origin jika tidak ada. Menggunakan master atau main, dengan prioritas ke main
git pub memublikasikan perubahan ke remote origin, dan memakai force push dengan lease
  git pr membuka URL PR yang sesuai di GitHub tanpa perlu klien GH. Jika upstream didefinisikan, PR dikirim ke sana
  git hub membuka halaman GitHub repositori
  https://softwaredoug.com/blog/2022/11/09/idiot-proof-git-aliases.html

  • Saya penasaran kenapa memilih panah aneh berbulu itu sebagai pemisah

• Saya berhenti berpura-pura tahu apa yang saya lakukan dan memakai alat Git visual. Misalnya SmartGit atau alat yang ada di IntelliJ. Menurut saya, “pahlawan command line” Git lebih mendekati pamer
  Lapisan perintah untuk pengguna bisa menjengkelkan karena membingungkan. Misalnya Yours dan Theirs bisa berarti kebalikan total tergantung konteks
  Tidak ada gaya atau tema yang konsisten di seluruh antarmuka pengguna, jadi diperlukan lapisan visual baru agar tidak membuat orang gila

  • Saya juga begitu. Saya suka bisa selalu melihat diff dan memeriksa secara visual sekilas apa yang akan terjadi. Tidak perlu menjalankan beberapa perintah tambahan
    Saya hanya tahu aplikasi dan Git secara umum sebatas yang diperlukan untuk pekerjaan, dan kalau suatu saat butuh lebih, tinggal cari. Selama bertahun-tahun memakainya, kasus seperti itu hanya sekali dua kali
  • Untuk pekerjaan sehari-hari, saya selalu memakai alat Git visual, terutama Tortoise Git
    Untuk pekerjaan kompleks memperbaiki kesalahan orang lain atau kesalahan saya sendiri, pertama-tama saya juga memakai alat visual untuk melihat history, commit, reflog, dan diff, lalu memahami apa yang kacau dan apakah ada yang bisa diselamatkan
    Kalau hanya ada satu commit untuk kembali, saya melakukan reset --hard; kalau perlu menggabungkan sesuatu dari beberapa commit, biasanya saya memakai command line

• Keduanya tidak saling eksklusif. Untuk hal seperti diff atau konflik, saya hanya memakai alat visual, tetapi saya mendapat banyak manfaat dari mempelajari objek commit, reflog, apa yang dilakukan rebase di balik layar, rebase interaktif, hard/soft reset, dan sebagainya.