Github - нужнейший сервис

Остальные вопросы по работе с операционной системой Windows
netraider
Мастер
Сообщения: 209
Зарегистрирован: 23 май 2015, 10:47
Репутация: 49
Настоящее имя: Юрий
Откуда: Москва
Контактная информация:

Re: Github - нужнейший сервис

Сообщение netraider »

Одна из самых замечательных возможностей git'a - простота и "дешевизна" создания веток. Никакие полные копии каталогов не создаются. Переключение между ветками мгновенное. Плюс еще несколько полезных мелочей. Но это имеет значение только при определенном workflow.

У меня это выглядит так (локальный daily workflow): любые работы в рамках некоторого требования выполняются в отдельной, локальной ветке. Иногда ведется работа над несколькими требованиями параллельно (что-то срочное, или наоборот какой-нибудь долгоиграющий рефакторинг) в нескольких локальных ветках. Наработки, некоторые атомарные части, эксперименты и т.п. тоже постоянно коммитятся(локально), иногда откатываются (далее я их буду называть техническими коммитами). При необходимости выполняются слияние из общего master/trunk/etc. По завершении локальных работ - все наработки уходят "наверх" либо одним либо несколькими коммитами, но тут уже ничего лишнего нет.

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

Вот для выполнения этих мелких, локальных действий git подходит идеально.

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

Организация веток на "серверной" стороне - это отдельный вопрос. Здесь все зависит от возраста/истории/особенностей компании и выпускаемых продуктов. Но, в силу "дешевизны" веток в git, можно подстроиться практически под любой процесс/workflow. https://nvie.com/posts/a-successful-git ... ing-model/ например и т.п.
Проблемы, связанные с тем что несколько людей вносят правки в одни и те же файлы (и в одни и те же места) одновременно - git совершенно не решает. Это может возникнуть в любой VCS. Решается административными мерами - назначение ответственных, более частые коммиты, разделение задач по времени т.п.

Другой путь – частичное изменение workflow, но там тоже есть нюансы. Например в большинстве случаев введение release branches очень сильно упрощает жизнь. Но если жизненный цикл версий продолжительный – то могут возникнуть проблемы, т.к. код между релизной и основной веткой имеет тенденцию к расхождению, и чем дальше (по времени) тем больше. Попытка добавления функциональности в старую релизную ветку приведет к проблемам, если вдруг выяснится, что эту функциональность нужно перелить в основную через N месяцев. Но опять же - это не проблема VCS как таковой.

Собственно в большей степени все зависит от используемых процессов, а не от системы контроля версий.

PS: вот хороший бесплатный клиент для Git под Mac/Win: https://www.sourcetreeapp.com/
Поддерживает chunk staging (git add -p), можно выбирать какие именно части одного файла попадают в коммит.
--
At the nanometer level, the world is made of rubber (с)
Аватара пользователя
Serg
Мастер
Сообщения: 21923
Зарегистрирован: 17 апр 2012, 14:58
Репутация: 5181
Заслуга: c781c134843e0c1a3de9
Настоящее имя: Сергей
Откуда: Москва
Контактная информация:

Re: Github - нужнейший сервис

Сообщение Serg »

netraider писал(а):Одна из самых замечательных возможностей git'a - простота и "дешевизна" создания веток. Никакие полные копии каталогов не создаются. Переключение между ветками мгновенное. Плюс еще несколько полезных мелочей. Но это имеет значение только при определенном workflow.
Это все есть во всех VCS.

Для примера пара применяемых "фишек" из-за отсутствия нормальной реализации которых git не прошёл: Другие репозитарии в составе основного репозитария проекта, над которыми ведётся работа участниками нескольких разных проектов (например библиотеки), права доступа на отдельные части проекта с точностью до файла.
Я не Христос, рыбу не раздаю, но могу научить, как сделать удочку...
netraider
Мастер
Сообщения: 209
Зарегистрирован: 23 май 2015, 10:47
Репутация: 49
Настоящее имя: Юрий
Откуда: Москва
Контактная информация:

Re: Github - нужнейший сервис

Сообщение netraider »

UAVpilot писал(а):
netraider писал(а):Одна из самых замечательных возможностей git'a - простота и "дешевизна" создания веток. Никакие полные копии каталогов не создаются. Переключение между ветками мгновенное. Плюс еще несколько полезных мелочей. Но это имеет значение только при определенном workflow.
Это все есть во всех VCS.
TFS полностью копирует стуктуру каталогов/файлов при создании веток.
Еще из полезных мелочей - в git есть возможность добавления в коммит части изменений из одного файла (а не всего файла целиком).
UAVpilot писал(а): Для примера пара применяемых "фишек" из-за отсутствия нормальной реализации которых git не прошёл: Другие репозитарии в составе основного репозитария проекта, над которыми ведётся работа участниками нескольких разных проектов (например библиотеки)
Submodules? https://git-scm.com/book/en/v2/Git-Tools-Submodules
UAVpilot писал(а):права доступа на отдельные части проекта с точностью до файла.
У нас это когда-то тоже было одним из пунктов "против". Вылечилось "переосмыслением" и переносом файлов в отдельные компоненты/репозитории, и назначением прав на них.
--
At the nanometer level, the world is made of rubber (с)
Аватара пользователя
Serg
Мастер
Сообщения: 21923
Зарегистрирован: 17 апр 2012, 14:58
Репутация: 5181
Заслуга: c781c134843e0c1a3de9
Настоящее имя: Сергей
Откуда: Москва
Контактная информация:

Re: Github - нужнейший сервис

Сообщение Serg »

netraider писал(а):TFS полностью копирует стуктуру каталогов/файлов при создании веток.
Это его проблемы, я им никогда не пользовался.
netraider писал(а):Submodules?
Да, но гораздо естественнее и "прозрачнее".
netraider писал(а):У нас это когда-то тоже было одним из пунктов "против". Вылечилось "переосмыслением" и переносом файлов в отдельные компоненты/репозитории, и назначением прав на них.
Например "экспортные" заголовочные файлы в проекте библиотеки имеют право изменять "не только лишь все". Выносить в отдельные проекты/репозитории отдельные файлы?

Спор ни о чём. Я лишь сказал, что "не git'ом единым", что в некоторых случаях он менее удобен. А меня тут похоже пытаются убедить, что git - наше всё. Зачем это вам? :)
Я не страдаю религиозным фанатизмом и пользу то, что удобнее в каждом конкретном случае. Например в системе отслеживания изменений в конфигах маршрутизаторов/комутаторов git вообще не применим. Вернее применить-то можно, но примерно так-же как удалять гланды через задницу. Гораздо удобнее и безопаснее использовать cvs/rcs. А вот в проектах, где я единственный разработчик я чаще пользую git.
Я не Христос, рыбу не раздаю, но могу научить, как сделать удочку...
netraider
Мастер
Сообщения: 209
Зарегистрирован: 23 май 2015, 10:47
Репутация: 49
Настоящее имя: Юрий
Откуда: Москва
Контактная информация:

Re: Github - нужнейший сервис

Сообщение netraider »

UAVpilot писал(а):Например "экспортные" заголовочные файлы в проекте библиотеки имеют право изменять "не только лишь все". Выносить в отдельные проекты/репозитории отдельные файлы?
Иногда да. Для внешних клиентов. Степень "внешности" может варьироваться от отдельных команд до совершенно сторонних клиентов. Отдельно API в одном репозитории. Но это в первую очередь используется для других целей - предоставить клиентам фиксированную версию API (и возможно до реализации, т.к. иногда можно интегрироваться без нее).

Для всего остального - блокируются вообще все коммиты, но разрешаются только те, у которых было успешно проведено ревью. В ревью один или несколько обязательных ревьюеров, ответственных да компонент/библиотеку. Все это делается автоматически. При отправке кода на ревью там уже автоматом указаны те люди, которые должны его заапрувить. Более того: этот список может меняться - например при изменении некоторых конфигурационных файлов, которые имеют отношение к процессу сборки, в ревью автоматически добавляется человек из другого отдела, обслуживающего эту инфраструктуру. Дополнительный плюс в том, что это работает независимо от конкретной VCS и миграция с одной VCS на другую сильно упрощается, т.к. нет привязок на специфические фичи конкретной VCS. Мы например, года четыре неспешно мигрируем на git, и процесс это никогда не завершится, т.к. команды/отделы/проекты весьма разнородные и где-то просто не хотят/не могут сменить VCS, а кому-то это вовсе не нужно. Но описанный процесс ревью успешно работает в такой гетерогенной среде. Проблемы с невозможностью использования прав доступа к отдельным файлам при таком подходе вообще нет, она (в нашем случае) решилась другим способом. И этот способ не возник сам по себе на ровном месте, он появился в результате эволюции процесса разработки в отдельно взятой компании. Разумеется это не серебряная пуля, и рекомендовать такой подход всем вслепую я не буду.

submodules (как и идентификация версий по хешам) в прочем тоже не прижились, но по другой причине.
Спор ни о чём.
Спор? :roll:
Я хочу сказать, что процесс разработки имеет очень сильное значение. В некоторых случаях особенности конкретных инструментов могут быть блокирующими факторами, которые сразу заставляют от них отказаться. В других - они не являются существенными. И разумеется в некоторых случаях использование конкретных инструментов может быть вообще нецелесообразным.
--
At the nanometer level, the world is made of rubber (с)
Ответить

Вернуться в «Прочие вопросы Windows»