Any multitude of files that you like to share and which may get changed/updated over time, could benefit by being shared on github. Code is the most common and typical case but documents could be shared this way also.
GIT is for revision control. It is supremely capable of handling all sorts of scenarios with changing sources which require traceability when these are changed/updated. It can do this for one person handling these files or a team. GIthub is a cloud based repository system for collections of files (projects) under GIT control.
If you need nothing or little of these functionalities; you are not missing out. Forcing yourself to use these tools would make life just complicated.
I’m working on various writing projects (blogs, books, guides etc), and iawriter/working copy/github desktop/github repositories is by far the most flexible and efficient setup I’ve worked with so far.
I’ve tried several dedicated writing tools (eg Ulysses, Bear and Scrivener) and while I definitely appreciate the toolboxes they provide, they also come with (to me at least) great limitations in terms of flexibility, corporation issues, vendor lock-ins etc.
Pure text files, Markdown is my favorite syntax, got me covered. And Github is an EXCELLENT hub for keeping track of everything text file-y
The power of git and other such products are its branching and merging capabilities. As an old software guy, these operations seem absolutely necessary to developing software in a team environment. @michael, do you use these features with your text workflow?
@jec0047 - yes and no. I (almost) always branch out when writing, but I try to merge when I finish the day. Old habit, I suppose. A few times I used branches when I was unsecure abut a direction a text should go. But usually the branch would only live until I’m decided.
An real world example
I’m maintaining a mailing list where I share interesting content from the tracking/ux world. I use Github Pages for that, and use the built in xml feed to trigger the newsletter automatically. I use branches to maintain each “edition” (some editions are themed, so I use the unpublished branch to collect the links until it’s ready).
When a given branch (themed/weekly/monthly) is ready, I merge it into the Master, Github updates the Page, my email newsletter provider registers the change, pick up the content from the feed and send the newsletter to all the recipients.
Super efficient, exciting to set up, easy to add new content (any device, any time, any place) and fully automated
I use GitLab now no GitHub but same basic idea. My odd use case is a shared user manual. It’s in Scrivener and so I can make all my changes in my standard Scrivener file but they get pushed to GitLab. The ability to see the history of changes is important to me for that project.
I have been using Bitbucket instead of GitHub for the classes I teach. Bitbucket has free private repos (and so does my .edu GH), so it’s for my writing and some website code (HTML, CSS, & JS).
I keep an archive of the weekly message sent to students so I don’t have to repeat everything, only update as needed. In addition, it is where I store assignments and labs that students need to complete each semester. I do need to learn more about branching and such, so when I do a course re-write, I have an archive of the old stuff.
Makes it super simple to sync across devices and more importantly keeps me fresh in the Git-verse so students can be too!
If you have a site or blog using a static site generator, typically its content will reside in a private repository on GitHub, Bitbucket, or GitLab, and the host, such as Netlify (or, for that matter, GitHub Pages or GitLab Pages) will “publish” from there, updating the site as you revise the content and push changes to the repo.