GIT workflow или как работать с проектом

Как использовать GIT, может зависеть от многих факторов, например как проходит тестирование, работает ли целая команда над проектом или один разработчик соло.

Соло разработка

Концепция работы с GIT в случае одного разработчика сводится обычно к тому, что есть одна основная ветка (main или master) и вы работаете преимущественно с ней.

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

Рано или поздно ветка возвращается в main

Мелкие фиксы, над которыми вы работаете прямо в ветке:

Работа с GIT в команде

Здесь у вас скорее всего есть несколько основных веток для разных серверов TEST — test, UAT — uat, LIVE — main.

Сервера TEST и UAT служат для тестирования, первый — для тестирования разработчиком в условиях близких к продашн, а второй — для тестирования клиентом, чтобы не пересекаться с разработчиком. Например, клиент может создать сдесь какой то элемент контента, страницу и т.п., чтобы оценить как это будет работать, не опасаясь что-либо сломать или что это будет опубликовано.

Когда один из разработчиков приступает к работе над своей фичей (тикетом), он отпочковывает ветку от main. Обычно при этом ветке присваевается какое то наименование, связанное с используемой системой нумерации тикетов. По мере готовности ветка мерджится в test, uat.

Если фичу (тикет) решили задеплоить с прочими готовыми тикетами на LIVE, то обычно собирают все нужные тикеты в одну промежуточную ветку и мерджат уже её в main. Последний шаг зависит от того как устроен деплоймент. Если изменения main ветки приводят к автоматическому деплойменту, то использование промежуточной ветки неизбежно.

После деплоймента делают merge из main в текущие ветки, а также в test и uat. Ветки тикетов, которые ушли в продакшн, удаляются, т.к. в них работа больше не ведется. На дополнения и баг фиксы создаются новые тикеты, и, соотвественно, работа с ними будет вестись в других ветках.

В чем суть такой работы с ветками?
Гибкость деплоймента. В продакшн попадают только те тикеты, которые готовы и были одобрены для деплоймента. Т.к. все они стартовали с main, то они легко возвращяются обратно в main.

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

Мало букафф? Читайте есчо !

Тонкости настройки в .gitignore

Июль 17, 2017 г.

Настройки в файле .gitignore позволяют исключить из списка файлов сканируемых GIT, все то что отслеживать не надо. Обычно это так называемые юзер-файлы, изображения, архивы, документация и т.п. В данной статье рассмотрим типовой случай настоек в .gitignore. ...

Читать

Git pull с передачей логина и пароля

Декабрь 11, 2021 г.

Репозиторий почти всегда требует реквизитов доступа. И, если вы их не храните в локальной конфигурации, то скрипты, содержащие git pull, будут прерываться, запрашивая пару логин/пароль. Передать реквизиты с отдельным ключом нельзя, но можно задать ...

Читать

Создание патча для модуля Drupal

Декабрь 4, 2017 г.

В Drupal для решения ваших задач вы подбираете contributed модули. Отлично, если модуль поддерживается автором, в нем нет багов и есть нужный вам функционал. В противном случае, вы, возможно, правите модуль и используете его для себя. Но, наверное, было ...

Читать

Удалить новые (untracked) файлы в git

Июль 31, 2024 г.

Иногда нужно избавиться от новых (лишних) файлов, привожу примеры команд. Если это случается регулярно, в процессе компиляции, сборки, у вас создаются файлы, которые вы не будете включать в commit, то, наверное, стоит подумать и включить их в настройки ...

Читать
 

Комментарии к «GIT workflow или как работать с проектом»

Понравилась статья? Есть вопросы? - пишите в комментариях.



Комментарий: