Как стать автором
Обновить

Комментарии 18

У нас был Bitbucket настроен так, что ты не мог просто так пушить в мастер и в девелоп. Только через проверку кода (code review) в веб-интерфейсе Bitbucket и слияние, тоже через веб интерфейс Bitbucket.
НЛО прилетело и опубликовало эту надпись здесь

там на Bitbucket такое на платном или на бесплатном тарифе? на github и gitlab тоже такое есть, но на платных тарифах.

Из GitHub docs - Protected branches are available in public repositories with GitHub Free and GitHub Free for organizations, На бесплатном для public.

@lxsmkv, ревью можно и в офлайне, в редакторе кода ` gh pr ---help `

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

Это первая статья про гит за все время, что я сижу на Хабре, которую не заминусовали.

У нас с друзьями есть традиция, каждый год 31 декабря пишем статью "Гит для начинающих"

Штука юмора ,???

Yet Another Git Introduction

Если вы живёте без таск-трекера - я иду к вам :)) Коммит мегаудобно начинать с идентификатора задачи из Jira / YT / RM, потом через пробел - описание, какую новую функциональность он добавляет, либо что лечит. Причём тут не нужно экономить строки - чем полнее, тем лучше, причём по возможности с точки зрения бизнеса. Дата и время попадают в коммит автоматически, вместе с автором, а если в таск-трекере настроены разные проекты на багфикс и разработку - то вам и тэг типа работы не нужен. Мы вот потом по нашим commit message почти автоматически release notes собираем. А IDEA вообще настроена на подсветку всех номеров веток в коммитах как гиперссылок, по которым сразу открывается описание задачи в YT со всей историей его изменений, комментирования и т.п.

Ух ты, очень интересно! Спасибо, что поделились опытом! Особенно интересно про подсветку веток с гиперссылками. Не подскажете, как такое реализовать?

Как мне кажется, для начинающих все же будет вернее и лучше использовать github и просто установить github Desktop и не мучиться вбивая все вручную в консоль. Лично я долгое время считал что гит это исключительно командная строка, враждебная к не-программистам, поскольку все без исключения статьи про гит освещают именно этот способ пользования, отчего не мог им пользоваться.

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

графические клиенты вообще не имеют ничего общего с командной строкой. названия даже могут быть разные в зависимости от клиента к клиенту. ну и визуализация интерфейса помогает куда больше чем черная командная строка… самый ближайший пример — не нужно запоминать все опции — они включаются галочками в интерфейсе. пойди запомни все эти -f -c -h -k модификаторы и что после них нужно писать. просто ад…

В каждой статье про Git должен быть абзац про cherry-pick! :))

Наверное, потому что эта команда очень интересная :) Я думал написать про неё, но за все время моей работы, мне ни разу не пришлось её использовать. И я решил, что в таком случае эта команда может оказаться лишней для людей, которые с Git раньше не работали.

Почему каждая статья про гит — это скупое введение, а потом сразу голая консоль и заучивание команд. 21й век GUI, а гит и ныне там. Ни одну команду не помню (чуть утрирую), все делает либо IDE из коробки либо внешние клиенты.
P.S. Ну тут мне нечем гордиться, просто я к тому, что ИМХО для новичков — начинать стоит с теории «как это работает» и далее чего попроще, а не черный экран с командной строкой (который для многих очень даже в новинку), плюс тупое заучивание весьма странных и запутанных команд… которые можно заменить 2мя ну максимум тремя кликами по интерфейсу.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории