By “maintaining” I mean any tasks involved in order to enhance/fix/update my Grav site.
Perfectly I would like to have every single file under version control system, let it be GIT. But the challenge is when non-technical person is involved and access the site (through the dashboard) to publish new articles/do copy updates.
I could gitignore directory with posts and just keep backing them up every day or so. That would work. Unless there is a way to git add . && git commit -am "New post!" everytime someone publish new post.
I could imagine a Git workflow where any change is stored, but in my opinion it would run contrary to a well-organized VCS (version control system) because tracking errors could quickly become a major hassle unless everything is structured into branches and releases that only administrators control.
In this regard, the writing of pages would operate under a different VCS as granular changes in content should not clutter a development repo. There is such a system planned for Grav, for keeping track of simple revisions.
For a current site I follow this workflow: Development is separate from content, and content is reviewed by an editorial team (its a small organization) before its sent to testing.
Version control of content happens on Google Drive for simplicity for end-users. Before publishing formatting is tested locally, and then staged for preview in a live environment (passworded). Thus development is tightly tracked with Git, and content more loosely with Drive, keeping non-tech users away from the Git repo.
We are transitioning about a dozen sites from WordPress to Grav. In the next few weeks we will be transitioning content updates over to the marketing department. Having all content in git will allow us to have snapshots of any moment in history. What did the site look like on March 2nd, 2016? Just git checkout {commit#} and there it is.
I’m looking for a writer friendly git client.
I like the idea of using Google Drive or Dropbox, I think Dropbox has a server version so edits to Dropbox files would go live immediately. I don’t really want to do that but it is another option. If they had “Dev” and “Live” folders, they could copy QA’d files to “Live” when they are ready.
I have also considered tying into the save button in the admin panel to create commits, but agree that it will create long and ugly commit histories thanks to endless arguments over Oxford commas.
I definitely dream of a git + Dropbox combo, too. But atm my site does not make much progress, so I can’t tell you more. Other than hooking into the Admin page save process, I think about a general sync stradegy: changes trigger a commit into a git “pages” branch. Themes and other stuff may be in a git “dev” branch. Then it is up to you to merge or revert them. Of course, the state of the git repo should be in sync with the Dropbox and live server; something I plan to evaluate and integrate it.
Well, as the work relies on an editorial process before testing and publishing, writers upload their files to Google Drive - which many editors allow directly syncing with (for example StackEdit). Further, editors can check the content and formatting before devs test the content and subsequently publish it. A benefit of Drive is that it also has version control on it’s documents (strictly speaking I guess it is Google Docs which holds this functionality) which is far more user-friendly than Git.
Of course, as Drive can be automatically synced locally the files could be symlinked directly to a local testing environment, but I find that counterproductive as I’d rather give the content and formatting a once over and then copy it into this environment. I regenerate responsive images regardless, and don’t need the overhead of Drive locally.