История изменений

мне кажется идея обобщить подход работы с гитовыми ветками - утопичная идея. у каждого проекта найдутся свои корнеркейсы, которые просто не вписываются в красивую картинку.

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

еще одно из мнений, которое я никогда не понимал - показушное храниние всех коммитов процесса разработки какого-то фича-бранча. еще ни разу в жизни не сталкивался с потребностью (ни у себя, ни где-то у других) заглянуть в какой-нибудь 105ый коммит какого-нибудь фичабранча.

резюмирую… с годами выработал простой подход

• мастер бранч с тегами релизов, откуда могут бранчеваться релизные бранчи если (это для саппорта внешних потребителей, кому отгрузили определенную версию и нужно саппортить его какое-то время)

• предрелизный (читай как тестовый). формируется после каждого релиза как точка отсчета для следующей разработки. по завершению она вмерживается в мастер схлапывая все коммиты в один. на нем же всякие тесты гоняются.

• остальная разработка ведется путем бранчевания от предрелизного

• если какая-то фича А зависит от фичи Б, то бранч А должен создаваться от бранча Б. если обе фичи зависят др от друга - увольняйте вашего ПМ или лида ибо кто-то из них не умеет в планирование.

• каждый разраб работает в клоне и бранчуется локально от фича-бранча. коммиты ведет ровно так, как ему хочется (хоть каждую букву коммитит). но пул-реквест должен быть одним коммитом с нормальным описанием.

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

мне кажется идея обобщить подход работы с гитовыми ветками - утопичная идея. у каждого проекта найдутся свои корнеркейсы, которые просто не вписываются в красивую картинку.

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

еще одно из мнений, которое я никогда не понимал - показушное храниние всех коммитов процесса разработки какого-то фича-бранча. еще ни разу в жизни не сталкивался с потребностью (ни у себя, ни где-то у других) заглянуть в какой-нибудь 105ый коммит какого-нибудь фичабранча.

резюмирую… с годами выработал простой подход

• мастер бранч с тегами релизов, откуда могут бранчеваться релизные бранчи если (это для саппорта внешних потребителей, кому отгрузили определенную версию и нужно саппортить его какое-то время)

• предрелизный (читай как тестовый). формируется после каждого релиза как точка отсчета для следующей разработки. по завершению она вмерживается в мастер схлапывая все коммиты в один

• остальная разработка ведется путем бранчевания от предрелизного

• если какая-то фича А зависит от фичи Б, то бранч А должен создаваться от бранча Б. если обе фичи зависят др от друга - увольняйте вашего ПМ или лида ибо кто-то из них не умеет в планирование.

• каждый разраб работает в клоне и бранчуется локально от фича-бранча. коммиты ведет ровно так, как ему хочется (хоть каждую букву коммитит). но пул-реквест должен быть одним коммитом с нормальным описанием.

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

мне кажется идея обобщить подход работы с гитовыми ветками - утопичная идея. у каждого проекта найдутся свои корнеркейсы, которые просто не вписываются в красивую картинку.

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

еще одно из мнений, которое я никогда не понимал - показушное храниние всех коммитов процесса разработки какого-то фича-бранча. еще ни разу в жизни не сталкивался с потребностью (ни у себя, ни где-то у других) заглянуть в какой-нибудь 105ый коммит какого-нибудь фичабранча.

резюмирую… с годами выработал простой подход

• мастер бранч с тегами релизов, откуда могут бранчеваться релизные бранчи если (это для саппорта внешних потребителей, кому отгрузили определенную версию и нужно саппортить его какое-то время)

• предрелизный (читай как тестовый). формируется после каждого релиза как точка отсчета для следующей разработки. по завершению она вмерживается в мастер схлапывая все коммиты в один

• остальная разработка ведется от бранчевания от предрелизного

• если какая-то фича А зависит от фичи Б, то бранч А должен создаваться от бранча Б. если обе фичи зависят др от друга - увольняйте вашего ПМ или лида ибо кто-то из них не умеет в планирование.

• каждый разраб работает в клоне и бранчуется локально от фича-бранча. коммиты ведет ровно так, как ему хочется (хоть каждую букву коммитит). но пул-реквест должен быть одним коммитом с нормальным описанием.

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

мне кажется идея обобщить подход работы с гитовыми ветками - утопичная идея. у каждого проекта найдутся свои корнеркейсы, которые просто не вписываются в красивую картинку.

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

еще одно из мнений, которое я никогда не понимал - показушное храниние всех коммитов процесса разработки какого-то фича-бранча. еще ни разу в жизни не сталкивался с потребностью (ни у себя, ни где-то у других) заглянуть в какой-нибудь 105ый коммит.

резюмирую… с годами выработал простой подход

• мастер бранч с тегами релизов, откуда могут бранчеваться релизные бранчи если (это для саппорта внешних потребителей, кому отгрузили определенную версию и нужно саппортить его какое-то время)

• предрелизный (читай как тестовый). формируется после каждого релиза как точка отсчета для следующей разработки. по завершению она вмерживается в мастер схлапывая все коммиты в один

• остальная разработка ведется от бранчевания от предрелизного

• если какая-то фича А зависит от фичи Б, то бранч А должен создаваться от бранча Б. если обе фичи зависят др от друга - увольняйте вашего ПМ или лида ибо кто-то из них не умеет в планирование.

• каждый разраб работает в клоне и бранчуется локально от фича-бранча. коммиты ведет ровно так, как ему хочется (хоть каждую букву коммитит). но пул-реквест должен быть одним коммитом с нормальным описанием.

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

мне кажется идея обобщить подход работы с гитовыми ветками - утопичная идея. у каждого проекта найдутся свои корнеркейсы, которые просто не вписываются в красивую картинку.

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

еще одно из мнений, которое я никогда не понимал - показушное храниние всех коммитов процесса разработки какого-то фича-бранча. еще ни разу в жизни не сталкивался с потребностью (ни у себя, ни где-то у других) заглянуть в какой-нибудь 105ый коммит.

резюмирую… с годами выработал простой подход

• мастер бранч с тегами релизов, откуда могут бранчеваться релизные бранчи если (это для саппорта внешних потребителей, кому отгрузили определенную версию и нужно саппортить его какое-то время)

• предрелизный (читай как тестовый). формируется после каждого релиза как точка отсчета для следующей разработки. по завершению она вмерживается в мастер схлапывая все коммиты в один

• остальная разработка ведется от бранчевания от предрелизного

• если какая-то фича А зависит от фичи Б, то бранч А должен создаваться от бранча Б. если обе фичи зависят др от друга - увольняйте вашего ПМ или лида ибо кто-то из них не умеет в планирование.

• каждый разраб работает в клоне и бранчуется локально от фича-бранча. коммиты ведет ровно так, как ему хочется (хоть каждую букву коммитит). но пул-реквест должен быть одним коммитом с нормальным описанием.

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