Panduan Git dari Beej

• Ini adalah halaman panduan yang menyediakan distribusi HTML dan PDF dalam berbagai format bagi pembaca yang ingin mempelajari atau merujuk Git
• Panduan ini sendiri berangkat dari asumsi bahwa kesalahan mungkin ada, dan menerima usulan perbaikan melalui email untuk konten Git yang keliru
• Distribusi HTML dapat dipilih sesuai lingkungan baca, seperti versi terbagi, satu halaman, widescreen, ZIP, dan lainnya
• PDF dapat diunduh dalam kombinasi US Letter dan A4, satu sisi atau dua sisi, versi dengan penyorotan sintaks atau hitam-putih
• Penerjemah dan penulis dapat meng-clone seluruh materi dari GitHub, lalu mengerjakannya dengan mengikuti README

---

Format distribusi untuk membaca

• HTML

  • HTML
  • HTML, widescreen
  • HTML, single page
  • HTML, single page, widescreen
  • HTML ZIP
  • HTML ZIP, widescreen

• PDF

  • US Letter, one sided, syntax highlighting
  • US Letter, two sided, syntax highlighting
  • A4, one sided, syntax highlighting
  • A4, two sided, syntax highlighting
  • US Letter, one sided, black and white
  • US Letter, two sided, black and white
  • A4, one sided, black and white
  • A4, two sided, black and white

Usulan perbaikan dan materi kerja asli

• Panduan ini membuka kemungkinan bahwa kesalahan mungkin ada, dan usulan perbaikan diterima melalui email
• Penerjemah dan penulis dapat meng-clone repositori GitHub dan mengikuti README

[GN⁺]

Komentar Hacker News

• Kalau menemukan bagian yang salah, silakan kirim. Akan saya rapikan dan perbaiki sendiri — Beej

  • Bukan salah, tetapi kalau membahas vim dalam konteks Git, :cq juga layak dimasukkan. Perintah itu keluar dengan status keluar non-nol, sehingga bisa membuat Git tidak menyelesaikan commit atau pekerjaan
  • Ini benar-benar karya yang luar biasa, dan terima kasih sudah membuat materi yang begitu komprehensif. Saya belum membaca semuanya, tetapi ada ungkapan di bagian 5.1 yang menarik perhatian
    Di https://beej.us/guide/bggit/html/split/branches-and-fast-for... disebutkan bahwa “branch default adalah main” dan “dulu master, dan repository lama masih memiliki master”, tetapi ini tidak tepat. Git masih memakai master sebagai default, dan hanya memungkinkan perubahan untuk git init melalui git config --global init.defaultBranch ke depannya
    Dasar: https://github.com/git/git/blob/bc204b742735ae06f65bb20291c9...
    Selain itu, ungkapan “repository lama” memberi pesan yang keliru. GitHub yang memutuskan perubahan ini dan pihak lain mengikutinya, sementara Git sendiri kemudian mengizinkan konfigurasi tadi; jadi ini bukan soal repository baru/lama, melainkan lebih dekat ke soal preferensi
  • Saya salah satu dari banyak siswa yang belajar di Lambda School, dan kelas saat itu adalah salah satu momen yang paling berkesan
  • Saya membaca panduan pemrograman C saat remaja, dan sekarang sebagai pengembang firmware saya masih merasa sangat berutang budi
  • Bukan salah, tetapi git worktree juga layak disebut. Dalam alur kerja saya itu sangat penting, dan banyak orang bahkan tidak tahu keberadaannya
    Ini cara yang bagus untuk menjaga branch agar tidak saling kusut tanpa repot mengurus stash

• Beej's Guide to Network Programming dan Beej's Guide to Unix IPC yang saya baca saat remaja mudah didekati tetapi tetap mendalam, dan sangat memengaruhi saya menjadi programmer seperti sekarang
  [0] https://beej.us/guide/bgnet/
  [1] https://beej.us/guide/bggit/

  • [1] adalah https://beej.us/guide/bgipc/
  • Saya juga mirip. Saya remaja pada pertengahan 90-an, dan terpukau oleh kode server IRCd dan bot
    Saya membeli Slackware Linux unleashed bekas yang disertai CD-ROM, dan di dalamnya ada contoh jaringan C. Kode-kode itu membingungkan saya, lalu saya menemukan situs networking Beej. Dari sana saya makin tenggelam dan masuk ke lubang kelinci yang dalam, sering berkeliling ke berbagai toko buku untuk mencari buku pemrograman
    Setelah membeli buku referensi luar biasa dari Richard Stevens, saya tidak pernah menoleh ke belakang, dan sampai sekarang saya masih berterima kasih kepada Beej karena memungkinkan gairah itu tumbuh
  • Saat belajar menggunakan select, saya ingat pernah menerjemahkan panduan jaringan Beej ke bahasa Italia karena ingin membuat suatu port scanner (mungkin “grabb”?) menjadi lebih cepat. Masa-masa yang menyenangkan
  • Saya datang untuk memastikan apakah ini orang yang sama, dan setelah melihat desain web lama yang tiap halamannya punya karakter sendiri, saya hampir yakin
    Itu masa ketika saya menyimpan halaman agar bisa dibaca offline supaya ayah tidak marah karena tagihan telepon, dan ketika kode berhasil berjalan, rasanya seperti validasi yang melampaui kegagalan dan penolakan hidup sebelumnya. Ada kegembiraan besar saat mengirim pesan dari satu komputer ke komputer lain

• Melihat “perintah lama: git checkout”, saya bahkan tidak tahu git switch ada, dan juga tidak tahu bahwa git checkout dianggap sebagai alternatif lama. Rasanya jadi tua
  Saya mulai belajar Git hampir 10 tahun lalu, jadi ya wajar saja, tetapi aneh rasanya bahwa orang yang belajar Git sekarang bisa bingung kenapa saya memakai git checkout. Rasanya seperti memakai ungkapan kuno
  Kembali ke artikelnya, kalau panduan ini ada saat saya belajar dulu, pasti sangat berguna. Mudah diikuti dan membahas pertanyaan-pertanyaan umum dengan baik
  Saya juga punya kenangan bagus tentang ketakutan saat menghadapi merge conflict pertama, lalu berhenti dan mencari jalan memutar demi menghindari conflict

  • git switch adalah perintah yang cukup baru dan pertama kali dirilis pada 2019
    Ada diskusi dari 2021 dan diskusi beberapa minggu lalu, dan pada diskusi yang terakhir juga disebutkan bahwa dalam dokumentasi git switch masih dianggap sebagai fitur eksperimental
    https://news.ycombinator.com/item?id=28024972
    https://news.ycombinator.com/item?id=42649858
  • Saya tidak melihat git checkout masih dianggap sebagai “alternatif lama”. Terakhir saya cek, switch masih eksperimental, dan saya juga tidak terpikir untuk meninggalkan alur kerja serta perintah yang saya pelajari saat belajar Git sekitar 15 tahun lalu
    Semua hal yang ingin saya lakukan masih bekerja persis sama, git checkout juga melakukan hal yang sama seperti dulu, dan tidak ada masalah saat berkolaborasi dengan orang lain menggunakan Git, jadi tidak ada alasan untuk mengubah alur kerja

• Fakta bahwa dibutuhkan panduan dengan lebih dari 30 bagian untuk menjelaskan cara memakai Git itu sendiri membuat saya merasa Git seperti kehilangan gambaran besarnya

  • Saya tidak mengerti kenapa programmer begitu marah besar pada fakta bahwa alat kompleks yang melakukan pekerjaan kompleks pada struktur data kompleks memang punya tingkat kompleksitas tertentu
  • Kalau orang-orang memakai setengah saja dari usaha yang mereka gunakan untuk mengeluh tentang Git untuk belajar Git, rasanya tidak perlu membuat panduan lebih dari 30 bagian untuk menjelaskan hal-hal yang bisa ditemukan di halaman manual
    Commit adalah snapshot dari tree, dan punya daftar ancestor. Biasanya satu, tapi tidak selalu begitu. Tag adalah label commit yang tidak berubah, sedangkan branch adalah label commit yang berubah. Index adalah proto-commit kecil yang sedang dikerjakan dan diisi dengan add sebelum commit
    Itulah Git. Kalau ingin tahu lebih banyak, jangan baca panduan; cukup cari hal seperti “cara berpindah ke commit Git tertentu tanpa memengaruhi tree”, “cara hanya meng-commit sebagian file yang sudah diubah”, atau “cara menyalin commit dari tempat lain ke tree saat ini”
    Abstraksi dasarnya minimalis dan mudah. Hal-hal yang ingin dilakukan dengan abstraksi itu yang canggih dan kompleks. Pelajari yang pertama dan cari yang kedua; tidak perlu membaca panduan
  • Cara memakai Git bisa dijelaskan dalam 5 baris komentar HN: git clone, git checkout, git pull, git add + commit + push, git reset / rebase
  • Meski begitu, tetap bisa berakhir merugikan diri sendiri
  • Ya dan tidak. Perintah untuk pengguna di Git mungkin sudah cukup baik untuk 95% pengguna
    rebase -i punya panduan tentang perintah mana melakukan apa, dan cara memformat keluaran git log sesuai selera dan kompromi bisa dijelaskan dalam beberapa paragraf. Biasanya saya menganggap perintah untuk pengguna juga mencakup hal-hal yang cukup campur aduk seperti git gc, git fsck, dan git rev-parse
    Perintah level rendah jelas lebih sulit dipahami, dan melakukan banyak hal tersendiri yang tidak selalu mudah dilakukan dengan perintah untuk pengguna yang dioptimalkan untuk kasus penggunaan umum
    Singkatnya, Git itu besar bahkan raksasa, tetapi bagi sebagian besar developer, banyak fitur yang disediakannya berada jauh dari jalur utama

• Yang menakutkan adalah betapa panjangnya panduan ini
  Saya tahu panduan-panduan Beej umumnya komprehensif, tetapi sebelum melihat ini saya belum benar-benar merasakan betapa luasnya nuansa Git
  Dengan Jujutsu, rasanya panduannya akan jauh lebih tipis, atau setidaknya lebih mudah ditemukan dan dipelajari secara bertahap oleh manusia

  • Sebagian besar panduan saya saya buat agar orang bisa berhenti membaca ketika merasa sudah cukup. Tidak perlu membaca semuanya
    Saya merasa panduan ini hanya mencakup sekitar 10% Git, tetapi saya berharap mencakup 90% penggunaan umum
  • Panduan ini berada di sisi yang komprehensif; di ekstrem sebaliknya ada materi satu halaman yang memuat 90% perintah Git yang akan Anda perlukan ke depan: https://wizardzines.com/git-cheat-sheet.pdf
  • Ini terlihat seperti tanda bahwa Git bukan alat yang cocok untuk kebanyakan orang, tetapi entah bagaimana terlanjur mengeras menjadi semacam standar

• Di kantor, sekali atau dua kali setahun saya mengadakan kelas pengantar model data Git selama 2 jam
  Saya benar-benar masuk ke dalam direktori .git, membongkar file-file, dan menunjukkan bahwa semuanya hanyalah representasi teks biasa dari struktur data dasar. Sangat keren melihat momen ketika orang-orang tiba-tiba memahaminya di kepala mereka
  Kami membagikan dokumen resep Git dasar agar pegawai baru bisa mulai meng-commit kode, tetapi kebanyakan hanya mengikutinya tanpa memahami apa yang sedang terjadi
  Sebaliknya, orang yang mengikuti kelas, meski tidak tahu semua perintah dengan baik, memiliki pemahaman kerja yang cukup masuk akal tentang apa yang sebenarnya terjadi di Git. Perintah mudah dicari, jadi selama model mental-nya benar, perintah itu sendiri bukan masalah besar. Namun hampir semua diskusi tulisan Git di HN tetap mengarah ke pembahasan command line
  Menariknya, kelas ini terdengar mirip dengan teks alternatif di https://xkcd.com/1597/. Bedanya, untuk pembaca teknis, itu benar-benar cara yang tepat untuk mengajarkan Git, dan setelah memahaminya sekali, mereka mendapat pemahaman dasar yang tidak akan terlupakan
  Jujur saja, rasio hasil terhadap waktu untuk ini sangat tinggi sampai aneh kalau tidak dilakukan

  • Saya juga pernah melakukannya sekali dan itu benar-benar bagus; diskusi setelahnya juga sangat hebat
    Di slide terakhir presentasi, saya memasukkan pertanyaan yang harus dijawab rekan-rekan berdasarkan model data Git. Misalnya “Bisakah commit dipindahkan ke branch lain?” dan “Apa yang menjamin bahwa graf commit tidak memiliki siklus?”
    Sangat memuaskan melihat orang-orang tidak hanya memakai Git, tetapi mulai berpikir dalam Git
  • Kalimat “selama model mentalnya benar, perintah bukan masalah besar” awalnya mungkin terdengar seperti logika yang sering terlihat pada era 90-an: “Kalau memahami semua lapisan dan semua bagian Linux, memakai Linux itu mudah.” Secara teori benar, tetapi bagi kebanyakan orang terdengar tidak realistis
    Untungnya, sejak awal saya menonton video yang menjelaskan sebagian model internal Git, dan saya menyadari bahwa dalam praktiknya, pengetahuan internal tidak perlu sebanyak atau sedalam itu untuk membuat perbedaan besar. Mengetahui sekitar 5% cara kerja Git saja sudah membuat saya jauh lebih memahami apa yang dilakukan perintah dan bagaimana seharusnya dipakai
  • Saya penasaran apakah materi atau rekaman kelas 2 jam itu bisa dibagikan, jika tidak ada informasi proprietari atau batasan yang menghalangi publikasinya
    Jika didasarkan pada materi yang tersedia publik dan cukup ringkas untuk masuk dalam 2 jam, akan bagus kalau dibagikan di thread ini atau sebagai tulisan HN. Saya percaya semakin banyak materi belajar untuk topik yang sama dengan premis, analogi, dan fokus berbeda, semakin baik
  • Saya penasaran apakah ada salinan presentasi atau videonya, atau materi serupa yang bisa direkomendasikan
  • Tolong bagikan videonya

• Saya cukup bisa mengikuti alur umum Git, merge, rebase, dan sebagainya, tetapi alih-alih berusaha menjadi lebih mahir dengan Git, saya serius mempertimbangkan pindah ke jujutsu. jj kompatibel dengan Git, dan saya bisa memakainya sendiri sementara rekan-rekan tetap memakai Git

• Saya merasa ada satu trik yang terlewat oleh banyak panduan dan sebagian besar GUI Git. Sebagai pengecualian, magit menanganinya dengan baik
  Yaitu menetapkan branch upstream bukan ke origin/feature/foo milik feature/foo, melainkan ke target yang ingin digabungkan, yakni branch integrasi seperti master atau origin/master
  Dengan begitu, banyak hal menjadi lebih sederhana. Saat menjalankan git status, Git memberi tahu seberapa jauh branch itu menyimpang dari branch integrasi, yang berguna; dan jika menjalankan git rebase tanpa argumen, branch langsung di-rebase ke atas upstream
  Menjadikan origin/feature/foo sebagai upstream kurang berguna. Para developer umumnya juga “memiliki” branch mereka sendiri di remote, jadi seberapa jauh branch itu menyimpang dari sana tidak terlalu berarti, dan hampir tidak ada alasan ingin me-rebase ke sana
  Jika push.default disetel ke "current", git push juga akan, sesuai harapan, mendorong feature/foo ke origin/feature/foo
  Saya penasaran mengapa pengaturan seperti ini tidak lebih umum

• Bagian kolaborasi sama sekali tidak membahas branch fitur. Rasanya itu pola kerja yang cukup umum
  Akan bermanfaat jika dibandingkan dengan “cara semua orang memakai branch masing-masing” dalam panduan tersebut. Selain itu, di bagian 17, mungkin layak dibahas cara memakai ulang branch untuk pull request GitHub versus membuat branch baru untuk setiap PR

• Saya belum membaca tulisannya, tapi sepertinya bagus. Rekomendasi lain adalah kursus Git di boot.dev yang diajarkan oleh Primeagen
  Kursusnya interaktif dan masuk cukup dalam hingga tingkat memanipulasi langsung file di dalam direktori .git. Setelah mengikuti kursus itu, saya mendapatkan model mental yang benar-benar baru tentang bagaimana Git bekerja