Привет! Я думаю тут вопрос больше должен ставиться так: подразумевает ли твой пет проект дальнейшее использование совместно с кем-то. Ведь Git берет свое начало именно с этого) Но думаю не будет лишним делать через Git, как минимум для возможности отката до определенного состояния своего изначального кода или экспериментов или тестов в другой ветке, плюс используя удаленные репозитории ты можешь значительно облегчить себе жизнь, если тебе надо быстро перенести свои наработки на другую машину.
«Итерационно-модульное программирование» - это же, по сути, и есть то, что Git формализует: итерации = коммиты, модули = ветки. Только Git ещё и запоминает каждый шаг
Рекомендую все-таки изучить такой инструмент как Git(кстати придумал его гениальный человек), там найдешь много интересного, например git revert. Удачи
Сергей, благодарю за статью! Оставлю немного своих мыслей на подумать:
standard-version как инструмент устарел, рекомендую что-нибудь поновее, например release-please
Когда вы говорите про rebase на main, стоит упомянуть, что далее всегда нужен force push, иначе будет ошибка. Новичкам рекомендую git push --force-with-lease либо делать это через IDE
При первом пуше лучше привязывать локальную ветку к удалённой через git push -u. IDE делают это под капотом, но раз в статье всё руками — стоит показать
Модель Git Flow подана сжато — лучше почитать про неё отдельно (например тут)
В энтерпрайзе 50 символов для заголовка часто мало. Обычно формат такой: feat(ABC-123): описание из задачи — это упрощает поиск старых правок и сборку карт влияния
Ещё хотелось бы добавить: пишите footer в коммитах. Вам не сложно, а лиду приятно, особенно в аварийных ситуациях. Формат: Refs: #42 (ссылка на задачу) или Closes #42 (автоматическое закрытие issue)
Всем удобочитаемых комментариев и аккуратно оформленных ПР(или МР - как хотите=) )!
Привет!
Я думаю тут вопрос больше должен ставиться так: подразумевает ли твой пет проект дальнейшее использование совместно с кем-то. Ведь Git берет свое начало именно с этого)
Но думаю не будет лишним делать через Git, как минимум для возможности отката до определенного состояния своего изначального кода или экспериментов или тестов в другой ветке, плюс используя удаленные репозитории ты можешь значительно облегчить себе жизнь, если тебе надо быстро перенести свои наработки на другую машину.
«Итерационно-модульное программирование» - это же, по сути, и есть то, что Git формализует: итерации = коммиты, модули = ветки. Только Git ещё и запоминает каждый шаг
Рекомендую все-таки изучить такой инструмент как Git(кстати придумал его гениальный человек), там найдешь много интересного, например git revert.
Удачи
Сергей, благодарю за статью! Оставлю немного своих мыслей на подумать:
standard-version как инструмент устарел, рекомендую что-нибудь поновее, например release-please
Когда вы говорите про rebase на main, стоит упомянуть, что далее всегда нужен force push, иначе будет ошибка. Новичкам рекомендую git push --force-with-lease либо делать это через IDE
При первом пуше лучше привязывать локальную ветку к удалённой через git push -u. IDE делают это под капотом, но раз в статье всё руками — стоит показать
Модель Git Flow подана сжато — лучше почитать про неё отдельно (например тут)
В энтерпрайзе 50 символов для заголовка часто мало. Обычно формат такой: feat(ABC-123): описание из задачи — это упрощает поиск старых правок и сборку карт влияния
Ещё хотелось бы добавить: пишите footer в коммитах. Вам не сложно, а лиду приятно, особенно в аварийных ситуациях. Формат: Refs: #42 (ссылка на задачу) или Closes #42 (автоматическое закрытие issue)
Всем удобочитаемых комментариев и аккуратно оформленных ПР(или МР - как хотите=) )!