Hello all, resident Git fanatic here. I'm already familiar with Git and Github: I've used it on a large professional project, taught people to use it for their smaller professional projects, and I keep all my projects on Github. My public profile is gabikeane if you want to poke around my repos or snatch my code.
I'm a writing and literature major, so I've long known my own process for revision. To be honest, my revision process was somewhat lackadaisical. I was drilled with grammar and spelling rules from a young age, so revision became optional once I got to college. My high school's English program was rigorous and stringent, so college writing became a one-and-done deal for me. While this didn't reflect in my grades, I didn't like my writing any more. Then I started coding.
This summer, I talked to a few English professors about digital humanities pedagogy-- and all of them said they felt coding made their undergraduates better writers. It forces you to think differently about constructing logical arguments, but mostly it forces you to consider revision.
Here's where command line git comes in. Using the Git GUI (graphical user interface, usually pronounced "gooey") removes some of the ritual of revision from the user. Imagine, if you will, that you're responsible for the care and keeping of a clock. But you can't see any of the gears, so you can't know how it works. That's what using the GUI is like. This is fine for a while: you dust the clock, wind the clock, make sure no one steals it or knocks it over. But one day something happens where the clock stops working. No one gave you a screwdriver to take off the clock face. You can't open the back of the clock. What do you do?
Honestly, you should just google it. However, you can avoid the whole situation by preparing yourself to be a good clock caretaker by buying a screwdriver in the first place and checking up on your clock's insides every time you wind it.
Excuse the extended metaphor, and I'll cut right to it. If you develop a project online, you need a version control tool. According to the lo-fi manifesto (and common sense), you should know how to fix this tool when you break it. The best way to learn that is to know how the tool works. At some point in your Git career, you'll run into a merge conflict. You'll forget to pull before editing, you'll edit at the same time as someone else, you'll get a scary error message. You'll panic; God knows I did. And then you'll learn command line and nothing will scare you ever again (except maybe birds).
In that process of learning how to pull, add, commit, push, stash, pop, checkout, etc., you'll become a better reviser. When you have a strong understanding of the changes you make to your text (natural language, code, or both), you have a better grasp of how to improve them, both as an individual and within your production community.
If you'd like to learn command line Git, you can teach yourself. When you download the Git software, you get something called Git Bash too (Mac users, you can probably just use Terminal). I use Git Bash for almost all of my command line needs (that's a different post for a different audience) because it's similar to a Linux environment, therefore very different from cmd.exe (the default command line for Windows machines). Here's a quick tutorial for Unix shell (you only really need the first three lessons to start) and one for Git shell.
To respond a bit more directly to the text, I'll add my favorite quote:
The tenuous distinction between natural and computer languages dissolves, revealing itself as a construct that thrives on and maintains fear and ignorance of many core affordances and constraints of the digital medium.
When you understand your computer better, even if that just means learning to read your error messages, you become less afraid of it. And why should you be afraid of your computer? Make it your best writing friend instead.
