Version control for content

[nigelhv]

Forgive newbie question. Statamic keeps content in files which are subject to version control. So submit to GitHub or whatever, and your content is safeguarded. Then the version stored on Github is pushed to production. As it's a CMS, users create content, that then resides on the server, not on GitHub, at which point versions diverge. What am I missing?

[jackmcdade]

You're missing the Git Integration where those changes are auto-committed and pushed back to github :)

[edalzell]

are there any errors when you try to commit/push from your server's command line?

Are you using a queue?

[joshuablum]

@tomagig Have a look at the ssh / git documentation from Forge (here) and make sure the keys are properly set up on GitHub.

[nigelhv]

@tomagig If I do a manual git push from my production server, I get "ERROR: The key you are authenticating with has been marked as read only. fatal: Could not read from remote repository." Clearly I have to fix ssh keys as mentioned above.

[nigelhv]

Seems to me that Statamic version control is different from "normal" Laravel sites. Maybe a short video on how to configure and troubleshoot it could be helpful?

[edalzell]

why is it different?

[nigelhv]

Really not sure where to go with this. One month on, and I'm none the wiser. Can someone please explain to me why keeping user data in version control is a good thing? And if it is a good thing, can someone please explain how it works - do I end up with user data on GitHub? My development machine? @edalzell - I'm sure this seems obvious to you, hence your terse response to my floundering, but I bet I'm not the only one who's struggling.

[bradfloodx]

Keeping user data in version control can be a good thing if it's a good thing for how you are using Statamic. For me it's perfect, I love having all the content and user data in Git. It works great. For others it might not be suitable.

How it works is that all data is stored as static files, so it gets committed to Git. That's how Statamic works - No database :)

[nigelhv]

Thanks @bradleyflood . I'm clear about flat file, no database, etc., and you clearly love it, but I just don't understand (a) why? and (b) how? Does it not lead to git conflicts? What's your version control workflow?

[bradfloodx]

Why: if your workflow can benefit from it then that's why.

How: depends on your workflow.

Sounds like you need to try it out and see for yourself.

Make it work for you and your unique situation. The tools and options are customisable for your needs.

[bradfloodx]

We use a Digital Ocean droplet for our production instance. However we causally use the SSG static generator to publish our static site regularly to Firebase CDN.

[nigelhv]

Thanks for responding Brad, I don't use a static generator as my site(s) don't need any extra performance, and anyway I'm not sure that would make much difference to my problem with version controlling everything, why do it and how. Still hoping someone can explain. (BTW yes, I've read the doc page, thanks @jackmcdade )

[jasonvarga]

If you are having trouble keeping your content in sync between GitHub and production, it sounds like you haven't set up the Git integration that Jack originally mentioned.

That would let Git on your server commit and push any changes back to GitHub.

If you work locally, then you'd need to remember to do a git pull from GitHub to get the latest data from production.

(By the way you can respond to this answer inline to keep a thread going instead of creating a completely new answer.)

[nigelhv]

My bad, I keep choosing the wrong box :-(. Thanks for your reply, Jason.
You're right that I haven't yet carried out the Git integration - I have hit a couple of bugs but have held back trying to resolve them while I do my best to understand why I would want to commit user data to version control anyway. I'm sure this must be common - we create dummy data with factories etc, but keep real user data separate in a database in production, and back it up separately from the code.

My use case is school websites. Schools need to update their sites very regularly, and I need to be able to maintain the code, introduce new features, etc. So to keep step I would have to pull from GitHub pretty frequently. Is that what people do? Is the advantage then that they can take a more fine-grain approach to restoring backups? I envisage conflicts - do the advantages outweigh this hassle? Or what?

I suppose I could just ignore the whole issue, just keep production backed up to fileservers somewhere, as normal.

[jasonvarga]

People generally like putting data in Git as it makes it easy to roll back and see when things have changed. Of course you'd have to work out what makes the most sense for your project. Excluding the content from Git is an option.

But yes, it's pretty common to pull from GitHub frequently. Once your site is live, you'd generally only be pulling down content changes, and pushing up non-content changes like templates, configuration, etc.

[nigelhv]

Ah now that sounds like the kind of information I'm looking for, thanks. It's just that the "no database" and "flat file" message is so prominent with Statamic that I've been expecting to see "a whole pile of reasons" jumping out at me. Anyway, I think this helps, thanks again.