Pull to refresh
4
Karma
0
Rating
Сергей Моргунов @ihostage

User

Rebase Flow. Способ приготовления и его поддержка в GitHub, GitLab, BitBucket

Вынужден не согласиться. Проблемы чистоты истории влияют не только на отображение.


Да, как я упомянул в статье, у нас есть ключи для терминального git log и различные способы фильтрации для GUI клиентов. Тут вы конечно правы и это несколько поможет в проблеме анализа истории и улучшит её визуализацию. Но на этом проблемы не заканчиваются.


Помимо анализа истории возникает необходимость работы с нею. Классический для нас кейс, когда заказчик очень быстро меняет требование к скоупу релиза и просит добавить/убрать из поставки любой набор функционала, который ему захочется. В этой ситуации работать с merge-коммитами далеко не так удобно, как если бы их не было.

Rebase Flow. Способ приготовления и его поддержка в GitHub, GitLab, BitBucket

Засчитано. Вот только с командой мейнтейнеров ядра я никогда не встречался :)
Хотя о кейсе работы с ядром линукса я, как и многие наверное, узнал когда-то из этого видео от первоисточника. Но всё-таки считаю их кейс использования git'а скорее исключением, чем правилом.

Rebase Flow. Способ приготовления и его поддержка в GitHub, GitLab, BitBucket

Создалось впечатление, что на одном проекте работаем. У нас правда тикетов за 15К перевалило, но заказчик у нас явно один и тот же :)

Rebase Flow. Способ приготовления и его поддержка в GitHub, GitLab, BitBucket

В статье говорится о ситуации «Перед вливанием feature-бранча в итоговый». В этот момент все работы по feature-бранчу завершены и он мержится в итоговый. Для того, чтобы история была линейной, мы в любом случае вынуждены сделать force-пуш.


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

Rebase Flow. Способ приготовления и его поддержка в GitHub, GitLab, BitBucket

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


PS: Децентрализации git'а для меня конечно же не новость. Вот только мне ещё ни разу не приходилось встречаться с командами, которые используют git в формате p2p, без выделенного remote-репозитория, к которому подвязаны различные инструменты из области CI. Хотя скорее всего такие команды существуют.

Rebase Flow. Способ приготовления и его поддержка в GitHub, GitLab, BitBucket

Не могу не согласиться. Лично я ещё очень надеюсь, что Upsource составит сильную конкуренцию. Он безумно удобен для проведения Code Review, но вот с поддержкой различных flow по работе с самим репозиторием было не очень (во всяком случае обещалось это ещё в 1.0, но когда я последний раз смотрел на него, этого функционала там ещё не было).


PS: Хотя вот на сайте сейчас для версии 3.0 говорится об интеграции с pull request'ами на github. В каком виде это реализовано не знаю, может кто-то в комментариях подскажет или сам @JetBrains расскажет на какой-нибудь конференции :)

Rebase Flow. Способ приготовления и его поддержка в GitHub, GitLab, BitBucket

Действительно может показаться что информации маловато. Но в случае с GitHub/GitLab/BitBucket, часть сообщения «#96» — это ссылка на баг-трекер, что позволяет в один клик добраться до нужной информации. На мой взгляд это очень удобно.

Rebase Flow. Способ приготовления и его поддержка в GitHub, GitLab, BitBucket

Отдельный багфикс в отдельном feature-бранче. Тут подход классический и скорее относится к организации работы команды с баг-трекерами.

Rebase Flow. Способ приготовления и его поддержка в GitHub, GitLab, BitBucket

Если речь идет о ручной реализации Rebase Flow то да, второму придется сделать rebase. Если же используется например GitHub, GitLab или BitBucket, то у них это автоматизировано и при соответствующих настройках репозитория достаточно нажать одну кнопку. По сути именно об этих удобствах вторая часть статьи.

Rebase Flow. Способ приготовления и его поддержка в GitHub, GitLab, BitBucket

Признаться я не писал об удалении смерженных бранчей. Смерженный бранч попадает в историю окончательно и оттуда не удаляется. Он просто мержится не в виде merge-коммита, а в виде линейного продолжения истории. Содержимое бранча при этом может остаться абсолютно таким-же.

Зачем смотреть на графическое представление? Тут ответ на самом деле прост. Прийти в эту точку можно в два шага.
1. Я смотрю на строчку кода и пытаюсь выяснить в рамках какой задачи и зачем автор её добавил. Для этого я смотрю к какому коммиту привязана эта строчка. Если в сообщении к коммиту я виже «issue-1 исправлена ролевая модель», то все хорошо. Я получил ответ и не потратил много времени. Если же я вижу «fix bug, refactoring» или что-то в этом духе (что часто возникает при частых коммитах в длинных бранчах), то перехожу на шаг 2.
2. Иду анализировать историю коммитов (те самые картинки на скринах), чтобы понять в рамках каких работ был сделан этот коммит. И если история очень грязная, то это занимает немало времени. Хотя все могло бы закончиться на шаге 1, будь она чистой.

Rebase Flow. Способ приготовления и его поддержка в GitHub, GitLab, BitBucket

Да, любые манипуляции с историей на первый взгляд кажутся злыми по определению, но я бы не был столь категоричен. Ведь именно этот вариант реализован сейчас в github, а значит многие разработчики пользуются этим функционалом и злом его не считают.

А что, если те самый 2-3-4-5 коммитов были декомпозированы на разные задачи изначально? Тогда их делают разные разработчики и они отдельно тестируются. В итоге мы приходим к ситуации, когда у нас не 1 feature-бранч из 4 коммитов, а 4 feature-бранча из 1 коммита и тогда становится уместным сделать им автоматический squash до того самого единственного коммита.
Но вообще, это уже начинает упираться в вопрос о размерах конкретных задач в конкретной команде на конкретном проекте. И в этот момент лучше использовать гибкость git'а и адаптировать его под командный процесс, чем самим прогибаться. Как я говорил в статье, я убежден что каким-то камандам/разработчикам может никогда и не понадобиться уходить от классического GitFlow.

Rebase Flow. Способ приготовления и его поддержка в GitHub, GitLab, BitBucket

Да, действительно, все это можно сделать и локально, написав предварительно небольшой bash скрипт. Но сделано это все ради экономии времени. Ведь можно пойти дальше и полностью автоматизировать рабочий процесс. Например, выполнять автоматический мерж после того, как N членов команды заапрувили pull request и все автотесты пройдены. Тогда никому ничего локально и не нужно будет делать.

Rebase Flow. Способ приготовления и его поддержка в GitHub, GitLab, BitBucket

На самом деле, не все так страшно. Да, force пуш опасная операция в неопытных руках. Но фатальных последствий можно избежать, если использовать пермишены на force пуш для ключевых бранчей репозитория. Ведь речь идет о force пуше только feature-бранчей. Пермишены можно выставить как локально, для собственной безопасности, так и на удаленном репозитории. Все перечисленные в статье менеджеры репозиториев этой функцией в каком-то виде обладают.
2

Information

Rating
5,876-th
Location
Чехов, Москва и Московская обл., Россия
Date of birth
Registered
Activity