How I learned Git, forgot it, and re-learned it

Part 1: Why you need to learn Git for Docs as Code

Docs as Code. What? In the software industry, technical writers work close to developers, especially when writing developer documentation, that is, documents that have other developers as target users.

The idea of Docs as Code is to employ the same workflows for the documents as for the software code.

The chances are that the collaboration with the developers of the software would benefit from this way of working.

To do this:

• You need to produce documents in text format, that is, documents that can be read by a text editor like Notepad, Notepad++, Atom, Sublime etc.
• You would keep those documents in a repository close to the code they describe.
  • A repository is a directory on a server that can be accessed by everybody involved in the development of the software.
  • Team members have either Read & Write or just Read access to that repository.
• To be able to collaborate on the documents, you need Read & Write access and a version control system. This prevents conflicts when several people edit the same document.
• THE state-of-the-art version control system is Git. Some of the well-known platforms hosting repositories and tracking them with Git are GitHub and Bitbucket.

As a technical writer, you would thus need a basic understanding of Git.

Peter Gruenbaum created a Git course, especially for technical writers. Click here to have a look at it.

Part 2: Learning, forgetting, re-learning

I took Peter Gruenbaum’s above-mentioned course last summer when I supposed that I would need it for a Docs as Code project. I remember that I liked the course and how I ended up having a good understanding of what I—in my technical writer role—would need to do with Git.

However, the project went for documenting that API in Microsoft Word instead of sticking to the Docs as Code concept. As Word documents are in binary format instead of text format, you cannot merge different versions of them automatically with Git. So, I did not need my new Git knowledge and started forgetting it.

Right now, I might need my Git knowledge again, for another project, but I feel I cannot relate to the knowledge anymore!

Conceptually, there is no lack of understanding, but I cannot remember the right commands. I searched for Git cheat sheets, but the ones I found only confused me. They contained too much information; information I could not relate to and probably would not need anyway.

So, I decided to retake the course because I wanted to feel as confident and well-prepared as last summer, that is, after I took it for the first time.

Only that this time I would create my own cheat sheet throughout the course to prevent me from having to take the course again in the future.

If you took Peter Gruenbaum’s course too and/or happen to need a technical writer’s Git commands cheat sheet—stay tuned for the next blog post. It will contain a comprehensive command list based on the commands taught in the course.

It will be helpful for you if you are a technical writer:

• With little or no prior experience with the command line
• And eager to enter commands to the Git Bash rather than working with the Git GUI or any other tool providing a graphical user interface for Git workflows, e.g., Sourcetree.

To explore the Docs as Code concept a bit more in the meantime: click here to access the Write the Docs community’s list of resources.