1. Код — собственность компании. В интересах компании сделать программистов взаимозаменяемыми. Отсюда и общее владение кодом, когда любой может залезть и исправить любой кусок и стайлгайд. Компания решила применять стайлгайд — придется следовать. Тут нет месту холиварам.
2. Многие программисты немного аутисты. Они чувствуют себя лучше когда строго следуют определенному набору правил. И наоборот, если что-то не так, настроение у них портится сильно больше, чем того заслуживает неправильный отступ или перенос.
Марк из статьи похоже был конктетным аутистом. Но в коллективе из аутистов любые правила, лучше их отсутствия.
Действительно сложно объяснить зачем кому-то нужна чистая история.
squash — нужен действительно только тогда, когда первоначальная реализация фичи была не совсем верная. Нет никаких доводов против мерджа как есть фичи сделанной за несколько коммитов, каждый из которых осмысленный и не ломал тесты(ну вы же делаете push каждый раз после коммита, да?)
rebase поверх — для того чтоб CI отработал на той версии кода которая получится после merge в основную ветку.
Все. squash'им только ненужные коммиты, а ребейсим и прогоняем CI чтоб держать общую ветку в рабочем состоянии. А чистая история это побочный продукт, а не самоцель.
Огромное количество комерческого серверного софта имеет открытую урезанную версию под AGPL.
С одной стороны, это привлекает новых пользователей, которые вот прям сразу могут взять и начать пользоваться. Можно, например, взять и развернуть AGPL CRM для бизнеса внутри компании, и даже менять ее, не предоставляя исходники сообществу.
C другой стороны, сторонняя компания, не может внезапно взять свободный код, допилить фичи из коммерческой версии и начать ими торговать. Или например нельзя развернуть модифицированное облачное решение, исходники придется предоставлять каждому внешнему клиенту.
Так, что фреймворк или движок какой вполне может быть залицензирован под AGPL.
1. Код — собственность компании. В интересах компании сделать программистов взаимозаменяемыми. Отсюда и общее владение кодом, когда любой может залезть и исправить любой кусок и стайлгайд. Компания решила применять стайлгайд — придется следовать. Тут нет месту холиварам.
2. Многие программисты немного аутисты. Они чувствуют себя лучше когда строго следуют определенному набору правил. И наоборот, если что-то не так, настроение у них портится сильно больше, чем того заслуживает неправильный отступ или перенос.
Марк из статьи похоже был конктетным аутистом. Но в коллективе из аутистов любые правила, лучше их отсутствия.
MVC мертв, ага.
Один из стандартных советов по борьбе с прокрастинацией — попрубуйте 5 минут ничего не делать. Вообще ничего.
А то иногда такого можно понаворотить, чтоб если что можно было одну строчку править, вместо двух.
squash — нужен действительно только тогда, когда первоначальная реализация фичи была не совсем верная. Нет никаких доводов против мерджа как есть фичи сделанной за несколько коммитов, каждый из которых осмысленный и не ломал тесты(ну вы же делаете push каждый раз после коммита, да?)
rebase поверх — для того чтоб CI отработал на той версии кода которая получится после merge в основную ветку.
Все. squash'им только ненужные коммиты, а ребейсим и прогоняем CI чтоб держать общую ветку в рабочем состоянии. А чистая история это побочный продукт, а не самоцель.
И вот подробное объяснение почему — http://www.infoq.com/presentations/Development-at-Google
Может надо аккуратней адрес вводить? Там явно КЛАДР и ФИАС используются.
С одной стороны, это привлекает новых пользователей, которые вот прям сразу могут взять и начать пользоваться. Можно, например, взять и развернуть AGPL CRM для бизнеса внутри компании, и даже менять ее, не предоставляя исходники сообществу.
C другой стороны, сторонняя компания, не может внезапно взять свободный код, допилить фичи из коммерческой версии и начать ими торговать. Или например нельзя развернуть модифицированное облачное решение, исходники придется предоставлять каждому внешнему клиенту.
Так, что фреймворк или движок какой вполне может быть залицензирован под AGPL.