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. Hopefully Git will migrate to a better hash function before further research destroys SHA1. Git on Microsoft Windows can be cumbersome: If your project is very large and contains many unrelated files that are constantly being changed, Git may be disadvantaged more than other systems because single files are not tracked. A solution is to break up your project into pieces, each consisting of related files. 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. How can Git be so unobtrusive? Aside from occasional commits and merges, you can work as if you were unaware that version control exists. 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. . $ git archive --format=tar --prefix=proj-1.2.3/ HEAD Telling Git when you’ve added, deleted and renamed files is troublesome for certain projects. 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. Every commit has an author name and email, which is shown by git log. 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. Just as nations forever argue over who committed what atrocity, if someone else has a clone whose version of history differs to yours, you will have trouble reconciling when your trees interact. Some developers strongly feel history should be immutable, warts and all. Did you just commit, but wish you had typed a different message? 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. 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: 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.