Best practice to set up git repo with git sync plugin

Hey guys,

I’m having a hard time figuring out how to setup our GRAV websites with the git-sync plugin.
We are using Gitlab to manage our website projects.

We used to sync the fully Grav website with Gitlab, but it seems that is not possible that way to get the git-sync plugin to work properly because it will push pages to the root folder (and not to user/pages)

So I tried other possibilities, like only syncing the user folder with Gitlab. This works almost like intended, but I get merge conflicts with the plugins folder if git-sync wants to push to our Gitlab server.

Other idea we had was storing everything in Gitlab besides the pages folder and mange this folder in a separate repository, this would work out best I think (not tried this yet), but you have to create two repositories every time for one project…

So I was wondering, if you guys work with git repositories and also use the gitlab-sync plugin, what’s your way of handling the repos? I‘m open for new ideas.

Appreciate any help! :slight_smile:

I didn’t manage to make it work with GitHub either :confused:

Hi @seb3000 , Git Sync was really designed only to sync folders in the User folder as most often it is really only the Pages folder you want accessible to others or do version control on etc. However, as you may know you can also add other common User folders like Themes etc.

My most common setup is a production server with Grav, with a local setup being the same, and then Git Sync to sync the Pages folder plus the folder with my custom inherited theme. I then make local symlinks from a clone of this repository to my local Grav install. With this setup I can test everything locally, including previewing content, before using GitHub Desktop to push content updates to production.

Not sure if this is the type of info you are looking for… please let me know.:slightly_smiling_face:
Paul
ps - the current release GitSync still needs a branch called master, so you need to make that branch your default branch rather than main - more info at grav-plugin-git-sync/README.md at develop · trilbymedia/grav-plugin-git-sync · GitHub
fyi - you might find this blog post of mine of interest Git Ready for Git Sync 2.0 | Exploring and Building Open [Source] Software for OER and Learning Ecosystems and there are more posts about Git Sync on that blog too Search | Exploring and Building Open [Source] Software for OER and Learning Ecosystems

1 Like

Hi @paulhibbitts, thanks for your help!
Maybe I should have mentioned the use case we wish for using git sync.
But first of all… just syncing the user folder would totally work for us, if we did not have trouble with merge conflicts regarding the plugins, but anyhow…

We setup our Grav projects locally, than sync the projects with out Gitlab server and use PLESK to deploy and host the projects. Everything works super sweet so far.
Thing is we get in trouble when clients starts working on their website and changing content.

Right now we always need to copy the whole pages folder from the online hosting to our local dev environment to ensure we will not override the content changes done by the client, when working on the theme for example. So we hoped that git-sync would come in handy for this situation.

TL;DR We need git-sync mainly to get content changes made on the online hosting synced to our Gitlab repository so we will not override those content changes made by the customer when working on the theme and deploying the changes via Git to the hosting afterwards.

Thanks for the links btw… will definitely have a look. main / master branch is nothing to worry about, because Gitlab still name it master by default.

1 Like

Hi @seb3000,

we have decided to use 2 Git repositories as you already described :

  • One for Grav with a customized theme, custom plugins, configurations, etc…
  • The other one is used only for the page content under the pages directory.

The git-sync plugin is installed only in the production environment.
We clone the pages repository to a separate directory of our local or staging environment. Using a small bash script, this separate directory is then synchronized with the pages directory of the Grav installation within the respective environment.
Or you can do it like Paul and set appropriate symlinks. I think this is a matter of taste.

The main goal was to have (another) backup of the page content and easily keep the local and staging environment up to date.

Greetings, Peter

1 Like

Thanks everyone for your input. Still figuring out which way works best.
Does anyone know if the following error occurs because our git version is 2.1.4?
I think I read somewhere that the git-sync-plugin needs 2.9.0?

From https://scm.bit-it.com/grav/grav-git-sync-setup * branch master -> FETCH_HEAD error: The following untracked working tree files would be overwritten by merge: plugins/admin/blueprints/admin/pages/modular_new.yaml plugins/admin/blueprints/admin/pages/modular_raw.yaml plugins/…

@paulhibbitts @djamil

I do believe Git 2.9 is the current min. version, please see this thread for more info on that: branch master -> FETCH_HEAD fatal: refusing to merge unrelated histories · Issue #168 · trilbymedia/grav-plugin-git-sync · GitHub

1 Like

For now it seems like I got it to work. Only thing is the git-sync plugin creates a pages folder inside the repo. So I have all the content twice.
Any idea how to solve this?