Комментарии 22
Невозможно читать из-за тупых мемов. Порой на экране сразу две картинки. И по смыслу не в тему совершенно.
Спасибо за ссылки в конце статьи, нашел для себя пару интересных.
Вы описали "Git flow" который сейчас вообще уже не используется, по причине сложности и ориентации на водопадную разработку. Статью по книжке писали? Больше пользы было бы от описания "GitLab flow", или "GitHub flow".
Хорошо работать всегда сложно. У меня вот сейчас все по модному аджайл льют в мастер, ток вот в релиз должны уйти не все сделаные задачи.
Гит флоу нормально ложиться на все эти модные говно аджайлы и спринты. Просто кто-то не умеет работать.
Тем более, что даже Atlassian признаёт gitflow устаревшим:
Gitflow is a legacy Git workflow that was originally a disruptive and novel strategy for managing Git branches.
Спасибо за отличную статью!
"Исправляет ошибки и форматирует" -- КТО исправляет и КТО редактирует? Или ЧТО? Не измывайтейсь над русским языком. Сообщение коммита - это как заголовок в книге, он должен описывать что содержится внутри (главы книги). А это какая-то пьеса с чтением по ролям. Или скорее, плохое школьное сочинение.
Кто? Коммит исправляет ошибки и форматирует. Это пошло ещё от английской версии, где, правда, коммит-месседжи писались в повелительном наклонении (или в инфинитиве, но без частицы to). Можно заметить по автоматическому сообщению про мердж: merge X into Y (не "merged", не "will merge", не "a/the merge" и уж точно не "merging").
Как я понимаю, смысл тут такой: "этот коммит сделает то-то, если его применить" - просто добавляешь в начале "will" и готово. Imperative mood тут тоже работает: на Гитхабе можно сначала написать issue с названием типа "use LibraryA instead of LibraryB", обсудить в нём плюсы и минусы, а потом сделать пулл реквест с дословно таким же названием.
Как адаптировать такое соглашение для русского языка? Можно писать "добавить XYZ" - это ок, но не самый короткий вариант. "Добавь XYZ" - смотрится странно и чуть невежливо. "Добавил XYZ" - глаз не мозолит, но здесь подразумевается актор "Я" (я добавил), а зачем он здесь, если мы говорим только про код и коммиты? "Добавит XYZ" - на один символ длиннее чем повелительное наклонение, но не такое странное. "Добавлено XYZ" - мне нравится больше всего, но это самый длинный вариант (я не думаю, что стоит так сильно заморачиваться краткостью в 2024 году, но тут автор выше пишет про 72/79 символов, так что наверное для кого-то это всё ещё важно).
Является ли "добавит XYZ" самым уместным вариантом для русского языка? Не знаю, но в целом этот стиль мне смотрится адекватным и продуманным. Я бы не назвал его насилием над русским языком.
Отличная статья для начинающих! Самая важная рекомендация - как давать правильные имена. Начинающие на это сначала вообще не обращают внимание, а тут хорошо описано.
Дополнение: полезно в начале проекта, над которым работает несколько человек, и регулярнр добавляются новые участники, добавить файл README, в котором перечислены основные правила ведения веток и пул-реквестов. А также имена участников проекта и кто каким направлением (набором задач) занимается.
Следует правда учесть, что пулл реквесты это не git
Крутая статья, некоторые новые вещи подчеркнул для себя. Особенно лайк за мемы (даже себе сохранил!) и множество ссылок на ресурсы
main(ранееmaster)
Шли годы, а свежеустановленный git так и продолжает рассказывать нам о том, что название главной ветки master is a subject to change.
У меня у одного такое впечатление, что "не опять, а снова" инструмент, задуманный для облегчения жизни, некоторые супер умники усложнили настолько, что он теперь сам усложняет жизнь разрабам? У меня всегда только 2 ветки, дев и мейн, а коммиты я вообще часто без сообщений делаю. И ничего, до сих пор жив.
У тебя - две ветки норм. А у вас?
Или понятие "командная работа" хотя бы в команде из 10-ти человек для вас невозможная ситуация? А из 100?
Не работал в таких проектах. Но уверен, что и с большими командами можно ограничиться не зоопарком веток, а 2-3. Не считая различных хотфиксов.
Невозможно.
Каждый разработчик свою фичу пилит в своей фича ветке. Или как минимум одна ветка на тикет в джире.
А если у разработчика две фичи, то две фича-ветки.
И мержит они их уже тогда, когда фича полностью закончена.
А разработчиков десятки.
А релизы могут пилиться паралельно - пока один готовится в продакшен, и он еще тестируется и активно патчится, второй уже пошел в разработку.
Тут без множества веток не обойтись, а если веток множества, то без четкого воркфлоу будет просто хаос.
Как же прекрасно желание аффтара разбавить статью шутейками с картинками...
Отличная статья для тех то начинает знакомиться с GIT разработкой, но я бы еще дополнил ее описанием работой с различными PSR Стандартами. Все таки их использование значительно упрощает совместную разработку, так как читать код становится проще и количество Merge конфликтов также снижается.
Здесь как во многих других статьях есть подмена понятий, разработка не ведётся ветках, она ведётся на серверах. И если вы будете разрабатывать в какой-то ветке которую вы включите на боевом сервере то на нём также будет жопа.
А это уже вопрос к конкретному типу работы, есть например веб-студии, в которых сотрудники переключается между двадцатью+ проектами, в день может могут быть задачи по трём четырём пяти разным сайтом, держать все эти проекты у себя локально бывает невозможно.
В в таком случае работа с гитом будет совершенно другой
@JuliaVolkova, большое спасибо за статью и ссылки в конце! Нашел для себя интересные моменты.
FYI. В одной ссылке указан неверный url:
Git — инструмент для совместной работы, с нуля и до регламента в команде — доклад Школы разработки интерфейсов Яндекса.
Мегагайд: культура работы с Git