Teamwork in Git

Question

git

There was one such, but a global question about building a git architecture for team work of 2 people on a site.

The bottom line is, there is a site that has a working copy (test.example.ru), with which 2 programmers work. They write new features and upload the functionality to example-test.ru for testing there, and if everything is ok, it is then transferred to production (example.com).

So this is the question about the architecture, how best to organize it in order to avoid bugs and glitches and make it as transparent as possible?

I have these options:

1. Developers connect to the repository of the test copy of the site, clone it and then work directly with the master branch, making commit and push to see the changes and check the functionality, in case something breaks in terms of functionality, the programmer fixes it and does more time commit, push and again checks whether everything is ok.
- I see several difficulties with this approach, firstly, branching is not used at all, and secondly, if one of the programmers broke something without suspecting it and uploaded the changes, then everything will break for the second programmer, the test copy of the site too.

2. Make 2 test copies of the site (each for the developer). Here, everyone will be able to break at their discretion, and branch as they please. But I vaguely imagine such an architecture.

3. Make branches, for example fix_35 and work directly with the branch. But here I don’t know if it’s possible to somehow make it clear to the remote repository (which works as a hub-live) that it is necessary to show files on the test copy of the site not from the master branch, but from fix_35? Well, it seems like it will not work at the same time in this scenario.

In general, I will be very grateful for advice. I myself encounter this for the first time and it is possible that some or almost all of the solutions I proposed will turn out to be complete nonsense.

PS Git is set up as a hub-live, as described in this article .

Answer 1

I wanted to fill a long answer, but scored. Still, there is no perfect solution. For two developers, I would do this:
dev.site.ru ->test.site.ru->www.site.ru
for each developer to install a git repository locally, and first work in the locale, then commit to dev and see how it works there on the norm. data. Well, further migration along the arrows.

Answer 2

The DVCS ideology assumes that each developer has his own repository in which he creates branches, checks their effect, and then uploads the finished code to the top (upstream).
It is logical, therefore, to either give each developer at the same time the opportunity to raise their own test copy of the site.
If this is not possible, then it is appropriate to arrange things in such a way that each developer has his own branch on the main test copy of the site and the opportunity to test the code there. This branch will then become an upstream for him , that is, the place where the developer will upload the code from his personal repository. There, after checking his code, the developer will merge from there to master.

Answer 3

If in short. That in GIT is a very convenient system of branches. We use the following branching technique on our project:
1 - dev
2 - qa
3 - production
That is, developers work directly with dev, and then new features migrate to testing by gluing branches and from there to production.
Each has its own local version of the site for ease of use. All three branches are also deployed on servers accessible from outside.

Answer 4

We had the following branches:
1. master. Stable development branch. Developers cannot commit to it. develop is merged into master.
2.develop. A more or less stable development branch that can be merged with master at any time.
3. feature-somefeature, feature-onemore… Branches of developers in which they work implement features. Once the branch is tested, it is merged into develop.
4. hotfix-hotfixname, hotfix-onemore… When a critical bug was found and it needs to be fixed urgently, but develop is not yet ready to be merged into master, a hotfix branch is created from the master, a fix is ​​made, the hotfix is ​​uploaded to master and develop (with conflict correction if any exist).
We also had test servers deployed, their configuration was identical to that of the production server. On the test servers, developers could switch to their own branch and test some feature live.
Well, the production server looks at master and, when necessary, git pull is done on it.

Answer 5

What I do in this situation:
There is master, there is always only stable code, that is, after each commit, before pushing (ideally, before commit), tests are run. All features are made in local branches (if several people make a feature, this branch can be pushed). When a feature is finished, it is merged into master.
The dev version of the site usually clones from master, in rare cases a dev branch is created (although in my memory this was never needed).
And then, if you work in iterations and you have several versions to be deployed, everything is carried along its branches. On the server, just a checkout of the desired branch is done.
That is, they completed the feature - they merged it into the master. Ran the tests. If everything is good, we push. If you need to roll it out to live or somewhere else, merged the feature/master into the desired branch. After changes in branches other than master, everything should be frozen into it, because branches with features are made from the master.

Answer 6

From experience (I've already put five commands on Git, now I'm watching the results) this is the most convenient and painless model I've tried in 5 years of using Git:
nvie.com/posts/a-successful-git-branching-model/
As an added bonus, it comes with a set of ready-made git-flow scripts (https://github.com/nvie/gitflow) that allow you to branch and merge with absolutely magical syntax:

git flow feature start superauth
git commit ...
git commit ...
git flow feature finish superauth
git flow release start v0.1
git commit ...
git commit ...
git flow release finish v0.1

And autocomplete for these mechanisms is easy to google ...

Answer 7

these two articles helped me in a similar question
habrahabr.ru/post/75990/
habrahabr.ru/post/60347/