Installed Statamic to complement my existing site. How should git work now?

I have a Laravel site for real estate. The big parts of it are the properties that come in through an API and my blog. The blog is now Statamic. But, since Statmic stores blog entries as files, I'm a bit confused as to how git will work.

If I create my blog articles in production, won't there be untracked files that git will complain about?

In other words, if I make a change to my website and push it to my git repository, my server is going to try and download those changes from git but I believe Statamic will have uncommitted files.

Hopefully that makes some sense. I jsut want to make sure I'm doing this right from the beginning.

LaryAI

11 months ago

Level 58

Great question! This is a common scenario when using Statamic (or any flat-file CMS) alongside a Laravel app. Here’s how you can handle Git and deployment with Statamic:

1. Where are your content files?

Statamic stores content (like blog posts) as Markdown/YAML files in the content/ directory. By default, these are tracked by Git.

2. Editing Content in Production

If you create or edit blog posts directly on your production server (via Statamic’s Control Panel), those changes are made to files on the server. These changes are not automatically pushed to your Git repository.

3. Potential Problems

If you deploy from Git, you might overwrite content created on production if it’s not in your repo.
If you make code changes locally and deploy, you might lose production-only content.

4. Best Practices

A. Treat Content as Code (Recommended)

Always commit content to Git.
When you create/edit content in production, SSH into your server, commit the changes, and push them to your remote repository.
Pull those changes to your local/dev/staging environments as needed.

Workflow Example:

Make a blog post in production.

SSH into your server:

git add content/
git commit -m "Add new blog post"
git push origin main

On your local machine, pull the latest changes:
```
git pull origin main
```

B. Edit Content Locally (If Possible)

Create/edit blog posts locally, commit, and push to Git.
Deploy as usual. This avoids untracked files on production.

C. Ignore Content in Git (Not Recommended)

You could add content/ to .gitignore, but then you lose version control for your content, which is a major benefit of Statamic.

5. Summary

If you edit content in production, commit and push those changes to Git.
Pull those changes to other environments as needed.
Do not ignore the content/ directory in Git unless you have a very specific reason.

6. Extra: Automating the Process

You can use deployment tools (like Envoyer, Forge, or GitHub Actions) to help automate deployments and even content syncing, but the core principle remains: keep your content in version control.

In short:
If you create content in production, make sure to commit and push those changes to your Git repository, so your content stays in sync across all environments and is never overwritten by deployments.

Let me know if you need more details or have questions about a specific workflow!