With Working Copy, we can use the text editors we each prefer and, as long as we overwrite the original copies of our drafts and keep track of commits, the app will take care of merging everything and displaying differences between versions. This system has never failed us in over two years, and it has saved us dozens of hours we would have otherwise spent exchanging revised versions of our drafts and finding changes in them. 1Īs I mentioned two years ago, this system takes a while to get used to: GitHub has a bit of overhead in terms of understanding the correct terminology for different aspects of its file management workflow, but Working Copy makes it easier by abstracting much of the complexity involved with committing files, pushing them, and comparing them. Each MacStories team member has a private GitHub repository where we store Markdown files of our articles in the same repository, other writers can make edits to drafts and commit them to GitHub this way, the author can then pull back the edited file and use Working Copy’s built-in diff tool to see what’s changed from the last version of the file and read comments left by whoever edited the draft. As I explained in a story from late 2016, even though Working Copy is a Git client primarily designed for programmers, it is possible to leverage the app’s capabilities to perform version control for plain text too. For the past couple of years, I (and the rest of the MacStories team) have used Working Copy to store and collaborate on Markdown drafts for our articles.

Ia writer free