How to implement automatic commit and push to remote repository using basic Ubuntu utilities? How to correctly handle the absence of changes? This repository is planned to be used for archival storage of changes on the site without cms.

We already use git normally to store the code, but now we are thinking about storing the site without cms in git. It is even more archive storage. Well, the "accountability" of what and when changed

  • Comments are not intended for extended discussion; conversation moved to chat . - Nicolas Chabanovsky ♦

3 answers 3

In my personal opinion, everything must be done exactly the opposite.

You change the site directly and want to save changes after the fact.

  • As a result, you will only have information about which day a particular row changed, but no information about the exact time and the author of the change. And when there is no information about the author, there is no responsibility.
  • And more changes made during the day will not have a backup.
  • Changes will also not have a meaningful comment. Why did they change or add something? A week later, no one will remember.

Consider that you buy a subscription for packs. In other words, technically your task is solved very easily (cron + git), but this task will not bring you closer to your goal - backups and reporting changes.

A much more reliable way is to carry out all changes at once and exclusively through git, deploying the combat environment from a specific branch (usually master or production ). There are many ways to deploy a site from git and they are beyond the scope of this question.

The point is this: if someone wants to change even one line - commits to the branch from which the site is deployed. If this commit is broken, we roll back to the past and draw conclusions.

It is very good and reliable to use the test environment, so as not to roll out immediately to the battle. In this case, you either expand the site to the test environment from each feature-branch, or from one in which the feature-branches are merged. Quite a common practice: master takes place on the stage, production takes place on the battlefield.

About the deployment of sites from git:

About the work model and releases (every change in battle is a release, albeit a small one)

  • one
    Thanks for the detailed answer with links, I'll go with him to colleagues - Alexey Shabalin
  • @AlexeyShabalin will be glad if he helps you. If you have any more questions on this topic, please notify me with a comment, I’ll probably tell you something) - Nick Volynkin ♦

Use the Cron + Bash utility. In Cron specify the period that will correspond to the call to the Bash file. It will be necessary to prescribe the creaks of the transition to the repository directory and add the following commands:

 git add -A git commit -m "время коммита, например" git push [server] [branch]

Then just run the Cron script and that's it.

But yes, this is a perversion, if you started using Git , then please kindly figure it out and what it is for, otherwise there’s not much of it.

  • I think that you understand perfectly well that this will work for one developer. For two, no longer. - KoVadim
  • But what about a commit? - free_ze
  • He is not a child, he probably knows what to do at the beginning of a commit, and then just push. But I agree with you that doing this through automation is a sort of perversion. - Aquinary
  • @Aquinary Your words "and add the following command:" as if hinting that this is a step by step guide. - free_ze
  • one
    However, the answer to the question must also be present, even though the question itself is ideologically incorrect - 4per

GIT is not suitable for this task, since it was created in order to store and track only changes in the project based on the actions of the developers. Keeping projects with their descriptions and fixing time is a task for programs from another category.