GIT - нельзя коммитить в мастер, а что тогда?

17 Октября 2019 Программирование
2 1

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

В компаниях, которые привыкли жить в старом мире SVN или TFS даже после миграции в GIT продолжают работать по-старому, когда все программисты мусорят прямо в master. Уже давно все говорят, что мусорить в master нельзя, но все продолжают это делать, просто добавляя один шаг, который реально ни на что не влияет. 

В нашей компаний при работе над заданиями создают новый бренч:

git checkout -b wip/XXXX origin/master

где wip в моем случае означает Work In Progress (в работе), но в реальной жизни здесь обычно пишут имя проекта или имя команды. Снова вернусь для примера на мой опыт работы с Sony, вместо wip я мог писать sony/XXXX, sonyrewards/XXXX, wof/XXXXX  и т.д., в зависимости от того, над каким сайтом я работаю. Я понимаю, что в репозитории все равно будет только один проект и никогда sony не будет находиться в том же месте, что и wof, но все же это удобно и для QA, по имени брэнча они сразу же видели, что это и какой сайт нужно обновлять. 

Вместо XXXX обычно все ставят номер тикета, над которым работают. Тут никаких вопросов у меня нет, хорошая идея и я это поддерживаю. 

Но вот что происходит дальше – народ заканчивает работу в этом брэнче, отпускает в репозиторий и потом мерджит все это дело в master. Чем это лучше прямого запуска в master? Это лучше за счет того, что потом можно взять и оторвать ветку с этим изменением и GIT как бы откатит все изменения брэнча. Отлично? Но не очень. 

Отправлять изменения в master без тестирования и без дополнительной пары глаз рисковано. А оно вам нужно? Чтобы решить эту проблему был придуман Pull Request подход, когда вы можете отправить изменения в репозиторий: 

git push origin wip/XXXX 

А потом создать Pull Request для того, чтобы изменения были смерджины в master. Плюс такого подхода, этот запрос на мердж должен посмотреть другой программист, который может посмотреть своими глазами на предмет наличия очевидных проблем. Не бойтесь таких запросов. Я нормально отношусь к критике кода, потому что пусть лучше мою ошибку найдет другой программист, чем она вылезет уже после запуска кода и это станет причиной проблем.

У нас в компании именно так и работают:

1. Программист выполняет работу и создает запрос на мердж в master

2. Через какое-то время начинается тестирования этого кода в основном брэнче. 

И вот тут регулярно возникают проблемы – программисты напишут много всяких фишек и багфиксов и QA потом тестирует, но приоритет у них именно фишки, а на баг фиксы далеко не всегда остается время и потом уже код запускается, а мы продолжаем тестировать. 

Моя позиция тут простая – код не может попадать в master без тестирования. 

Проблема тут в том, что в нашей компании QA тестирует в специальных QA окружениях, которые смотрят на master и не могут смотреть на какой-то случайных брэнч. Я думаю, можно было бы сделать какие-то специальные брэнчи типа версии кода, но в компании как-то не видят проблемы и не пытаются искать решение. Здесь с самого начала работали на TFS и привыкли код коммитить в основную ветку, поэтому мусорить в master – это как пить дать. 

Я предпочитаю вводить дополнительный уровень, потому что в master не должен попадать код, который еще не оттестирован. Я считаю, что там вообще должен быть только код, который уже ушел в продакшн и используется пользователями. В моей практике были случаи, когда работаешь над какой-то фишкой, а потом перед запуском приходит клиент или менеджер проектов и говорит – а мы не хотим ее пускать в жизнь сейчас или вообще и выгрызание кода с багфиксами из мастера потом превращается в боль. 

В общем - master может быть тем, что готово к релизу или тем, что уже релизнуто. Это большая разница и я предпочитаю, чтобы это было вторым. Первый вариант тоже имеет право на жизнь как раз для таких компаний, как та, где я сейчас работаю, а вот для небольших проектов и сайтов мне нравится больше второй вариант. 

О своем подходе я писал здесь: git - современное управление кодом

Git – это круто и я использую его даже для собственных проектов, над которыми работаю один. Даже код этого сайта хранится в GIT, что позволяет мне хранить всю историю изменений. Я могу откатиться на любой момент. 

Из личного опыта хотел бы порекомендовать коммитить чаще. Я сделал небольшое изменение – закоммитил. Хотя бы один раз в день делаю git push на всякий случай, чтобы изменения были не только на моем компьютере. 

Я за всю свою жизнь ни разу еще не делал rebase и пока не было необходимости это делать. Как я слышал, rebase меняет SHA каждого коммита, а если так, то могут возникать проблемы с мерджами. 

Понравилось? Кликни Лайк, чтобы я знал, какой контент более интересен читателям. Заметку уже лайкнули 1 человек