Думаю это целая тема для обсуждения, вот мои соображения, которые являются результатом многократных споров и обсуждений с моими коллегами.
Для коммитов на русском языке просто следовать этому правилу: "Используйте повелительное наклонение", будет не благозвучно и думаю не правильно с точки зрения русского языка, тут говорится: "Use the imperative mood in the subject line" и поясняется, что заголовок должен быть продолжением фразы: "If applied, this commit will your subject line here", пример:
If applied, this commit will update getting started documentation
В случае применения этого коммита будет обновлено руководство по началу работы
Без начала предложения т.е. без глагола will в английском языке получается imperative mood:
update getting started documentation
обновить руководство по началу работы
а в русском языке, если не ошибаюсь, это инфинитив:
обновить руководство по началу работы
обновить конфигурацию commitizen
добавить хук забытый в прошло коммите
обновите руководство по началу работы
обновите конфигурацию commitizen
добавьте хук забытый в прошло коммите
Если следовать трюку с продолжением фразы, то данное правило можно свести до:
Заголовок комментария должен формулироваться, как продолжение фразы: В случае применения этого коммита будет...
В таком случае комментарии получаю такой вид:
обновлено руководство по началу работы
обновлена конфигурация commitizen
добавлен хук забытый в прошло коммите
исправлена ошибка…
добавлена возможность…
улучшена возможность...
Я далеко не эксперт в русском и тем более в английском, но определенно такой подход более логичный во всех смыслах история лаконично читается и на ее основе можно генерировать список изменений.
Мне будут очень интересны другие мнения на эту тему.
Аннотации или git blame это отдельная история в теории за его формирование отвечает правила по оформлению кода и текущие конвенции не решают этот вопрос полностью, в общем это отдельная тема.
Номер таска в комментарии полезен но не всегда, название бага и описание нежелательного поведения формирует тестировщик, а разработчик для решения может изменить совсем не связанный с описанием компонент или компоненты.
Поэтому в политику формирования истории полезно добавлять правило: фиксировать изменения разных компонентов отдельно, отдельно фиксировать рефакторинг отдельно фиксировать решение, если ему предшествует рефакторинг и дополняя конвенцией по формированию комментария получаем полезную историю.
Но это не решает вопроса аннотации тут нужен опыт, дополнительная конвенция или правила по оформлению кода которые это учитывают.
1. Перед каждым Pull Request-ом разработчик заполняет в файле ReleaseNotes.md
Это один файл на проект? Учитывая конвенцию и генерацию коммитов что мешает это файл формировать автоматически?
2. Выбрали классический git-flow (хотя сам я сторонник другого ветвления)
Другого ветвления, это какого?
Учитывая Ваш опыт применения git-flow, представите, что будет с историей, если каждый разработчик будет синхронизировать свою рабочую ветку не слиянием с develop, а через перемещение git pull --rebase origin develop?
Мой опыт говорит обратное, если вести историю по правилам, то как минимум можно воспользоватся git changelog, дает вполне адекватный материал, который можно обработать в ручном или полу-автоматическом режиме. Например применить агрегацию и фильтрацию на основе типов. Мы это делаем руками, надеюсь есть инструмент о котором я еще не знаю.
Отличный материал, спасибо! Есть вопросы:
1. Список изменений (changelog.md) генерируете на основе истории или нет (есть мнение, что это не лучший способ), какой подход у вас к созданию и поддержке истории изменений?
2. Применяете git-flow или свой поход? Расскажите подробнее.
3. Интересно как относитесь к линейной истории это полезно или нет? Мое мнение, что линейная или частично линейная история дает массу профитов и даже применяя git-flow история может быть линейная, если приложить немного усилий, но мало кто видит в этом преимущества, давно хочу понять почему. На текущий момент гипотиреоза в том, что мало кто использует историю как инструмент анализа или может быть есть иной способ сохранить блейм или анализировать историю в незавидности от ее линейности.
Могу отметить, что в текущей версии с типографикой все просто отлично т.е. есть «тире», а не «минус», приятно слушать (в моей книжке нет настроек TTS).
Как пасти котов. Наставление для программистов, руководящих другими про-
граммистами. — СПб.: Питер, 2016. — 256 с.: ил. — (Серия «Библиотека про-
граммиста»).
ISBN 978-5-496-01820-3
ISBN 1590590171 англ.
978-5-496-01820-3
Встречал издания 2006 чем оно отличается от издания 2016 не понятно, обычно когда преиздают пишут: «Второе издание», в данном случае этого нет.
Читаю, хорошее изложение материала, рекомендую к прочтению начинающим лидам.
На сайте издательства есть ошибка, написано, что книга 2018 года, на самом деле 2016.
Есть сравнение на английском PHP Profiler — Z-Ray, Blackfire, Tideways, кратко вывод: победила дружба, выбирайте инструмент исходя из своих потребностей и предпочтений.
Представил, «вот эта сборка» сложной не будет, но могу согласится с тем что такое возможно, пока не сталкивался, предвкушая возможные осложнения, посматриваю в сторону соответствующих инструментов.
Спасибо за ссылку, она несомненно пригодится. Без спорно инструменты chef, ansible, puppet и п. р. имеют свои плюсы, но без наличия в команде соответствующего специалиста, применять их будет сложно.
Описанный мной подход, без каких либо ноу-хау, прекрасно решает задачу консистентного программного окружения и позволяет легко воспользоваться его возможностями.
С тем же успехом можно просто запустить vagrant init ubuntu/trusty
Если выполнить несколько не сложных действий описанных в комментарии выше станет очевидно что это готовая к работе виртуальная машина, на которой настроено (из описания проекта ilyar.github.io/localserver/):
Ubuntu 14.04 LTS 32-bit (for use 64-bit set VM_ARCH=64)
Еще раз на примере реального проекта на Yii, для того что бы разработчику получить локально действующий проект, достаточно выполнить:
$ git clone https://github.com/ilyar/imotlib.git
$ cd imotlib
$ vagrant up
$ open http://imotlib.local/
В результате имеем настроенное рабочее окружение и проинициализированный проект, разработчику останется только писать код. При необходимости он может поправить настройку ВМ и для этого не потребуется изучать что то дополнительно, потому что все в одном месте с использованием родного bash.
Под областью видимости, в данном случае, я имею ввиду, что конфигурация виртуальной машины реализована одним файлом (подробнее ilyar.github.io/localserver/), конечный результат почти аналогичен описываемому в статье.
Когда решал подобный вопрос, мне не давало покоя необходимость изучать дополнительный инструмент (несомненно полезный), необходимость поддерживать актуальное стояние Chef-конфига и держать целую структуру и только для того что бы поднять локальную ВМ. Особенно убивало то, что проверенный конфиг не всегда отрабатывал и приходилось фиксить. Предположу, что вопрос актуальности Chef-конфига на текущий момент может решить пакетный менеджер для Chef (librarian, berkshelf или что там сейчас в апстриме...).
В результате остановился на provision с помощью shell-скриптов, это позволило решить задачу одним файлом Vagrantfile, ничего особенного, но может быть, будет полезно не только мне.
Я понимаю полезность использования Chef и подобных ему инструментов, по возможности изучаю данную тему на предмет повседневного использования. Хочется получить ответы от пользователей Chef на вопросы:
Возможно описать настройку Vagrant одним файлом используя Chef?
Какую методику можно переменить что бы быть уверенным в том что Chef-кофиг не протухнет будет актуальным?
Есть успешный и комфортный опыт использования Chef для развертывания, как рабочего окружения так и локального на Vagrant?
Думаю это целая тема для обсуждения, вот мои соображения, которые являются результатом многократных споров и обсуждений с моими коллегами.
Для коммитов на русском языке просто следовать этому правилу: "Используйте повелительное наклонение", будет не благозвучно и думаю не правильно с точки зрения русского языка, тут говорится: "Use the imperative mood in the subject line" и поясняется, что заголовок должен быть продолжением фразы: "If applied, this commit will your subject line here", пример:
Без начала предложения т.е. без глагола
willв английском языке получаетсяimperative mood:а в русском языке, если не ошибаюсь, это инфинитив:
а повелительное наклонение образуется иначе:
Если следовать трюку с продолжением фразы, то данное правило можно свести до:
В таком случае комментарии получаю такой вид:
Я далеко не эксперт в русском и тем более в английском, но определенно такой подход более логичный во всех смыслах история лаконично читается и на ее основе можно генерировать список изменений.
Мне будут очень интересны другие мнения на эту тему.
git blameэто отдельная история в теории за его формирование отвечает правила по оформлению кода и текущие конвенции не решают этот вопрос полностью, в общем это отдельная тема.Номер таска в комментарии полезен но не всегда, название бага и описание нежелательного поведения формирует тестировщик, а разработчик для решения может изменить совсем не связанный с описанием компонент или компоненты.
Поэтому в политику формирования истории полезно добавлять правило: фиксировать изменения разных компонентов отдельно, отдельно фиксировать рефакторинг отдельно фиксировать решение, если ему предшествует рефакторинг и дополняя конвенцией по формированию комментария получаем полезную историю.
Но это не решает вопроса аннотации тут нужен опыт, дополнительная конвенция или правила по оформлению кода которые это учитывают.
Это один файл на проект? Учитывая конвенцию и генерацию коммитов что мешает это файл формировать автоматически?
Другого ветвления, это какого?
Учитывая Ваш опыт применения git-flow, представите, что будет с историей, если каждый разработчик будет синхронизировать свою рабочую ветку не слиянием с develop, а через перемещение
git pull --rebase origin develop?1. Список изменений (changelog.md) генерируете на основе истории или нет (есть мнение, что это не лучший способ), какой подход у вас к созданию и поддержке истории изменений?
2. Применяете git-flow или свой поход? Расскажите подробнее.
3. Интересно как относитесь к линейной истории это полезно или нет? Мое мнение, что линейная или частично линейная история дает массу профитов и даже применяя git-flow история может быть линейная, если приложить немного усилий, но мало кто видит в этом преимущества, давно хочу понять почему. На текущий момент гипотиреоза в том, что мало кто использует историю как инструмент анализа или может быть есть иной способ сохранить блейм или анализировать историю в незавидности от ее линейности.
Встречал издания 2006 чем оно отличается от издания 2016 не понятно, обычно когда преиздают пишут: «Второе издание», в данном случае этого нет.
На сайте издательства есть ошибка, написано, что книга 2018 года, на самом деле 2016.
Сюда подходит термин Уровень переопределения из БЭМ методологии.
Применяя BEMHTML можно сократить:
Демонстрация bem-core + BEMHTML jsfiddle.net/ilyar/x1bfu5zh
Описанный мной подход, без каких либо ноу-хау, прекрасно решает задачу консистентного программного окружения и позволяет легко воспользоваться его возможностями.
Если выполнить несколько не сложных действий описанных в комментарии выше станет очевидно что это готовая к работе виртуальная машина, на которой настроено (из описания проекта ilyar.github.io/localserver/):
VM_ARCH=64)Еще раз на примере реального проекта на Yii, для того что бы разработчику получить локально действующий проект, достаточно выполнить:
В результате имеем настроенное рабочее окружение и проинициализированный проект, разработчику останется только писать код. При необходимости он может поправить настройку ВМ и для этого не потребуется изучать что то дополнительно, потому что все в одном месте с использованием родного bash.
Под областью видимости, в данном случае, я имею ввиду, что конфигурация виртуальной машины реализована одним файлом (подробнее ilyar.github.io/localserver/), конечный результат почти аналогичен описываемому в статье.
Минимальная область видимости, просто изменять, стабильный результат.
Когда решал подобный вопрос, мне не давало покоя необходимость изучать дополнительный инструмент (несомненно полезный), необходимость поддерживать актуальное стояние Chef-конфига и держать целую структуру и только для того что бы поднять локальную ВМ. Особенно убивало то, что проверенный конфиг не всегда отрабатывал и приходилось фиксить. Предположу, что вопрос актуальности Chef-конфига на текущий момент может решить пакетный менеджер для Chef (librarian, berkshelf или что там сейчас в апстриме...).
В результате остановился на provision с помощью shell-скриптов, это позволило решить задачу одним файлом Vagrantfile, ничего особенного, но может быть, будет полезно не только мне.
Я понимаю полезность использования Chef и подобных ему инструментов, по возможности изучаю данную тему на предмет повседневного использования. Хочется получить ответы от пользователей Chef на вопросы:
не протухнетбудет актуальным?