Working with Git on Kirby projects, doubts

Kirby 2 Solved ✅
1

Hello,

A friend and I make Kirby based websites together through ftp users and directly on the server.

We changed host and this one does not allow more than one SFTP account, and it suggests using Git instead.

We have some doubts with Git + Kirby, please help us understand:

  • As Git pulls to local by definition, won’t we need to modify routes to make the website work locally aswell as remotely on each pull? or shall we not pull kirby routing files each time?

  • What about in-panel modifications ? if made on the server, will the pull command pull those too ? How about locally when pushing?

  • How do we deal with different php versions locally and remotely? Is this relevant at all ?

  • What other caveats should we be aware of?

  • Is it worth it ?

Thank you very much!

1 Like
2

Hello @plagasul
Working with git and Kirby, in my opinion, is amazing.
There’s a plugin that commits every change done in the panel and pushes. So you’ll just have to pull on your remote machine to get the latest update.

Though I strongly recommend using two different branches, one for live and one for development, so prevent merge issues.
For larger files like images etc, you can use git LFS (Git Large file system), as it’s designed to cope with large files like jpg, etc.

Working in Git is worth it, indeed.

I also strongly recommend keeping the same PHP version locally and remote, this is to prevent something to maybe work locally but then it doesn’t work remotely.

1 Like
3

First of all, I think you mixed two things up, that I would recommend to separate: The Kirby page and the content folder.
I would have the Kirby installation without the content folder in one git repository. The content could be another repo, as @tnViking mentioned.
To deploy the changes to the installation repository I realized a solution for a customer, which involves a post-receive hook. This script deploys the changes of the master or develop branch to the main or staging site at each push to the server repository (which will be at the same web server).

Because you have git on your hosting provider, I would assume, that there is ssh as well.

For the content folder, I personally don’t like to put quite large files into git (but I also haven’t used git LFS yet).
So the content of my sites is synchronized between the local development site and the server by some rsync scripts. But I’m the only person editing the content on something other than the panel.

I just wanted to mention this method as another solution, but it depends on your use case, if it’s a good solution for you.

About the routing I would think, that it shouldn’t be a problem, if your routes do not contain the whole domain name. But this also depends on your local setup. Especially, if you don’t just have localhost for your local site, but localhost/somesite.

Is it worth it? I think, for the code definitely.

1 Like
4

I agree with @jbeyerstedt. It makes sense to separate code from content and work with two repositories.

For the content, you can either use a plugin like Auto-git, or some other sync method. If you use Auto-git, I would recommend to do the pushing only once a day via a cron job, otherwise, if you do it on every change/commit, this would slow down the Panel too much.

As regards PHP versions, it makes sense to use the same PHP versions on both local and remote servers for the reasons outlined above, but this is not Git related and should be done no matter if you version control your content with Git or not.

Routes should usually be relative to the domain, so I don’t see any issue there. If you do need different routes on local and remote, and if you define routes in your config file, you could set up custom config files for each environment.

Make sure to gitignore account files, license or API keys if you use public repos on GitHub/Bitbucket etc.

An option for deployment would also be a service like Deploybot or similar.

Using Git makes totally sense, as an indispensable tool when developing, as a backup solution and as a means of deploying to different servers.

And as a file based CMS, Kirby really lends itself to version management.

1 Like
5

You should use Git, with or without Kirby. The fact Kirby is file-based makes it an even easier decision to make. There are plenty of resources on the internet that go in detail as to why one might need to use Git (or version control in general), make sure to look that up. One that I found coming up often was this: http://mikemcquaid.com/2014/01/18/why-use-version-control/

As to your questions:

  1. No, Git works entirely in the background. That means you would not need to change anything regarding routes, configs, or permissions, except one time when you’re setting everything up. Unless of course you’re host dependent (which you shouldn’t, and can take this as an opportunity to address that).
  • As others suggested, auto-git is a great plugin for this use case. The optimal use-case would be: on prod is a running version. When you need to perform a change, do it locally on a separate branch. Submit that branch to your Git host (for example: github, bitbucket, etc.), and create a pull request. Your friend reviews it, accepts pull request, and your changes are deployed to prod. He would need to pull master when he does that to make sure his local version is also updated.
  • It is relevant, but not to an extreme extent. We use php local webserver for our local development, and host on a prod level PHP on our prod (and staging) servers. As long as you’re running locally with notice level warnings and handling every warning/notice, you should be fine on prod too.
  • In regards to others mentioning to split up your content into its own git repo, I would recommend not to. Maintaining submodules in git is not as straight forward as one would hope, and that will become more apparent if you decide to automate certain aspects of your process. I would say the major two reasons that would somehow influence your decision to do that are:
  • if you decide to use Git LFS for big files, you probably need a separate content repo setup.
  • if you make frequent changes to your content folder and it would cause lots of “noise” to your git log to keep them with your development log/history.
  • Worth it? Absofreakinglutely. You’d be surprised how you haven’t been using it from the beginning.
1 Like
6

Thank you all very very much for your answers and suggestions. Very helpful. We are giving it a try :slight_smile:

I have a related question, that may actually be a basic question but I am a bit confused: If I change owner or permissions of files on a LOCAL cloned git repo, then push these to the remote original git repo, will I mess the owner or permissions of the files on the remote repo aswell ? the same when pulling them again, will I also pull permissions ?

Thanks again.

7

git config core.fileMode false

… makes git ignore file/folder permissions. Some more information.

1 Like
8

Thanks! There are some warnings about using this, tho. If anyone finds this, read well before using.

Thanks again.