• Excerpts
• blog post comments
• Hacker News comments
• Sep 26, 2013
• Oct 26, 2013

GitHub system for writers

People discussing a collaborative, version control system for writing projects and non-programmers. Some fascinating ideas and user experiences exist in these posts. Good ideas. It's an interesting area of software development that includes the Web and native apps for desktop and mobile.

I'm most interested in Web/native apps for writing, collaborating, and managing content. So that would includes software programs such as blogs, message boards, wikis, editors, content management systems, and knowledge management systems.

• Aug 29, 2013 - Github For Writers
• Hacker News discussion - 137 comments

2012 Wordpress activity

• http://ben.balter.com/2012/02/28/github-for-journalism-what-wordpress-post-forking-could-do-to-editorial-workflows/
• http://postforking.wordpress.com/2012/10/01/introducing-post-forking-for-wordpress/

http://www.wired.com/wiredenterprise/2012/02/github/all/1
https://github.com/WiredEnterprise/Lord-of-the-Files
http://www.wired.com/wiredenterprise/2012/02/github-revisited/

Excerpts

From the original blog post by Loren:
http://madebyloren.com/github-for-writers

Some barriers make it intimidating for non-developers to jump in, even if the platform can technically handle it:

• Tech jargon: non-developers don't understand branches, forks, commits, rebasing, cloning, etc.. and they don't care to learn.
• Command-line first: while GitHub is slowly moving Git functionality into the browser, the primary focus is still on the command-line. The in-browser features are meant to supplement the command-line, not replace it altogether.
• Diffs: GitHub diffs (changes in a file) are designed for code: line-by-line diffs instead of words, sentences, and paragraphs.

GitHub is built by developers for developers.

• The Limitations of GitHub for Writers
• GitHub for Teachers
• We Need a Github of Science

So, I've been working on this crazy idea - I'm calling it Penflip.

The goal is to build a platform with the primary features of GitHub (teams, issues, pull requests, discovery, project management, built on Git) but with an interface optimized for writers, along with some other useful features:

• In-browser editor
• Auto-generated project structure
• LaTeX support: math and science need it.
• One-click publishing: one click to convert to PDF/ePub/mobi/etc, complete with layout and styling.
• Mobile-friendly: because writing can happen anywhere.
• Diffs for writers

Oh, and did I mention that all of this happens in the browser, from any computer, anywhere? And because Git is running beneath the surface, the technically inclined can clone projects onto their computers and use desktop editors instead. But it's not required.

blog post comments

You should check https://draftin.com

draft doesn't seem to mention Latex anywhere? It seems to be entirely based on html. I'm not sure that html would be powerful enough for scientific writing

No it doesn't support Latex, it's only about writing and markdown. But it still solves the problem for many people.

You should check out authorea: https://www.authorea.com

Think this has huge potential for Education > see http://openplan.cc for more.

For LaTeX, check out http://www.mathjax,org

nice. probably the closest thing out there is draftin. here's a nice bog post on some of the metaphors between the git tech jargon and the functions of everyday, word users http://kivo.com/blog/git-for-the-masses

I started using Editorially ( http://editorially.com ) which as collaborating option on which you can write in Markdown.

I guess you know about Ben Balters Wordpress Plugin Post Forking? http://ben.balter.com/2012/02/28/github-for-journalism-what-wordpress-post-forking-could-do-to-editorial-workflows

I do believe a great version control should be use on not only code and writing, it should work on a lot of way. Control versions, share with others, work with other talents etc

Hacker News comments

A lot of programmers already find it awfully hard to wrap their heads around how git works. I can only imagine how hard it will be for non-programmers to (it doesn't suprise me that the successful example used is written by mathematicians).

HOWEVER, that doesn't mean it can't be done. In fact, if there are ways to visually simplify git and make it more intuitive for non-programmers, those techniques could wind up making git even better for programmers too.
I could also imagine a convergence of the git model and the wiki model someday -- where anyone can edit (like Wiki), but where there are branches, merging, etc. Obviously, a lot of internal wiki's don't need such complicated version control, but for things like Wikipedia, it could be amazing.

And the main attraction for users over, say, Google Docs, is that your changes don't overwrite others'. The fact that your edits create a "branch", that then others can accept/reject/modify/merge, is a vast improvement in creative collaboration.

Learn Git Branching did a really good job of making git easier to understand:
http://pcottle.github.io/learnGitBranching/
If you take that approach and update with precise but plain english vernacular (redundant?) and domain specific examples, then you are halfway there to making it understandable by regular people.

The most important thing to help people really get it is to promote small commits to their work. The real value of git only makes sense when you start making small commits. Having worked as an editor in a past life, having something like cherry-pick and interactive rebase would have been most dope. In a way, maybe editors are the best audience for driving adoptions among writers in general. For professional editors, version control is a painkiller. For writers, it is a painkiller if the writer is an obsessive editor. For those who write and commit once, but don't go back and review commits and refactor, it doesn't provide much value.

Loren and others may not solve all the problems right out the gate, but they will lay the groundwork for new approaches to teaching version control to writers and other audiences.

Learn Git Branching is best learning tool I ever tried! With this tool and a little practice on the side I was able to learn the basics of git within a couple of hours so that I can confidently branch, merge, push, pull and rebase and I know what I'm doing!

I want git to handle everything behind the scenes, and everything that the user touches just 'makes sense' - ie its not all that different from what they're already doing. A 'save' button makes a git commit, editing somebody else's content automatically creates a new branch, 'submitting' that content on the new branch creates a pull request .. etc.

I can also imagine writers will get a great deal of use out of git cherry pick.

You could combine the advantages of git versioning with wiki style collaboration and make a git-wiki like the parent said, but for writers.

The intersection of git and wikis is interesting, it's one of those things that sounds compelling but then the details usually end up making it hugely complicated. For general writing collaboration I would seriously consider not allowing arbitrary branches. Most people just get confused managing multiple independent outstanding branches that potentially branched from different points in the history.
One restriction could be that each user gets a single branch (their suggested change). As changes get merged into HEAD each user's branch must be rebased (with a click) before they can add more changes to it.

Honestly, I think writers could benefit more from the collaborative editing model than the git branching model. When do writers need to branch their stories/articles into two forks? Instead, it can be quite valuable to have a collaborative text editor: your colleagues' changes are shown in real time as they make them. If you go on a plane ride, they're synced when you get more internet access, with conflicts clearly shown and deliminated so you can resolve them simply.

My wife is a novelist.
The collaborative editing would be useful in the later phases of a book -- i.e., working with an editor and copyeditor, it's be great to have a really efficient way to review changes made to the actual text (instead of reviewing a hard-copy with hand-written corrections, and then hoping those corrections are accurately hand-merged into the text...).
But for most of the life of a manuscript, it's just the author working completely solo (from what I've seen). In the standard flow, there's no editor until the book (in a fairly complete and polished draft) is sold to a publisher. A literary agent may read drafts along the way, but normally wouldn't touch the text, just write up higher-level feedback.
On the other hand, the task of designing a narrative that flows well at the scope of a novel is really hard, and can take a lot of large-scale trial and error to improve. She usually does have several "branches" of her current project, as well as large chunks that she has cut from the current draft but doesn't discard (and sometimes may be re-added).
Her first published novel shed more than 300 pages that were never re-added on its way to the final version... it's hard to keep track of all that. It wasn't like "drop this chapter", generally, more like "remove this subplot from the hundred or so places it shows up".
I'm not sure how well the git model would address the problems -- the big problem is scale, and visualizing large structures made up of lots and lots of tiny little words. They are plenty of pain points worth attacking, though, except that most writers don't have much cash to spend on tools.

"And the main attraction for users over, say, Google Docs, is that your changes don't overwrite others'. The fact that your edits create a "branch", that then others can accept/reject/modify/merge, is a vast improvement in creative collaboration."
This.
Version control is a capital-P Pain In The Ass for group writing projects. Anything that improves the version control problem in collaborative writing solves a very real need. Perhaps not a huge TAM at first glance, but a real need nonetheless.

I love git, but some of the metaphors and inconsistencies it makes are definitely not good and make it much harder to pick up than it should be. I think with the right set of metaphors and ui it can work.

Writers, or anyone that's not a programmer, doesn't care what a git is or how it work technically. They want to know how it will fulfill their wants/needs, and they want big buttons labeled with those solutions.

Draft's editing/version control is rather awesome and easy to use. It would be neat if Loren and Nate could work together to get some of the github-like "social" features into Draft--following updates and broadcasting progress.

Agreed. Draft tackles versioning and editing in markdown very well. The incremental save feature makes all of this transparent to the writer.

Git branching a storyline is an awesome idea.

Is it just me, or are there a number of fairly high-profile writing tools that have launched recently? The ones I'm thinking about:
* Draft http://draftin.com
* Editorially http://editorially.com
* Quip http://quip.com
* Loren's Penflip http://www.penflip.com
* Google Docs (obviously not new)
A lot of thoughts running through my head, including that finally products are being built from the ground up both for collaboration and for mobile/tablets. (And that this appears to be an early sign of the end of Microsoft's dominance in the office productivity software world.)

Are any of these projects aiming to interface well with MS Word or OpenOffice?

Well you could use pandoc [1] for creating MS Word or other file-formats. As far as I know MS Word is still the choice to use for novelists, when it comes to giving test to editors and a like.
So pandoc could be used for transforming a text into many different formats (even ebook formats).
Might be an interessting thing to look at for the creator of "git for writers" ;-)
http://johnmacfarlane.net/pandoc

I'm currently using GitHub to collaborate on writing a book with a non-technical coauthor. Generally it works great, but there are two key issues:
* Changes are tracked by line which is equivalent to a paragraph in a book. If I go in and add a comma to a paragraph and my coauthor simultaneously changes a word in that paragraph that can create issues.
* Errors are very difficult to solve for my coauthor. When Github Window's app encounters an error, it basically says "Just open up the command line and you should be able to figure out how to solve this". Of course this isn't feasible for a non-technical audience.
If your product can fix these two issues (which it looks like it is trying to) it could be very valuable.

Disclaimer. I'm the creator of GitSense which is working on building advanced power tools for Git and GitHub.
The diffing problem is solved quite easily with the Google Diff, Match, Patch algorithm and our Smart View technology. When GitSense was created, it was obvious that we all work differently and we all have different needs which was why we made it insanely customizable. If you are not familiar with the Google Diff, Match, Patch algorithm, you can learn more about it here:
https://code.google.com/p/google-diff-match-patch/
I've also put some screen shots of what the diff results for two markdown files would look like at:
http://screenshots.gitsense.com/google-diff-patch-match.html
The context aware source code that is used in GitSense to display the diff can be found here:
http://screenshots.gitsense.com/google-diff-match-patch-integration.js

> Changes are tracked by line which is equivalent to a paragraph in a book.
When using Markdown, I usually split paragraphs over multiple lines (usually between sentences) which makes diffs much easier to read, while still rendering as a single paragraph.

I know people who break lines per phrase/clause, rather than per sentence. You wind up with lots of very short lines, but that doesn't matter after Markdown is done processing. The benefit is some very granular diffs that are easy to read, as you work out rewording things in the editing process.

Same here. "Single line paragraphs" are a pet hate of mine - they have no place in plain text files even if those files are intended to be post-processed.

I disagree with this. In a plain text file that consists of prose, line breaks are presentation, not content. Hardcoding them into the file doesn't appeal to me. It makes editing a pain in the neck. It also means the line breaks have to be removed again if you want to move between formats.

That sounds like an editor issue, though. You should be able to reflow a paragraph, indent it or whatever it as you like.
A compromise might be to break lines on sentence boundaries: edits are often constrained within sentence or paragraph boundaries, and then diff would give more meaningful output for most sentences.
^-- This one sentence is two lines long, though, so perhaps my idea is not that good. Diffs would still be easier to read than if each paragraph were one line.

I'm still undecided on this. Say you have a long paragraph and have to add one word at the beginning. You have two options - either rewrap and introduce a silly diff, or don't rewrap and exceed your chosen text width.
Single line paragraphs don't put such a difficult choice in front of you. If your diff software is any useful, it'll highlight your change within the line.

Perhaps you could have a special kind of commit, a "text-rewrap" commit (similar to merge commits), which might let your diff presentation tool alternate between diffing lines, pararaphs, or the like. I agree, the presentation layer really needs to be as granular as your editing team needs to be. I really like how Github shows the differences within a line that is different.

That's why I don't use fixed-width. I break lines up logically, usually at the end of a phrase/sentence, regardless of their length.

i write quite a bit with git, and recently brought an old collab project with a friend onto it.
i do all of the git work, and i just have my friend add my edits to his document, then he sends it back and i diff the two for potential errors... he requested it be this way because he is stuck in his ways, but we've agreed to go full git on book two in the series...
that said, when i first started sending him diff files we both saw this as a problem... my solution? i just wrote a script that i run on the diff to just highlight the changes made, then send him the new edited diff.

What I mostly want, when writing collaborative documents, isn't a git equivalent - it's a code-review equivalent.
I want to leave comments on individual words, sentences, paragraphs, etc., with suggestions for changes. And that's something that git doesn't allow, because the smallest change you can comment on is a file, with no ability to comment on specific parts of it. (reminds me of Medium.com's marginal notes for paragraphs.)

Git doesn't support it, but GitHub does. You can comment on individual lines via GitHub. I'm going to do something similar - maybe on a more granular level (words/sentences).

Latex has line comments and since it is compiled into a document you can place line breaks anywhere. It does break the flow of the sentence though.
I've used Latex+vim+git to write scientific papers recently. It is unfortunately much too complicated for my colleagues to adopt. They're holding onto MS Word which is far inferior in terms of markup, citing, and VCS.
I've been converting my Latex documents to ugly word documents for collaborating and editing. The MS Word editing isn't great either. The strikethrough method breaks up flow. I've also had problems deleting side comments in Libre office. And the MS Word experience isn't always the same on Macs.

If you're using google docs for your collaboration this sort of commenting is built in. It's a great feature. Almost better than collaborative editing.

(If it's a personal writing project, it makes more sense to accept feedback from others through comments, notes, and annotations than it does to allow others to edit the document. This means that advanced collaborative editing and git-like features are not needed. Simple wiki-like versioning or a history for the writer is all that's needed along with a commenting system for feedback. If it's a workgroup project with many possible authors, like a wiki, then advanced collaborative editing and git-like features make sense.)

his is interesting, but I think it kind of fails to take its audience into consideration.
1) It assumes writers write like programmers code. This isn't true. At least with scripts, what typically happens is the writer will write an entire script, send it to their boss for revisions, and then rewrite it. They would consider it a pain in the ass if they had to make "commits" for every page they wanted to add, and especially if their bosses had to review each change (mostly because bosses are executives who just want to leave their mark by making unnecessary changes on things).
2) In either book or script writing (or whatever) small grammatical changes are unimportant, and there will be way more of these than we would care to look at. Who cares about reverting a change of "its" to "it's"?
I see this kind of thing as being useful for writing an informal, informational book in the form of an extended blog post (see http://gettingreal.37signals.com/) but otherwise, I can't really see it being that useful for professional writers.
Also, something that I think would be REALLY useful (that I'm honestly surprised I haven't seen is a Final Draft - meets - Google Docs (screenplays editable by multiple people via online, all stored online). Dunno if anyone's seen anything like this.
Sources: My dad is a TV writer.

Exactly. I don't care about the document progression or the changes of words. I just want "versions" and "notes". I actually did a writing application for myself only and I had two windows, one on the left with the actual text, one on the right with the notes, also a sidebar with the chapters and progression of the book.

i try to get my SO to write academic essays in applications that have history or diff viewing... but never had any success. but that only means the current offerings are bad. even for programmers.
regarding your points, when i set up `meld` to show the text she sent vs what her professor or coleague sent back, she is amazed. So there is usefulness.
Second, have you ever used Kwrite in KDE? you don't have to commit or anything. just type. and it shows the diffs marks on the left. pretty hand. and avoid commits and all.
about point #2, just make branches and tags more practical. Also, try to merge back those 'word fixes' in other branches ' heads. would be awesome even for programmers.

Scientific writers do write like programmers code. There are as many as ~15 authors on a paper. The scientific paper has intensive markup, often in Latex. And collaborative writing like GoogleDocs doesn't work b/c 3 different authors will make changes to the same sentence and you need to be able to see all three changes next to each other. Not to mention figures, equations, etc...
MS Word and Libre office aren't powerful enough for scientific writing and aren't universally embraced or consistent across operating systems.
Github for writers is desperately needed. Draft doesn't do nearly enough

I think the guys at Github do want to help non-technical people learn to collaborate with git in areas like education, government, and literature.
Check out this interview where one of the Github trainers, Brent Beer, talks about these ideas. You might want to get in contact with him.
http://blog.begriffs.com/2013/08/an-interview-with-brent-beer.html

Take a look at "Why use version control systems for writing a paper" http://academia.stackexchange.com/questions/5277/ .
When it comes to diffs for text, just add "--color-words":
git diff HEAD~1 --color-words my_file.md
But I agree with other stuff, that for non-techies Git + GitHub may be to hard to start.

How are you solving the diff problem? Word based diffs tend to be jumpy and hard to follow. On the other hand line based diffs do not work well for text (prose). (unless each sentences or parts of sentences exist on their own separate lines.)

Yeah, prose.io uses word diffs and it's definitely hard to follow.
I'm doing 'fragment diffs' (doesn't really have a name) - but basically, all the text is displayed as you would read it (sentences and paragraphs), with diffs displayed inline and colored. Added content in green, removed content in red - doesn't matter if it's characters/words/sentences/paragraphs - it all works.
Screenshot is not the best, but something like this:
http://www.flickr.com/photos/madebyloren/9620674181/

Don't know if you've already thought of / planned this, but please please implement a side-by-side diff view.
Code is easy enough to read in a unified diff because lines are usually short (unless java). Prose flows a lot more fluidly, and there is no formal grammar for human language. I have had the displeasure of having to read "redlines" (prose with inline diffs marked in red strikeout) and I find them completely impenetrable.

I'm using latex+vim+git for this purpose currently. I put two spaces after a period to signal the end of a sentence in Latex. Which helps me break the document up by sentences with vim.
If you're using markup then encouraging the period-double-space could be a harmless way of easily breaking the document up by sentences.

"Sentence-based" diffs would work well for prose, but the problem is recognizing sentences, given the other uses for full stops. If you use hard line breaks at, and only at, sentence ends, you could use line-based diffs to do this (but this may run into editing convenience issues.)

I think for writing, sentence-based diffs would be the most useful.

We've been working on a similar problem. Writing in markdown, pre-processing the saved markdown to truncate to 80 column (best fit) paragraphs and then diffing on the markdown.

What about draftin.com? I use that already and I like it a lot.

Big fan of Draft (and Nate). It's got the version control part down, and I think it works well for gathering feedback on blog posts and other short form content, but it isn't designed for longer form content as far as I can tell. It's also missing the community aspect that GitHub has, which is huge, as well as features that would make writing an ebook or textbook feasible. Definitely a great tool though.

https://draftin.com/ - Agreed, great.
http://www.roughdraft.io/ - Also, I like it.
I don't think it's a bad idea to proceed with it, I would just find a way to differentiate it from what's out there.

The idea is terrific but focus is all wrong. Writers don't need branches. They don't code features in. Hell, most developers don't do stupid updates-on-branch-then-merge-merge-suffer-merge-curse-merge commit accounting.
Writers usually write alone, what they need is: A (desktop) tool with basic WYSIWYG markup (paragraphs, bold/italic, that sort of thing) with version control, visual diffs, export into common formats. Maybe a pull request or two.

Scientific writers do need branches. When there are 10 authors on one paper all suggesting different paragraphs/figures/equations at different times. (as usual, the requirements for geeks are different from "normal" users, which outnumber the geeks like scientists, programmers, and mathematicians. But many "normal" people have a need to write either personally or professionally. Writing is still a large part of many types of jobs.)

I use a similar setup with vim+latex+git for chemistry articles. It works amazing for me. I feel like it is the most powerful presentation setup and most efficient editing setup currently available.
I break sentences by ending with two spaces. (this doesn't matter since Latex is markup) The only issue arises when ideas span across multiple sentences, but I believe there is a flag for controlling the number of lines around a diff. (sorry, I'm new to git) But this sort of proves the point that an easy wrapper for git should be created for scientific writing.
The two main problems I have are: 1. adoption by collaborators (they can't surmount the learning curve) 2. diffing sentences is very different from lines of code

Is this going to be focused on those who use latex and markdown, or the the broader audience of 'people who write'?
If the latter, you run into a problem pretty quickly - MS Word. It's still one of the most popular document editing tools out there. More recent versions do store content in zipped XML, but are you willing to put the work into parsing that content at a level sufficient to let it integrate into the kind of flow you discuss?
(EDIT: That said: if your target is those creating text-based documents, then I think this is an excellent idea. )

An idea is to think about rendering/typesetting as a feature. For many, getting an environment set up to turn the project files into final files of whatever form is a huge barrier. It would be great to have a bunch of back-end rendering be just a click: Markdown->HTML, Markdown->PDF, Markdown->epub, Latex->PDF, Latex->HTML.

especially when you throw in citations for scientific articles. Which often require compilation of the citation database, citation order, and citation insertion. Adding 3 more steps to the process.
I've recently switched to papers to help with this. It seems to have a strong community and supports both MS word, libre office, and vim. Jury's still out though.
http://www.papersapp.com/papers/

I'm a little late in the party but I wanted to express my feelings anyway. I wrote a book with 2 other authors 2 years ago, and would have LOVED a tool like this. Going over Word documents in revision mode was a colorful nightmare. In general, having to work with Word was not the ideal stuff anyway.
To my point: to be totally useful along the whole typical writing process with traditional publishers (authors -> technical review -> authors -> editor review -> authors -> punctuation/misc review -> authors -> editor) you'll need at some point to export as Word documents. Ideally, collaborate in Git like environment, export as Word, receive a new Word with all those colored revision and import into Git like stuff.

hi @kmatzen/@mallyvai! Adding briefly to Nate's comment (my co-founder at Authorea), I would like to point out that we do support many popular LaTeX packages. One big reason why we do not support custom LaTeX packages is that some of them are really intended for the printed page and cannot be easily ported to the web- and the point of Authorea is to create web-native documents, which render in the browser, first, and can then be ported to print formats. In other words, we support a safe subset of LaTeX which we can easily convert back and forth into other web formats (such as Markdown). Do let us know if you have a LaTeX package in mind and we will see if we can add it for you.

Have you asked a representative sample of writers whether they write this way, and would like to use your site to write this way? Outside of business, collaborative writing seems to be pretty minimal (I say this as a novelist)...
Also, if there could be some cross-compatibility with MS Word's Track Changes (I know, I can dream...) that would be great.

My wife's job as a professional editor involved editing hundred-page documents, often with more than one author. A tool which made version control simple, yet writing easy, would be a godsend.
The down side is, many such organizations (e.g., military) have standardized on Word, which is terrible for collaborative review, editing, and version control of long documents. (Of any documents?) She would have been extremely happy had her employer allowed them to use LaTeX or similar.

One question is, do writers create their own work because of the nature of writing, or because they lacked the tools for collaboration. I have seen several examples of collaborative writing. The first example that comes to my mind is the SCP Foundation.
http://www.scp-wiki.net/

As someone who writes software and fiction (heck, even software-fiction in the form of visual novels), I actually keep finding more and more parallels between the craft.
I like to explain the fiction creation process as "writing code that targets the Human BIOS."

But Markdown as UI... is less than ideal. It's great for hackers, but there's already a GitHub for hackers, and it's called GitHub. No matter how much prose.io prettifies it, you still get those damn asterisks all over the place.
Personally, I write in TextEdit, Helvetica 12pt. That's not a universal answer, but it works for me. (Previously I used MacWrite Pro, ClarisWorks and Word 5.1 at different times, but the basic appearance was the same.) Anything that makes a bold word look like "* * this * *" breaks 20 years of habit, and I won't do it.
Markdown as backend storage, fine. But not as the primary editing interface.

> Markdown as backend storage, fine. But not as the primary editing interface.
That's interesting - hadn't thought about storing in markdown and just displaying as html. Hmmm.

At work we are trialling Lyx + Subversion for collaborative creation of developer documentation. The stored data is in a text + markup format which allows for easy diffing. Lyx being a layer over Latex means we can easily transform into a wide variety of formats, but mostly we output to PDF and HTML. Subversion was chosen as we already had a server available and there isn't really the same need to branch/merge documents compared to code. Writing in Lyx took a little time to get used but I definitely feel more in control that when trying to wrangle complex docs in Word.

I used to write my documents in Lyx too but spreading the tool amongst my colleagues involved a lot of evangelism. Markdown is a backend storage easier to adopt as developers are used to it (stackoverflow, github) but it produces output for the web : no pagination, header/footer, etc. Throw pandoc+tex template into the mix, and it starts to get really interesting : a quickly hacked markdown file transforms into nice pdf will all needed attributes. But why stop there? Now that you have a build process, move it to a server and add some hooks to injects traceability infos (author, last edit date, commit hash...) into the generated document, etc...
I went down this road, and it works surprisingly well. If you're trialling different solution for writing technical developer documentation, see a more precise description of the workflow that I pushed on my blog yesterday: http://kray.me/pro/doclegit-git-documentation-server/ (sorry for the copy quality, english not my first langage, corrections by mail are welcomed)

Interesting. When we set this up we looked at maybe adding an automated build (transform) step on commit via our CI (Jenkins) server.
While the software developers are comfortable learning and using Markdown or other markup syntaxes, I eventually would like to spread this approach to other technical people in the company. In previous attempts at teaching basic scripting (Awk, Ruby, Python) to engineers who are comfortable writing complex logic operations in Excel and who can dabble in VBA - I found a lot of resistance to the idea of learning a new syntax. So I expect the evangelism required to get these colleagues to write in Markdown will be greater than showing them Lyx, which at least looks like one of the editing modes in Word.

This sounds great.
I am also working on something similar called Papyrus. It lets authors create and edit ebooks simultaneously.
http://papyruseditor.com/en/home/collaborate/new

We edit research quality publications on Bitbucket. So Git already works for writers.

Just today, I was checking out the JS API wrappers for Github API v3 and I found Github.js. There, I discovered this site called prose.io
Check it out! It's awesome!

Wooki* is a smart tool to write documents. It let you publish them and get reviews
https://github.com/spreadthesource/wooki

I thought https://poetica.com/ was doing just this

Just re-purpose git-flow with a "writing/publishing" namespace: https://github.com/nerdfiles/Concept-of-Flat-Design#adaptation-of-git-flow
master <-> publication
develop <-> draft
feature <-> chapter
release <-> edition
hotfix <-> redact
support <-> copyright

See also https://www.scigit.com/

Can't emphasise enough how important offline editing would be for something like this. As a professional writer (whose co-written a book), you can't rely on always having internet; but you always need to be able to work on your current project.

Sep 26, 2013

Git concepts simplified:

• http://gitolite.com/gcs/index.html
• https://news.ycombinator.com/item?id=6450191

Oct 26, 2013

Show HN: A Github for writers? (penflip.com)
https://news.ycombinator.com/item?id=6617063
http://www.penflip.com

Every damn new writing tool makes the same claim: "Distraction-free."

Comment in this Hacker News thread:

Hey there, sorry about this. I'm the guy building Penflip. It's still in alpha and was not ready to be shared with a larger audience. The email notifications for discussions were helpful for the smaller alpha group that I was/am currently testing with.

#writing - #github - #collaboration - #blog_jr