How to use git in web studio?

Question

git

Hello!
You and a friend have a small web studio. Two developers. Very often, we work together on the same site and sometimes we need to touch the same files. We work via ftp.
I understand that you need to implement GIT, because It's already tired of coordinating who opens which file now.
Now we have lined up. scheme:
sitename.ru - real site. Current, working version of the site.
test.sitename.ru - a copy of the site where the current development and testing is being carried out.
From test to real, we shift c/o ftp. Those. downloaded via ftp from test to the local machine, and then from the local machine we also transfer via ftp to the real one (the collective farm, of course).
developer #1 works with test.sitename.ru directly via ftp (notepad++)
developer #2 periodically downloads the contents of test.sitename.ru to his local machine. A web server is running on its local machine, it makes edits and, as tasks are completed, downloads updates via ftp to test.sitename.ru
Resp. periodically we overwrite each other's files and it's enough.
Here is the scheme as it is now: It is

necessary to implement GIT, and here I have a number of unclear points:
1) Is the repository something separate, independent, lying away from the test and real site?
2) Or does each developer have their own repository? But how then does data synchronization happen if we both corrected the same style.css?
3) Developer #1 will also have to install a web server on his PC and work locally?
4) Which scheme of operation is correct?
one:

or two:

I would like at least to the level of the test server, to abandon ftp altogether.

Answer 1

1) A repository is a single repository of files that is located somewhere and you and your partner upload commits there, they are also edits.
2) Each project has its own repository. Files merge into 1 automatically. If git can't do this, it will ask you exactly how to merge the files. But usually the files merge on their own very easily.
3) Both developers must work and test features locally or on their own server. You should not have a common server, otherwise you will grind each other. Upon completion of the edits, the revision is uploaded to the general repository and it is already deployed (automatically or manually) to the production server, bypassing your link from test.site.ru. If you need someone to test, for example, the customer checks the edits before uploading to the main site, you create a separate branch in which you are developing. This branch will be rolled out to test.site.ru, then it will be merged into the master-branch and poured onto the main site. 4) The
second scheme is correct /briefly-about-gitflow

Answer 2

Take GitLab, create two branches in the repository: dev and master. Set up deployment (CI / CD) from the dev branch to test.site.ru, from master - to production, i.e. site.ru. Accordingly, when changes are made to the branch, the changes are immediately uploaded to the server, and when the files are "overwritten" each other, a warning will be issued and you can merge two files into one

Answer 3

see git-flow.

Answer 4

You don't need Git yet - you have to line up the work, not take on one task at a time.
Perhaps you manage to edit one file this way - because it is 100500 lines long?
Split these files according to logic and OOP of course.
If one is engaged in the front, let him not get into the back.
Set tasks in asana for example and post them at the beginning of the working day.
The decision to merge should be made by one. One project - one responsible. To make it not offensive and on an equal footing - divide it equally))
notepad ++ in the furnace. We must grow. Netbeans (yeah - they bury him, and he has already been updated several times in the Apache incubator over the year. Live alive and knows a lot for web development) or VSC, for example, from free ones. The first one can git at almost 100% (I did not face the task that he could not do it).
As mentioned above, the git repository must have branches - according to the feature being developed, for example, or the version. Then merge into one.
Each developer has their own local or remote server. But not one common. I often move and the remote server helps me with this. Netbins knows how to do it by default. VSC will have to shamanize choosing from thousands of plugins. It's still a whistleblower.
Deploy to the production site through github webhooks or through the CLI
. And remember - even a small edit cannot be done on the production site. Properly selected tools and organized processes will get rid of the nonsense like "yes, there is a bit of tweaking, so quickly"
Testing .... probably left for "later"?