Re: Github - нужнейший сервис
Добавлено: 05 мар 2019, 17:40
Одна из самых замечательных возможностей 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), можно выбирать какие именно части одного файла попадают в коммит.
У меня это выглядит так (локальный 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), можно выбирать какие именно части одного файла попадают в коммит.