As a developer you know how awesome Git is. So should we consider using it for our business documents too?
At NU Creative we work with large multi-national companies who require that our internal processes will stand up to security audits. There is an expectation that our work and business documentation is stored centrally, is failure-resistant and that we could quickly recover from our premises being destroyed. We have a server that is backed up offsite and this works well. So you could say ‘if it isn’t broken why fix it?’
Git version control
At NU Creative we love using Git. We’re used to being able to rapidly restore a previous version of a set of files from any point in time. We take for granted being able to quickly see how changes evolved, and who was responsible. So why wouldn’t we want this for our business documents too?
Let’s take a business continuity plan as an example. It contains procedures to follow in the event of a disaster at the company’s premises, staff contact details and their roles and responsibilities in recovering operational capabilities.
The business continuity plan needs to be highly available – Every member of staff needs to be able to access a copy from home if the premises was unusable. This is simple with Git as staff can simply log onto a web-based Git repository (GitHub or Bitbucket), and be confident that they are viewing the latest copy of the document.
Collaboration > Top down. Different thoughts and opinions will help to develop a robust business continuity plan. Git encourages collaboration.
Business continuity plan 1.0 might be great, but Git is still there, waiting for the document to be evolved and improved. A Git mentality could help documents from being considered final and set in stone.
The speed of collaboration should also be considered. Let’s say a staff member notices a typo in their telephone number. If the business continuity plan was a PDF with company branding, the correction might need to be forwarded to someone with InDesign or the tool the PDF was created in. It might then need to be redistributed amongst all staff members so that they have a copy accessible from home. Compare this with the speed of Git; the staff member makes the correction themselves, the administrator approves their pull request and applies the change as a hotfix to the master branch.
Git also handles concurrent editors so you won’t be receiving warnings such as ‘this file is being used by another user’.
Substance over style
In our code we are used to separating style from content. If the master copy of the business continuity plan was a plain text Markdown document, the content would shine through. If a document needed be designed as part of a package for a supplier list pitch, the latest release could easily be styled by a designer. This designed copy is a derivation from a specific release. The easy to edit Markdown file is always considered the source document, and will be referred to when an up to date copy is needed.
Separating style from content makes the structure of the document clear. A forth level heading might be a certain size or colour to distinguish it from a third or a fifth level heading. Is it clear from looking at 11pt italic pale mauve text that it is a forth level heading? Maybe, but a Markdown H4 tag is unambiguously an H4 tag. There is no concern that inconsistently applied Word heading levels may affect the meaning of the document.
Handling non-text docs
Git is designed for plain text formats, and its speed and power is substantially reduced with other file types. It stores a complete copy of each version of non-text files, so the repo size quickly increases. You also loose powerful features like highlighting changes and being able to merge changes from concurrent authors.
For creating most written business documents for use with Git, choosing the Markdown file format is a no-brainer. But what about the existing documentation in MS Word format? Ben Balter, who has been helping the US government switch to Git, has created a Word to Markdown convertor.
This is great for development agencies where everyone knows Git, but what about businesses where non every team member is a developer? Should they use Git for company documents? As a full service agency, NU Creative has lots of non-developers so this is something we need to consider.
Loren Burton, a developer from LA, considered the issue of non-developers and created Penflip. It is an interesting project designed to give the power of Git to writers. As far as I know it doesn’t have the facility for automated backups, so would not pass a security audit.
There is no need for everyone in your company to know command line Git to get the benefits. GitHub and Bitbucket provide many Git features through their web interfaces, including creating and editing files. Users who need to be able to edit locally can use visual Git clients like GitHub Desktop or SourceTree that are much less intimidating than the command line prompt. There is undoubtedly a learning curve, but the benefits are good.
Take home message
In addition to version control, Git can offer benefits for collaboration, high availability and promoting substance over style. Whether you should move to Git versioning for your business documents will depend on the situation in your company. How good your current document system is, the number of non-developers and their willingness to adopt new technology should be factors in your decision.