Git for Content

From DevSummit
Jump to navigation Jump to search

Git for Content with Amanda Hickman from BuzzFeed Labs @amandabee

  • She has collaborated on lesson plans & curricula.
  • Snapshot from group:RE workflows

Uses lesson plans, narratives, documentation (+1), collaboratively written proposal, manifesto, replacement for google docs collaborative writing, static websites, collaboration on legal documents & blog posts, develop materials with committees, technical documentation collaboration, writing for website, informational materials & getting feedback/peer review


  • curious about git as store for collaboratively maintained metadata,
  • curious about git as a barrier for non-techies (+2)

Output Workflows

  • storing plain text - using in blogs or pdfs, ways of using info stored in a repo
  • connecting relationships of content


Git is an open protocol, a way to manage version control for a set of files

  • — provides shared hosting for git repositories (as a hub)
    • git is good at storing text
    • can sync projects independently with others so long as you have access to the internet
    • github, gitorious, bitbucket as places to do account management
a single project on your own computer
A well documented, simple language for
  • not a lot of layout, or margins
  • But can do things like bold, images and anchor things
  • lets you encode in text what is italicized, similar to how HTML or Latex, Textile allow you to describe formatted text in plain text.

Microsoft Word is good for storing rich text & formatting

Further notes and Resources

Command line vs. Graphical User Interfaces (GUI)

Folder, run a command, to turn a normal folder into a git enabled folder (because it will contain a hidden folder that git the program that is installed on your computer looks for)

Git the program will allow you to store changes to your files, keep track of them

Amanda shows example, which is a course plan she has.

  • points out what the change was when she edited a file.

"Commit messages" allow you to leave a message about your change, which allows you to leave a message that you can find later to understand why you made a change.

Some commit messages just might be 'edit'... but you might make changes based on the reason for a change - helps create a record

  • github will let you see what the markdown files in the repository actually look like, as you can see here: Data Skills
    • This uses the github pages (gh-pages) features.
    • will only publish the gh-pages branch in your repository, and this can be public.

git also allows tracking of software versions or "releases" (using branches and tags) that let you know a certain version. But you can also "fork" your files into a new branch.. so for examples a version that you publish, or a version that was for a class in a certain semester.

Fork and Branch

Question: what is the different between "fork" and a branch?

Is when you make a new project that is a totally separate repository. "forking" means copying off an existing project.. and splitting off from someone elses project. On github, you usually fork someone else's repository. Like making a snapshot that you now own or control.
Is within the same repository, which you might (or might not) branch. A branch is more a small copy.

Example:if you wanted to fork the data skills class, make it your own, delete what's not useful. Then you might branch your own copy to archive it for a new series of classes.


ReText is a simple but powerful editor for Markdown and reStructuredText markup languages. ReText is written in Python language and works on Linux and other POSIX-compatible platforms.

  • On github -- and most centralized service, there is a pencil tool, edit icon if they have permissions, to edit the file.
  • observation: Github desktop -- hard to edit documents -- website easier to use to edit documents. "their desktop client is weird."


A thing that gets added. It is some sort of workflow tool.

means going to repository and getting all the changes.
example: 2 people worked on same chapter, and merging back into the main branch (usually "master")
Resolving Conflicts"
if you try to merge files, but they happen in the same place, gives you an opportunity to review those changes and decide which changes to keep.


Issue with git: all one line (ex. paragraph) - git handles changes as line if line changed yes or no & requiring human intervention

  • Git good if you need to document and track the changes and who apporved changes etc
  • Real time changes -- google docs is still good
  • if collaboration is just leaving comments - github is good
  • if line and comments happen, the line can be accepted then it's documented on github

Markdown is hard

  • 2 good markdown editors
    • Mou & Prose