-
1. Untuk Bermula
-
2. Git Basics
- 2.1 Mendapatkan suatu Repositori Git
- 2.2 Merekodkan Perubahan bagi Repositori
- 2.3 Viewing the Commit History
- 2.4 Undoing Things
- 2.5 Working with Remotes
- 2.6 Tagging
- 2.7 Alias Git
- 2.8 Summary
-
3. Git Branching
- 3.1 Branches in a Nutshell
- 3.2 Basic Branching and Merging
- 3.3 Branch Management
- 3.4 Branching Workflows
- 3.5 Remote Branches
- 3.6 Rebasing
- 3.7 Summary
-
4. Git on the Server
- 4.1 The Protocols
- 4.2 Getting Git on a Server
- 4.3 Generating Your SSH Public Key
- 4.4 Setting Up the Server
- 4.5 Git Daemon
- 4.6 Smart HTTP
- 4.7 GitWeb
- 4.8 GitLab
- 4.9 Third Party Hosted Options
- 4.10 Summary
-
5. Distributed Git
- 5.1 Distributed Workflows
- 5.2 Contributing to a Project
- 5.3 Maintaining a Project
- 5.4 Summary
-
6. GitHub
-
7. Git Tools
- 7.1 Revision Selection
- 7.2 Interactive Staging
- 7.3 Stashing and Cleaning
- 7.4 Signing Your Work
- 7.5 Searching
- 7.6 Rewriting History
- 7.7 Reset Demystified
- 7.8 Advanced Merging
- 7.9 Rerere
- 7.10 Debugging with Git
- 7.11 Submodules
- 7.12 Bundling
- 7.13 Replace
- 7.14 Credential Storage
- 7.15 Summary
-
8. Customizing Git
- 8.1 Git Configuration
- 8.2 Git Attributes
- 8.3 Git Hooks
- 8.4 An Example Git-Enforced Policy
- 8.5 Summary
-
9. Git and Other Systems
- 9.1 Git as a Client
- 9.2 Migrating to Git
- 9.3 Summary
-
10. Git Internals
- 10.1 Plumbing and Porcelain
- 10.2 Git Objects
- 10.3 Git References
- 10.4 Packfiles
- 10.5 The Refspec
- 10.6 Transfer Protocols
- 10.7 Maintenance and Data Recovery
- 10.8 Environment Variables
- 10.9 Summary
-
A1. Appendix A: Git in Other Environments
- A1.1 Graphical Interfaces
- A1.2 Git in Visual Studio
- A1.3 Git in Eclipse
- A1.4 Git in Bash
- A1.5 Git in Zsh
- A1.6 Git in Powershell
- A1.7 Summary
-
A2. Appendix B: Embedding Git in your Applications
- A2.1 Command-line Git
- A2.2 Libgit2
- A2.3 JGit
-
A3. Appendix C: Git Commands
- A3.1 Setup and Config
- A3.2 Getting and Creating Projects
- A3.3 Basic Snapshotting
- A3.4 Branching and Merging
- A3.5 Sharing and Updating Projects
- A3.6 Inspection and Comparison
- A3.7 Debugging
- A3.8 Patching
- A3.9 Email
- A3.10 External Systems
- A3.11 Administration
- A3.12 Plumbing Commands
1.1 Untuk Bermula - Mengenai Kawalan Versi
Bab ini akan mengenai bagaimana untuk bermula dengan Git. Kami akan bermula dengan menerangkan beberapa latar belakang yang ada pada alat kawalan versi, kemudian beralih kepada bagaimana untuk menjalankan Git pada sistem anda dan akhirnya bagaimana untuk membuatkannya bersiap sedia untuk mula bekerja. Pada akhir bab ini, anda haruslah memahami mengapakah Git digunakan di semua tempat, mengapakah anda perlu menggunakannya dan anda sepatutnya bersiap sedia untuk berbuat demikian.
Mengenai Kawalan Versi
Apakah itu “kawalan versi”, dan mengapakah harus anda mengambil perhatian mengenainya? Kawalan versi merupakan suatu sistem yang merekodkan perubahan yang dibuat kepada suatu fail atau set fail dari semasa ke semasa supaya anda boleh mengembalikan versi tertentu pasa masa hadapan. Untuk contoh-contoh dalam buku ini, anda akan menggunakan kod sumber perisian sebagai fail yang telah dikawal versi, walaupun hakikatnya anda boleh melakukan ini dengan hampir apa-apa jenis fail pada komputer.
Jika anda merupakan seorang pereka grafik atau laman web dan ingin untuk menyimpankan setiap versi bagi sesuatu imej atau susun atur (yang pasti anda inginkan), Sistem Kawalan Versi ataupun Version Control System (VCS) adalah antara perkara bijak yang boleh digunakan. Ia membolehkan anda mengembalikan semula fail terpilih kepada keadaan sebelumnya, mengembalikan semula seluruh projek kepada keadaan sebelumnya, membandingkan perubahan dari semasa ke semasa, melihat siapakah yang telah mengubahkan sesuatu akhirnya yang mungkin menyebabkan masalah, siapakah yang memperkenalkan sesuatu isu dan bilakah, serta banyak lagi. Menggunakan VCS juga secara amnya bermakna bahawa jika anda mengacaukan atau kehilangan fail, anda boleh dengan mudah memulihkannya. Di samping itu, anda boleh mendapat kesemua ini dengan overhed yang sangat sedikit.
Sistem Kawalan Versi Tempatan
Kaedah pilihan kawalan versi bagi orang ramai adalah menyalinkan fail ke direktori lain (mungkin suatu direktori yang dicap masa, jika mereka pandai). Pendekatan ini adalah suatu kebiasaan kerana ia adalah sangat mudah, tetapi ia juga sangat mudah terjejas oleh ralat. Ia adalah sangat mudah untuk melupakan direktori yang anda masukkan dalam dan secara tidak sengaja menuliskan kepada fail yang salah atau menyalinkan fail yang bukan anda maksudkan.
Untuk menangani isu ini, pengaturcara telah sejak lama lagi membangunkan VCS tempatan yang mempunyai pangkalan data mudah di mana boleh menyimpan semua perubahan kepada fail di bawah kawalan semakan.
Salah satu alat VCS yang lebih popular ialah sistem yang dikenali sebagai RCS, yang masih diedarkan dalam banyak komputer hari ini. RCS berfungsi dengan menyimpankan set tampalan ataupun patch (iaitu, perbezaan antara fail) dalam suatu format khas pada cakera; ia boleh membuat semula apa yang kelihatan bila-bila masa bagi mana-mana fail sahaja dengan menambahkan kesemua tampalan.
Sistem Kawalan Versi Terpusat
Isu utama seterusnya yang dihadapi oleh ramai orang adalah bahawa mereka perlu bekerjasama dengan pembangun pada sistem lain. Untuk menangani masalah ini, Sistem Kawalan Versi Terpusat ataupun Centralized Version Control Systems (CVCS) telah dibangunkan. Sistem ini, seperti CVS, Subversi ataupun Subversion, dan Perforce, mempunyai satu pelayan tunggal yang mengandungi semua versi fail, dan jumlah bilangan klien yang menyemak fail dari tempat pusat itu. Selama banyak tahun, ini telah menjadi suatu standard bagi kawalan versi.
Persediaan ini menawarkan banyak kelebihan, terutamanya apabila berbanding dengan VCS tempatan. Sebagai contohnya, setiap orang boleh mengetahui tahap tertentu bahawa apa yang telah dilakukan oleh orang lain dalam projek itu. Pentadbir mempunyai kawalan yang baik mengenai siapakah yang boleh melakukan apa sahaja, dan jauh lebih mudah untuk mentadbir suatu CVCS daripada berurusan dengan pangkalan data tempatan pada setiap klien.
Walau bagaimanapun, persediaan ini juga mempunyai beberapa kelemahan yang serius. Yang paling jelas ialah titik kegagalan tunggal yang diwakili oleh pelayan terpusat. Sekiranya pelayan itu tidak berfungsi selama sejam, maka pada waktu itu tiada sesiapa yang boleh bekerjasama sama sekali atau menyimpankan perubahan versi kepada apa sahaja yang dikerjakan oleh mereka. Sekiranya cakera keras bagi pangkalan data pusat telah menjadi rosak, dan sandaran yang betul tidak disimpanlan, anda akan kehilangan segala-galanya — seluruh sejarah projek itu kecuali apa-apa tangkapan gambar tunggal pada mesin tempatan mereka. Sistem VCS tempatan akan mempunyai masalah yang sama — pada waktu bila-bila masa anda mempunyai seluruh sejarah projek di satu tempat, anda akan kehilangan segala-galanya.
Sistem Kawalan Versi Distribusi
Di sinilah merupakan tempat di mana Sistem Kawalan Versi Distribusi ataupun Distributed Version Control Systems (DVCS) berada. Dalam sesuatu DVCS (seperti Git, Mercurial, Bazaar atau Darcs), klien tidak hanya melihat tangkapan gambar terkini bagi fail mereka; Sebaliknya, mereka mahu untuk mencerminkan sepenuhnya repositori, termasuklah sejarah penuhnya. Oleh itu, jika mana-mana pelayan telah tidak berfungsi, dan sistem-sistem ini yang telah bekerjasama melalui pelayan, mana-mana repositori klien sepanjang masa ini boleh disalin semula ke pelayan untuk memulihkannya. Setiap klon sememangnya merupakan sandaran penuh bagi semua data.
Tambahan pula, kebanyakan sistem ini berurusan baik dengan mempunyai beberapa repositori bersifat jauh yang boleh dikerjakan oleh mereka bersama, jadi anda boleh bekerjasama dengan kumpulan orang yang berbeza dengan cara yang berlainan pada masa yang sama dalam projek yang sama. Ini membolehkan anda menubuhkan beberapa jenis aliran kerja yang tidak mungkin dilakukan dalam sistem terpusat, seperti model hierarki.