I decided to get acquainted with git. There are 2 computers (two geographically separated machines), the one-to-one folder with the project (site) is synchronized via dropbox (this is the development version of the project). Hosting is the production version of this project. How to make it so that:

  1. between local machines, the development version was synchronized one-to-one through git (via the bitbucketa server)
  2. by excluding unnecessary files from the latest development-version, get production and upload to hosting

At the moment, the development version is on the beatback

I thought so: make 2 remote repositories (on the beatback) for the dev and prod versions. In the local repo will be dev, it will be manually pushed to the remote dev. If necessary (i.e., manually), a certain magic command (set of commands) from the remote dev-repo will take the last option and copy it to the remote prod-repo. From there to the hosting pool. As a result, the chain is as follows: local-repo -> remote-dev-repo -> remote-prod-repo -> hosting. I have all the dev versions locally, on the bitpack - all versions of both dev and prod, on the hosting only the latest version of prod.

  • And what kind of unnecessary files to exclude? Maybe they should not immediately be versioned and just ignored? - Nick Volynkin ♦
  • In the deployment phase - look at this answer here, is it appropriate? ru.stackoverflow.com/a/428514/181472 - Nick Volynkin ♦
  • Here, finally, at least one person began to understand me. Yes, it would be possible to ignore, and then the hosting would fill only what I need. But what about the second local machine? There I need the latest version with all the files (version dev). DropBox? but I did take Git so that it was more convenient and that version control (including these special files) was. - Samir Routh
  • DropBox doesn't exactly fit. And you can more precisely explain what kind of files? Are they from the development environment? Any hidden parts of the site? Changes that are not yet time to release? - Nick Volynkin ♦
  • Hidden parts are modules that are needed for the dev version (such as a debugger, etc.) and changes that are not yet released (or several variants of the same, but so far I have not chosen which is better) - Samir Routh

4 answers 4

git does not synchronize itself, you have to do git push to send changes to the server and git pull to receive. At first glance, it looks inconvenient (after all, you need to commit and push permanently) and do not get to "work a little on one machine, and then a little on another. But it’s not necessary to keep the same versions. You can do different functions on different computers. Over time, you will come to understand And you can allocate yourself a server for development. Then many "problems" will go away on their own, but you need constant access to the server.

Now the second part is the warmth. There are many options, but divide them into two parts - automatic and manual. With the automatic option, the maximum that is needed is to press the "deploy" button, and sometimes this is not necessary, but as for me, it is very dangerous. Others respond to this and say when they mention CI. With manual everything is transported by the piece, but this is for special fans.

But I think that at first you will approach semi-automatic mode. It is very simple and reliable. The bottom line is to write your script (in any language (if you know php - write on it, I would write on a mixture of bash and pearls). This script should do the following - merge the master branch into a separate clean folder, then delete from there “extra files” and add “correct files / configs". You can also run tests (if any). At the very end everything is packed into the archive. The same script can copy the file to a remote server (a). And then on the server, another script is needed that will stop the Apache (or whatever the server is); That’s the old (if needed) and will unpack the new (and of course it will start the server).

As a result, the warming up of a new code is the launch of one script to collect a package and one more to launch it itself. In the future, these scripts can be used for the same CI.

Many people think that deploying to a server is possible and necessary using the same git. But this is absolutely wrong - there will be "extra data" on the server. If the server is accidentally hacked, it gets access not only to the whole story, but also to the repository.

  • "Many people think that deploying to the server is possible and necessary using the same git. But this is absolutely wrong - there will be“ extra data ”on the server. If the server is accidentally hacked, it gets access not only to the whole story, but also to the repository.” That's it, I'm talking about this and say: I need the latest prod version and everything on the hosting. And the repository with all the prod versions with the history, to be stored on the beatback server, so that from there I could always take the latest version and upload to the hosting. - Samir Routh
  • About hacking the server - absolutely true. You can not store repositories there. - Nick Volynkin ♦

Without Continuous Integration nothing will be synchronized. Only with hands doing pull'y on the right servers / machines.

If you are just starting to get acquainted, it would be better for you to familiarize yourself with the documentation and standard workflow. There are at least two popular ones: gitflow and githubflow. For small projects / teams, the second option is more suitable (in my opinion).

  • so i want pens. But how? How to pull from a beatback for a local machine to differentiate from pull from a beatback for hosting? - Samir Routh
  • Add local configs to gitignore. In production, you probably should always have a working branch (stub) - master, for developers and development environments, create a second branch, make changes to it, make pull from this branch anywhere, and as soon as you realize that you need to send the code to Prod, merge the development branch into the master and make a pull from the master to the prod server. - Powar
  • so, this seems to be what i need. I will try in the evening, accomplish your goal with me. thanks - Samir Routh

In normal projects, they usually put a Continious Integration (CI) server, which, under certain circumstances, deploit the project to production.

We have this: Teamcity (CI) is subscribed to our GitLab, there is a hook, in which every merge in the release branch with a tag v1.0.1 (we call them v1.0.1 , v1.0.2 , etc.) passes the last test (before This was separately tested by the branches themselves with features). After successful testing, a special deployment script is executed, which updates the necessary files in the necessary folders.

  • Guys, I'm new to php, but for the first time I come up with Git, which is CI ??? Moreover, I am alone. Those who have serious projects and a team of several people and who need CI will ask questions similar to those I asked? - Samir Routh
  • Since you are offering CI for this task, let's immediately 12factor-app and release containers, which trifles) - Nick Volynkin ♦
  • I painted not the most complicated deployment scheme, but which can be set up for free, on my own and spending no more than a week on it (including reading the documentation on any incomprehensible questions). Even if only one person works on the project, nothing bad will happen if he learns to do everything initially beautifully and correctly. - Michael Sivolobov

You need to create a new branch in the repository on the dev server, for example production. In this thread, change the necessary files to work on another server:

  - поменять конфиги для работы с другой базой - рабочий домен - и т.д, зависит от реализации вашего проект

After that you push into your repository on bitbucket.

On your production server you clone the repository, switch to the production branch.

As a result, you have 2 branches:

  - development, для разработки - production, для основного сервера, куда вы сливаете все новые обновления из ветки development. И на основном сервере делаете pull.

You can even automate a little branch update on the main server. To do this, create a cron git pull task that runs every minute.

Then it will be enough for you to make a push from the production from the test server and the change will arrive on the main server

  • Your lists are formatted as code. Is this consciously so? The last line is difficult to read because of this. - Nick Volynkin ♦
  • Crown task is bad, creates an extra load on the network and the server. The meaning of updating is only when the branch from which the release is made has been updated. To do this, you can configure the hook. - Nick Volynkin ♦
  • Yes, I have a small project, all the changes I make only one. I do not need kroner, I'll manually. In the evening I will try to do as advised and accomplish my goal - Samir Routh