nazar-tertyshnyi
@nazar-tertyshnyi
Govnocoder

Как лучше организовать Git?

Доброго времени суток.

Имеется git репозиторий и два сервера (dev, prod). На репозитории имеется несколько основных веток:
- master - Сборщик всякого г*вна (pull request из различных веток под задачи)
- dev - Dev окружение, dev сервер
- prime - Production окружение (sandbox для API и live для API)
И вот получается такая ситуация, что чтобы мне дойдти до прода - нужно создать 3 PR. Мне эта схема не особо нравится, задумался о том, чтобы сделать это проще и лучше, но пока не особо могу понять как.
Есть какие-нибудь идеи? Буду благодарен

Всем бобра и ключ на 13
  • Вопрос задан
  • 788 просмотров
Решения вопроса 7
@vism
Вот я как-то для проекта описывал workflow

In this project we work in team. 2,3 and more developers can do different features at same time. They can have different knowledge in PHP, GIT and standarts.
So we decided to make simple workflow for git, that important to use. Purpose is to make it so simple as possible and simple to understand for developers who used other workflows or even always edited master brange :)
This workflow very similar to Git Flow stratagy and Feature brange stratagy, but with some difference.
In Git Flow a lot of attention given to release branch. Git Flow project have rare releases that are pass tests and deeply tested.
In our project we don't have release branch and some features take few time, some a lot time. And most of them should be uploaded the next day after testing.

Workflow.
Puspose is fully separate staging code from production code. We start branches only from master branch and never from staging branch.
Also we should have good and clear history of commits.
We should be sure that changes of one developer will not disturb another developer
1. new feature:
New feature branch name should fully describe feature
New feature branch should be checkout from master branch
You can as many commits in feature branch, as you want.
When you done feature or have to test changes on staging - merge it to staging with "--no-ff --log" option
After feature tested you can merge it to master with "--no-ff --log" option
2. master hotfix:
If you need fast hotfix on master, like change typo, you can just create hotfix branch and then merge it to master with "--no-ff --log", then to staging with "--no-ff --log"

Terms.
1. We have 2 default main branches:
master - production default branch, all pushed here automatically uploaded to production
staging - staging default branch, all pushed here automatically uploaded to staging
2. It is strongly prohibited to start new feature branches from staging
3. Mandatory to start new features from master
4. Before merging branch to master, merge master into branch to resolve conflicts.
5. Merging to master and staging should be with "--no-ff --log" option for better commits history

Hints.
1. You can set "--no-ff --log" by default for master and staging branches in local repository config.
repository/.git/config
[branch "staging"]
mergeoptions = --no-ff --log
Then git merge will work with that option
In PhpStorm it also work for toolbar merge

2. You can merge with any options from PhpStorm
VSC->Git->Merge changes
Ответ написан
@Roman_S1
На нескольких проектах был такой флоу:
Ветка production из нее создаешь ветку для таски и в неё же создаешь PR. Вручную мержишь свою ветку в testing(dev) и эту ветку на тестовом сервере смотрят. Когда все ок PR с твоей веткой сливается обратно в production
Проблема такого флоу в том, что в testing со временем будет куча всякого мусора. Частично решается периодическим пересозданием testing из production (например, раз в неделю/две)
Ответ написан
@EvgeniiR
https://github.com/EvgeniiR
Создавать для таски ветку от мастера => делать дела => создавать PR в мастер.

Гуглить разные "git branching model" либо использовать https://trunkbaseddevelopment.com/
Ответ написан
BojackHorseman
@BojackHorseman
...в творческом отпуске...
окружение на песочнице и на проде должно быть одинаковое. одна ветка лишняя
Ответ написан
HeadOnFire
@HeadOnFire
PHP, Laravel & WordPress Evangelist
Какое-то у вас сложное распределение веток по ролям, а prime вообще первый раз слышу чтобы где-то использовалось/называлось так...

1. Главная ветка, она же master - содержит последнее стабильное состояние. Она же деплоится на production. Код в master попадает из develop - либо напрямую через PR, либо через ветку release/* если это большая сборка, требующая отдельной работы параллельно с develop.
2. Рабочая ветка, она же develop - содержит последнее актуальное состояние. В маленьких проектах с одним разрабом прям сюда все коммитится, в чуть более крупных - отсюда создаются ветки feature/* в которых идет работа и они же регулярно клеятся в develop обратно. Чем чаще, тем лучше. Из develop деплоится на staging.
3. Собственно текущие ветки - feature/* и тд. В каждой ветке своя фича, рассматривайте как кусок/компоненту которую можно накатить на любую другую ветку и получить фичу. После того как код из ветки принят она удаляется.
Ответ написан
@rado
Проще всего использовать 2 или 3 основных ветки:
- master/dev - сюда мерджим все ПР (автоматически деплоится на стейджинг)
- production - сюда мерджим стабильный мастер (обычно fast forward, без PR) и деплоим на прод, тоже автоматически
- qa - совсем песочница, с кривым всем, используется на больших проектах, чтобы отладить вещи, которые невозможно отладить локально, типа генерации pdf например. Без всяких PR, доступно всем.

В вашем случае снести dev и деплоить master на dev-сервер. Таким образом у вас остается один PR + сам деплой.
Все ветки с feature отпочковываются от мастера. И только хотфиксы отпочковываются и мерджатся в прод.
Ответ написан
amark
@amark
rush less, feel more
GitFlow вам в в помощь. Как говорят коллеги выше, выглядит так, будто вы слишком намудрили с ветками.

Вот Игорь Воротнёв (@HeadOnFire) выше описывает тот же GitFlow, только простыми словами.

Еще раз:
– все фичи ветвятся из дева и возвращаются в дев.
– в мастер может попасть только дев
– в крайнем случае в мастер может лететь hotfix, который ветвится от мастера; но в случае такого решения этот же фикс должен лететь в дев, чтобы потом не столкнуться с конфликтами кода.

Обычно тестируют на деве. Если вам надо разнести разработку и тестирование, то добавьте еще ветку. Как например release или stage. Обычно, это лишнее усложнение, разве что вы собираете что-то сложное с распределенной командой – но не похоже, что это ваш вариант)
Ответ написан
Пригласить эксперта
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы