How to use version control for a website on a regular hosting?

Question

git

Hello connoisseurs!
I want to transfer the development / support of sites to git, but there is a problem here, almost all client sites are on regular hosting, where there is access via ftp, and it’s not very convenient to work like that. I have long wanted to start using git, but I don’t know how to do it with such sites, the problem is that several people can work on them, and when uploading, you need to take into account possible changes already on the hosting.
Those. merging everything to yourself creating a repository on github or bitbucket is not particularly problematic, but it’s not clear to me how to upload everything to the hosting.

Answer 1

How to use version control for a website on a regular hosting?

Transitionally simple. The recipe is this:
1. Take any, you can get the cheapest VPS (if you don’t have your own server)
2. Set up GIT repositories there in the right amount
3. In each repository, put a script hook that will upload the changed files to the needed FTP server ( Judging by the links above, such solutions already exist either in finished or semi-finished form).
That is, you just need to familiarize yourself with the mechanism of the "hooks" of the git, as I see it. And perhaps you can also get acquainted with FTP clients launched from the console, or the mechanism for mounting FTP as a file system ... There are many options, you just need to choose.

Answer 2

Surprisingly, some "regular hosts" (for example, beget, I don't advertise) know how to use git. This is usually done upon request.
Check with hosting support.

Answer 3

The problem described is just the tip of the iceberg.
You need to change the approach to development itself.
While the client will climb into the code and on FTP, you will not be able to work normally with git.
As long as the client's site is on shared hosting, you will not be able to work normally with git.
There will be problems with version discrepancies on ftp and your local environment and repositories, conflicts will begin when migrating the database.
In general, try it, you will understand that something is not right and in the end you will come to a normal solution :)

Answer 4

git does not support ftp protocol. Therefore, in the context described, the work should be structured as follows:
1) We start an empty repository in bitbucket or github (I remind you that private repositories in github are paid).
2) Clone it locally to the X folder.
3) Set up an ftp client (for example, FileZilla) to this X folder and the folder on the hosting.
4) Upload files to hosting sites.
5) Add the appeared files to git (git add).
6) Commit from (git commit -a).
7) Send changes to a remote repository (bitbucket/github, git push).
From time to time, via ftp, we merge files into a local folder, and via git diff we look at the changes. If they are legitimate, then we do a git commit. If not, we roll back the necessary ones (git checkout file_name). We fix it again (git commit), send it to the remote repository (git push), re-upload from the local folder.

Answer 5

There are many ci/cd services. For example buddy.works there you just need to specify your git repo and what to upload with each commit to the master on the ftp server.
It's all free if the deployments don't consume a lot of resources. You can always run Jenkins on a raspberry pi or vps.

Answer 6

Hosting must have git installed. It is filled also - through clone.

Answer 7

Merge your repo and upload via ftp

Answer 8

If you have not been able to find options on the Internet so far, then it is better not to meddle.
And there are plenty of options.
The simplest - created a repository on git / bitbucket, set up access, etc. cloned-uploaded via ftp
More difficult - hooks + continuous integration services.
Well, even more difficult - hooks, settings on the server and SSH

Answer 9

https://deploybot.com/
Pros:
1. There is everything you need for efficient deployment (upload via ftp, sftp, atomic sftp...)
2. Ability to pre-build the frontend (gulp, grunt... ) on a separate docker container
3. You can specify patterns of excluded files or folders for
uploading 4. Notification through different services (for example, slack) about the upload status
Minus: the service is paid (15 bucks per month for 10 projects)