I wrote a book about the Git version control system, which was published in 2015. While writing that book, I also wrote short posts about the process. I also wrote about the people who helped me throughout. I published these posts every week on a now-defunct forum site run by the publisher. When I look through these 58 posts, it’s a public diary of what I experienced while writing this book. Thank you for visiting!

My name is Rick Umali.

I earned a computer science degree in 1990 from Rensselaer Polytechnic Institute (Troy, NY) and I’ve been a working computer professional ever since.

I’ve worked exclusively in the Boston area. Counting my current job, I’ve been with six companies: ICS, Open Market, Mercury Computer Systems, Endeca, Turbine/Warner Brothers Games, and FirstFuel Software.

While I consider myself a programmer, my jobs have usually been in support of software: technical support, training, consulting, and ‘web development’. At each place, I’ve written computer code, and used version control. (My first job had me using C with RCS, and my current job has me in front of Ruby and Git.)

I was born in the Philippines, but I moved to the United States with my family when I was 3 years old. We lived in Jersey City, New Jersey, until I went to college.

I’m married and my wife and I have a teen-aged daughter.

Thanks for visiting!

I’ve spoken about Git at a few local conferences these past few years. Once at the Northeast PHP (August 2012), and once at a Boston PHP meetup (October 2013). Both went relatively well, and both whet my appetite to get my thoughts in book form. Prior to those events, I’ve spoken at smaller venues (once at a company’s lunch hour).

As I churn away at this book, I’m coming to the conclusion: speaking is easier than writing. With speaking, there’s only so much time: eventually we have to leave the venue. With speaking, I can ‘hand wave’ certain details. With speaking, I can add some dazzle and sizzle with live demos.

Writing is different. The text is going to be a permanent record. The text has to have as much of the details as needed to convey my points. The text has only a limited range for dazzle and sizzle.

That said, I’m embracing the opportunity to write this book. I hope it shows!

When I first spoke with Mike Stephens (Associate Publisher at Manning) about this book, he said that as long as I could produce 7-10 pages a week, I’d meet the book’s schedule. I remember thinking “I got this. No problemo.”

Of course, now that I’m in the thick of things, I’m realizing that 7-10 pages a week is not as easy as it originally sounded. In order to write that many pages, I have to write every night. Every night.

I try to produce at least one or two pages each evening. Some nights are easier, and some nights are difficult. And some nights I just take a break! But I try to keep those breaks infrequent.

As I type this, I’m starting Chapter 7, trying to get in the quota. Thanks for reading. And your patience!

I’m wrapping up Chapter 07 this weekend!

In the evenings when the writing is difficult, I try to ignite my muse by partaking in some legitimate distractions. I spend time reading StackOverflow’s Git questions. I also spend time playing with the latest Git by building it from source. Another distraction is reading the voluminous Git discussion list.

Writing is a very effective way to learn something. On the nights when it’s difficult to write even one sentence, I try to make up for it by learning more about Git.

Thank you for reading!

Deciding on an audience is a very important step in writing any book. During the planning stages and the early writing my target audience was loosely defined. I wanted “every person who creates or manages electronic files” to read it. I included writers, artists, and (yes) programmers in this audience. Anyone who needs versioned files could stand to learn Git, I thought. In the end, this proved to be too broad.

Right now, my target audience are programmers who are beginning to learn Git. Ideally you have some programming experience, so the motivating examples won’t throw you off too much. The book is less about code and more about managing code.

My ideal target audience is also new to version control systems, but this is only an ideal. I know many of you will have some experience with other version control systems, especially if you have more experience. If you do, then try to keep an open mind about Git’s quirks.

My target audience should have some familiarity with typing commands into a command line. Everything we type will be carefully spelled out, however, since the book is written in tutorial fashion. That said, the book does make use of Git’s UIs (gitk and git gui).

Hopefully you see yourself in this description. I’m writing for you!

At a party earlier today, I was describing to someone the mechanics of royalties and advances. As if I was some expert on the subject!

I pulled out my book contract just now, to remind myself about royalties and advances. I suppose this was some form of mild procrastination, but it was helpful to me to be reminded of this simple fact: I’m obligated to write this book. I signed a legal document saying I would.

The book is almost a third of the way done. I’m not anywhere near finished but I know that my current schedule can get me there. And even though maintaining this schedule is somewhat arduous, I’m obligated to do it.

More chapters of the book are now available. If people have comments I’m happy to receive them either through this forum or via e-mail. Drop me a line and Thank You for reading!

People say that you learn more by teaching someone how to do something. I think you learn even more by writing a book. I know that I have learned a lot more about Git in the last four months of writing than in using it professionally in small teams or for myself over the past three years.

I know a lot of this comes from looking closely at every command and example, and asking “what is really happening?” I find myself doing some interesting exploring, much of which you can see in the exercises and the “further exploration” sections.

Learning more about Git is what I was looking forward to when I decided to do this project. If there are beginner’s topics that readers would like to see covered, please drop me a line here or send me an e-mail. Thank You for your support!

One of my reasons for taking on this book project is that I’ve always enjoyed writing.

When I was a kid, I thought I wanted to be a journalist. Throughout high school and college, as a way to write “for real”, I was a writer for school publications.

At a personal level, I’ve always kept a journal, first on paper, then later electronically. I like writing to the “future me”, and I write to myself everyday. I think everyone should keep a journal or a diary. It keeps you sane!

In the late 1990s, when “web logs” (later BLOGs) became a big deal, I leapt at the offering from Blogger, and I’ve been writing there for a long time. After some dormant stretches, for the past few years I’ve tried to write at least one blog post a month.

When the Sporting News offered personal blogging space, I joined that. They shuttered those BLOGs though, which forced me to move to ESPN’s BLOGs. This year they discontinued those BLOGs, which forced me to yet another provider. I’ve yet to start that up, so all my thoughts about the World Cup ended up on BigSoccer forum posts.

I’m happiest for my technical BLOG, though I don’t update as often as I’d like. I started that BLOG as an excuse to learn Drupal (and PHP), and I still enjoy working on the back-end bits. Mixing computers and writing made me ripe to take on this book.

Thank You for reading. One note: there will be no Book Blog post next week, as I will be away. I will respond to any forum postings, so please post away!

I’m writing this book using Microsoft Word. This may seem blasphemous. I can hear the nay-sayers now: “What?! Microsoft!? UNIX is the way to go! Write that manuscript in Emacs! Or vi!”

The biggest reason for writing in MS Word is that the editor I first worked with said it would be more efficient for us to trade comments back and forth using Word. I did not want any friction between myself and the editors so I agreed. Word has a “review and comment” capability that enables an editor and a writer (and others) to have a conversation in the margins.

I also liked that Word (and the Manning-supplied templates) gave me immediate feedback for how the book might look. WYSIWYG indeed. This helped a lot because I have a good number of figures and listings. The accurate layout also gave me a better sense for the page count.

Manning does have an XML format, and I was very close to buying into it (using a separate tool to convert AsciiDoc to Manning’s XML format, and then generating a PDF from it), but that sounded like a lot of work. Once the first editor suggested Word, I didn’t look back.

Thanks for reading, everyone!