Appendix B. Translating This Guide. I recommend the following steps for translating this guide, so my scripts can quickly produce HTML and PDF versions, and all translations can live in the same repository.
Clone the source, then create a directory corresponding to the target language’s IETF tag: see the W3C article on internationalization. For example, English is "en" and Japanese is "ja". In the new directory, and translate the txt files from the "en" subdirectory. For instance, to translate the guide into Klingon, you might type: $ git clone $ cd gitmagic $ mkdir tlh # "tlh" is the IETF language code for Klingon. $ cd tlh $ cp .. and so on for each text file.
Edit the Makefile and add the language code to the TRANSLATIONS variable. . $ make tlh $ firefox book-tlh/index.html Commit your changes often, then let me know when they’re ready. Appendix A. Git Shortcomings. Appendix A.
Git Shortcomings There are some Git issues I’ve swept under the carpet. Some can be handled easily with scripts and hooks, some require reorganizing or redefining the project, and for the few remaining annoyances, one will just have to wait. Or better yet, pitch in and help! As time passes, cryptographers discover more and more SHA1 weaknesses. Chapter 8. Secrets Revealed. Chapter 8.
Secrets Revealed We take a peek under the hood and explain how Git performs its miracles. I will skimp over details. For in-depth descriptions refer to the user manual. Chapter 7. Git Grandmastery. Chapter 7.
Git Grandmastery By now, you should be able to navigate the git help pages and understand almost everything. However, pinpointing the exact command required to solve a given problem can be tedious. Perhaps I can save you some time: below are some recipes I have needed in the past. For my projects, Git tracks exactly the files I’d like to archive and release to users. Chapter 6. Multiplayer Git. Chapter 6.
Multiplayer Git Initially I used Git on a private project where I was the sole developer. Amongst the commands related to Git’s distributed nature, I needed only pull and clone so could I keep the same project in different places. Later I wanted to publish my code with Git, and include changes from contributors. I had to learn how to manage projects with multiple developers from all over the world. Chapter 5. Lessons of History. Chapter 5.
Lessons of History A consequence of Git’s distributed nature is that history can be edited easily. But if you tamper with the past, take care: only rewrite that part of history which you alone possess. Chapter 4. Branch Wizardry. Chapter 4.
Branch Wizardry Instant branching and merging are the most lethal of Git’s killer features. Problem: External factors inevitably necessitate context switching. Chapter 3. Cloning Around. Chapter 3.
Cloning Around In older version control systems, checkout is the standard operation to get files. You retrieve a bunch of files in a particular saved state. In Git and other distributed version control systems, cloning is the standard operation. To get files, you create a clone of the entire repository. I can tolerate making tarballs or using rsync for backups and basic syncing. Initialize a Git repository and commit your files on one machine. . $ git clone other.computer:/path/to/files to create a second copy of the files and Git repository.
. $ git commit -a $ git pull other.computer:/path/to/files HEAD will pull in the state of the files on the other computer into the one you’re working on. Chapter 2. Basic Tricks. Rather than diving into a sea of Git commands, use these elementary examples to get your feet wet.
Despite their simplicity, each of them are useful. Indeed, in my first months with Git I never ventured beyond the material in this chapter. About to attempt something drastic? Before you do, take a snapshot of all files in the current directory with: $ git init $ git add . $ git commit -m "My first backup" Now if your new edits go awry, restore the pristine version: $ git reset --hard To save the state again: $ git commit -a -m "Another backup" The above only keeps track of the files that were present when you first ran git add. Chapter 1. Introduction. I’ll use an analogy to introduce version control.
See the Wikipedia entry on revision control for a saner explanation. I’ve played computer games almost all my life. In contrast, I only started using version control systems as an adult. I suspect I’m not alone, and comparing the two may make these concepts easier to explain and understand. Think of editing your code, or document, as playing a game. But this will overwrite the old version. When editing, you can Save As… a different file, or copy the file somewhere first before saving if you want to savour old versions. Let’s make the problem slightly tougher. With some computer games, a saved game really does consist of a directory full of files. Version control systems are no different.
Now imagine a very difficult computer game. How would you set up a system so they can get at each other’s saves easily? In the old days, every project used centralized version control. What if a player wanted to get an older saved game for some reason? Preface. Git is a version control Swiss army knife. A reliable versatile multipurpose revision control tool whose extraordinary flexibility makes it tricky to learn, let alone master. As Arthur C. Clarke observed, any sufficiently advanced technology is indistinguishable from magic. This is a great way to approach Git: newbies can ignore its inner workings and view Git as a gizmo that can amaze friends and infuriate enemies with its wondrous abilities.
Rather than go into details, we provide rough instructions for particular effects.