What is the workflow when updating a live site?

Let’s say a website is live. And the customer edits content via the panel.
Later he wants you add a new feature.
When working with Git I realized that every time I push my local changes to the remote repository, everything on the remote repo is overwritten. Means that changes that my customer made via panel are lost. I was thinking about merging Branches, but while changes via the panel are not tracked by Git, this I guess, would not work.

So what workflow do you recommend to add new features to a live website while a customer edits content via panel at the same time?

1 Like

There are some ideas collected here: Deploying via Git - #22 by dinko

1 Like

Thanks for the hint.

I would deploy new features on a subdomain like preview.domainname.com to preview them by the customer. And after the customer releases the new feature I would deploy it on the live server .

It’s a bit hard for me to think the whole chain to the end.

When I just add /content to .gitignore for the live server, then I could deploy the new features without overwriting content that the customer changed in /content on the live server during developing the new feature.
I also could add new fields to existing content items without “destroying” content-changes the customer made meanwhile, right?

New fields are added in the blueprints, not in the content, so the content files are not directly affected.

But keep in mind that when you rename fields in your blueprints (or change certain field types), you would have to update the content files (programmatically or manually with search&replace).

1 Like

I’m still using my rsync workflow as @texnixe already pointed out, for me it works great in exactly this kind of situation. There’s many ways to achieve it, depends what you’re comfortable with.

In general, when developing a new site, you have a preview site and people already start entering content on it as it will eventually go live. As this is happening, I sync the content to me locally so I have actual content to work with.

Later on, when the site is live, the preview domain is just for testing and the source of truth for content is the live site, always syncing content from that one (to local / to preview domain if possible).

I do the same. I don’t use git at all for kirby sites, it is just not worth the effort in my opinion. I just use rsync to push everything to my server. If you would like to use git with kirby, the only way I could think of, is to git ignore the /content folder.