Pull to refresh
4
0
Send message
Похоже на то как оценивать полезность/вредность участников соревнований по скоростной или меткой стрельбе в составе группы войск, которая ведёт длительные боевые действия в горячей точке. Полезны ли их навыки меткой и быстрой стрельбы? Да, полезны, но насколько? Насколько они полезнее умения не попасть в засаду или окружение, например? Всё зависит от задач, которые ставит жизнь.
Согласен, инфраструктура разработки — широкое понятие, и система контроля версий — только её часть.
Интересно было бы почитать про орг. меры, направленные на соблюдение всех этих «кодинг гайдлайнов», требований к коммитам и т.п в группе разработчиков размером под 10 человек и более. Очень не хватает реального практического опыта, а не теоретизирования на тему.

По моему горькому опыту примерно лишь половина разработчиков из команды понимает зачем всё это нужно, остальные в разной степени считают это необязательными пожеланиями и относятся соответственно. При попытках объяснить натыкаешься на позицию «вот понапридумывали всякого барахла, главное чтобы код работал!». Может и правда всё это лишняя шелуха?
Ещё полезная опция

[Service]
Type=notify

Позволяет в вашем приложении-сервисе сделать начальную инициализацию, которая необходима перед продолжением загрузки системы, а потом вызвать из сервиса
sd_notify(0, "READY=1");

и загрузка пойдёт дальше вместе с вашим работающим сервисом.
Важно у кого этот коэффициент ошибки окажется меньше в итоге.
«Охотнику не обязательно бегать быстрее гепарда, чтобы убежать от него. Главное бегать быстрее своего напарника».
В среднесрочной перспективе подобная автоматизация повзолит устранить человеческий фактор не только в производственном процессе (на уровне примитивных физических операций), но и в сфере социального взаимодейсвия, устраняя из неё прослойку «недалёких» умом людей.
«С тех пор, все виды людей — от больших и малых компаний до людей на Kickstarter'е...»
Мощный пассаж.
У нас: на словах — Scrum, Kanban; на деле — через %опу.
Править локальную историю придётся из-за досадного изменения по невнимательности уже опубликованного коммита. Решение, которое я предложил направлено на пресечение подобного ошибочного коммита по невнимательности, ещё на этапе его совершения, а не спустя уже какое-то количество времени (и коммитов).
Ещё бы научились целеуказание считывать со зрачков оператора.
Думаю, что многое зависит от постановки рабочего процесса с Git, который заведён в компании (в отделе/в сообществе). Где-то сотрудники заводят свои локальные ветки, которые сами и мержат в итоге; где-то заводят свои удалённые ветки и пушат туда (доступ к master-ветке ограничен), периодически обновляя их при помощи rebase из master-ветки (чтобы не создавать merge-коммиты).
Данный хук может пригодиться в похожем случае, когда программисты работают со своими удалёнными ветками, в которые некоторые (не особо опытные) сотрудники иногда выполняют push -f =)
Да, и в таком случае придётся править историю коммитов в своей локальной ветке, чтобы разрешить проблему. Лично мне хотелось бы до этого не доводить.
2

Information

Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Registered
Activity