Writers Stack Exchange is a question and answer site for authors, editors, reviewers, professional writers, and aspiring writers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm a writer, not a programmer. I'm just now for the first time learning about version control and how it works, and I am wondering how version control could streamline my workflow.

In a previous question, I asked what version control system to use, and settled on Git.

For years, I've used my own cobbled-together version of version control. My folders are littered with files like resume-2012-06-01.doc, resume-2012-06-15.doc, letter.txt, letter-old.txt, letter-v2.txt, story-notes.txt, story-notes-with-character-sketches.txt story_draft1.txt, story_draft2.txt, story_draft2-shorter.txt, etc.

Now that I'm using version control, I guess I don't need to manually create all these renamed versions of a file. What should I do instead? Now that I'm using version control, how should I name my drafts and rewrites? How should I keep track of drafts and revisions?

What philosophy and practices should a writer use for commenting when doing a Git commit of rewrites and revisions to keep track of everything and find things easily later?

share|improve this question
up vote 12 down vote accepted

There are two concepts in git that can help: branches and tags.

Tags. Think of a tag as a name for a specific revision. Any time you want to remember a version, create a tag for it. For example, when you finish a draft, you can tag it like this:

git tag first_draft

When to use tags. Tags are good for marking any version that you might want to remember later. I use them to mark the end of each draft.

Branches. Think of a branch as a series of changes. The default branch is called master. That's a good branch to use for your initial research and first draft. Unless you create a new branch, every change you make updates the master branch.

When to use branches. Whenever you want to start on a new series of edits, you have a choice. You can either continue on the the current branch, or create a new branch.

Some possible uses for branches:

  • Drafts. You might start each draft by creating a branch for it. (I tend not to do this, but it may suit your needs.)

  • Experiments. Suppose you want to experiment with rewriting a few scenes to change from first person to third, or to change the POV character. You can create a branch and do your experiments there. Later, if you like the new POV, you can continue writing on your experimental branch. If you don't like the POV changes after all, you can switch back to whatever branch you were on before.

  • Submissions. Before I make a submission, I'll often create a new branch, add my cover letter, make any minor manuscript changes specific to that recipient (e.g. quirks of mss formats), and add a text file with notes about the submission. When I receive a reply, I can check out the branch and update my notes.

I tend to use branches more for experiments and submissions than for drafts. When I finish a draft, I'll tag it, then continue with the second draft on the master branch.

Creating branches. To create a new branch, use the git branch command like this:

git branch charles_pov

When you create a new branch, the new branch starts with the same content as the branch you were on. If you're on the master branch and you create a charles_pov branch, the charles_pov branch starts with the current content of the master branch.

Note that creating a new branch doesn't switch to the new branch. To switch to a branch, see below.

Switching branches.

You can change branches at any time by "checking out" a branch. To switch to your new charles_pov branch:

git checkout charles_pov

When you commit changes, git updates whatever branch you are on, and leaves the other branches unchanged. So if you switch to the charles_pov branch, your changes will update the charles_pov branch, and the master branch will remain unchanged.

Creating a branch and switching to it in one command. You can create a new branch and switch to it in a single command, like this:

git checkout -b charles_pov

Viewing tags and branches. You can see a list of all tags and branches with these commands:

git tag
git branch

Checking out a tag (AND A WARNING). Remember that a tag is a name for a specific version. If you've tagged each draft, you can check out an old draft like this:

git checkout twelfth_draft

Yep, you check out a tag the same way you check out a branch.

BUT NOTE that when you check out a tag, you are no longer on any branch. Any changes you make end up in a floaty nebulous place that I don't know how to explain succinctly. Git does warn you about this.

The current branch. To see what branch you are currently on, use this command:

git branch

Git displays all of the branches, and marks the current branch (the one that will be updated when you make changes) with an asterisk.

share|improve this answer
One thing I would add: use meaningful checkin comments. (I assume git has checkin comments.) Later when you're browsing the revision history looking for, say, where you introduced a new major character, these comments will save you lots of time. There is no virtue in terse checkin comments. – Monica Cellio Feb 17 '13 at 3:04
git has checkin comments. The first line of the comment is treated as a title or summary. Some parts of git display only the title, and only the first 50 characters of the title. So it's best if the most important information appears in the first 50 characters. But after the title line you can write a detailed description of any length. – Dale Hartley Emery Feb 17 '13 at 22:19

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.