Здравствуйте, _NN_, Вы писали:

C>>Так ведь rebase и не меняет историю основной (master) ветки. Тем более, если для сервера стоит only fast-forward.
_NN>Для мастера додумались делать защищённую ветку по умолчанию.

В смысле? Там нет особой обработки именно для master. Или о чём речь?

_NN>Только это функция сервера, а не клиента.

C>>А недельный труд всё равно остаётся в reflog.
_NN>Да, но всё равно неприятно. К тому же не все это знают

Ну вот последнее и есть результат широко распространённых ламерских инструкций типа "освой за 5 минут".
А "неприятно" это следствие ошибочных действий до того, а не свойство самого средства восстановления.

Здравствуйте, Hobbes, Вы писали:

НС>>Ни разу не делал черрипик при выпуске хотфиксов?

H>Нет, не делал. Ветка с релизом и фиксами мерджится в мастер. Либо ветка с отдельным хотфиксом мерджится в мастер и ветку релиза.

А на каком коммите будет у вас основана эта "ветка с отдельным хотфиксом"?
Если master, v1 и v2 каждый получил свои специфические изменения, а хотфикс универсален для них (неизменная или мало изменившаяся часть кода), то вы не найдёте такого общего базового коммита, и мерж превратится в ад.
А вот черипик для таких условий — идеален.

Здравствуйте, Clerk, Вы писали:

C>Вроде можно и на клиенте:
C>git config --global merge.ff only

Наколько я понимаю это указывает не создавать комиты слияния.
Не думаю, что это спасает от push --force

Здравствуйте, netch80, Вы писали:

C>>>Так ведь rebase и не меняет историю основной (master) ветки. Тем более, если для сервера стоит only fast-forward.
_NN>>Для мастера додумались делать защищённую ветку по умолчанию.

N>В смысле? Там нет особой обработки именно для master. Или о чём речь?
Я о защищённых ветках на сервере, которые не допустят переписывания истории.

_NN>>Только это функция сервера, а не клиента.

C>>>А недельный труд всё равно остаётся в reflog.
_NN>>Да, но всё равно неприятно. К тому же не все это знают

N>Ну вот последнее и есть результат широко распространённых ламерских инструкций типа "освой за 5 минут".
N>А "неприятно" это следствие ошибочных действий до того, а не свойство самого средства восстановления.
Как раз есть полезный сайт: https://ohshitgit.com/

Здравствуйте, _NN_, Вы писали:

C>>Вроде можно и на клиенте:
C>>git config --global merge.ff only

_NN>Наколько я понимаю это указывает не создавать комиты слияния.
_NN>Не думаю, что это спасает от push --force

По умолчанию защита от forced push, да, не включается. Если это нужно, ставится receive.denyNonFastForwards=true в центральной репе.
Хотя для команды объёмом минимум в 5 человек лучше поставить уже что-то вроде Gerrit, будет сразу peer review, интеграция с CI и прочая.
Ну и кто не в такой репе поставил core.logAllRefUpdates=always — сам себе ЗБ.

По поводу отсутствия этих настроек (а также некоторых других, типа merge.conflictStyle=diff3) в типовых инструкциях я уже высказался — они написаны ламерами для чайников. Здесь, увы, вина и на авторах Git — снобизм не позволил вникнуть в нужды простых пользователей, когда их счёт пошёл на миллионы.

Здравствуйте, _NN_, Вы писали:

C>>>>Так ведь rebase и не меняет историю основной (master) ветки. Тем более, если для сервера стоит only fast-forward.
_NN>>>Для мастера додумались делать защищённую ветку по умолчанию.

N>>В смысле? Там нет особой обработки именно для master. Или о чём речь?
_NN>Я о защищённых ветках на сервере, которые не допустят переписывания истории.

Это я понял. При чём тут слово master?

N>>Ну вот последнее и есть результат широко распространённых ламерских инструкций типа "освой за 5 минут".
N>>А "неприятно" это следствие ошибочных действий до того, а не свойство самого средства восстановления.
_NN>Как раз есть полезный сайт: https://ohshitgit.com/

Отличный пример страусиной глупости авторов такого сайта: проблемы не исчезнут от того, что средство, которое их решает, сложнее, чем требуется для Васи из Запердуновки или Абдулкумара из Кришнапутрыассама.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Зачем их исправлять? Это реальная история изменения кода, она имеет определенную ценность.
1. Есть мелкие опечатки и ошибки которые никакой ценности не имеют Какая ценность в коммитах типа "ой, забыл закоммитить заголовочный файл вместе с исходником"?
2. "Чистая история" где каждый коммит можно собрать и протестировать сильно облегчает жизнь.

Твои аргументы сейчас похожи на аргументы нелюбителей вещей типа RAII в соседней теме про C++

Здравствуйте, _NN_, Вы писали:

_NN>Из-за безоглядного rebase + push --force много начинающих программистов теряют недельный труд.
Что-то потерять с git очень сложно, т.к. есть reflog.

_NN>Поэтому появились защищённые ветки, где историю менять нельзя и там внезапно появляются коммиты исправления исправлений
Сделайте еще один шаг вперед: откройте для себя тестирование веток перед вливанием в мастер и не будет у вас никаких "исправлений исправлений"

Для примера: у нас CI запускается на новые коммиты и в мастере и в любой ветке с именем "ci/*".
Типичный рабочий процесс:
* Работаете в своей ветке dev/asdf и переписываете историю как угодно
* от dev/asdf делаете форк ci/asdf и пушите в систему CI — получаете ответ: хорошо/плохо
* по результату исправляете или мержите/пулл реквестите в мастер

В итоге чистая история и счастливые коллеги с минимальными затратами

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Зато больше подходит к задаче.
Нет
Условнй git log v1..v2 удобнее любого трекера (если у вас история без мусорных коммитов)

S>> например github/azure умеет автоматически закрывать задачи
НС>Лучше скажи кто не умеет этого делать.
Тем более

Здравствуйте, Skorodum, Вы писали:

НС>>Зачем их исправлять? Это реальная история изменения кода, она имеет определенную ценность.
S>1. Есть мелкие опечатки и ошибки которые никакой ценности не имеют Какая ценность в коммитах типа "ой, забыл закоммитить заголовочный файл вместе с исходником"?

Если кто-то в твоё отсутствие собрал exe-шник и отдал подставив в него какой-то другой заголовочный файл, то история будет объяснять, почему так произошло. А когда у вас история не соответствует собранным исполняемым модулям, то как вы будете воспроизводить ошибки?

S>2. "Чистая история" где каждый коммит можно собрать и протестировать сильно облегчает жизнь.
Или усложняет, потому что новая собранная версия не соответствует исполняемым скомпилированным модулям.

Здравствуйте, netch80, Вы писали:

N>Это я понял. При чём тут слово master?
Ветка мастера может незащищённой тоже.

Здравствуйте, Skorodum, Вы писали:

_NN>>Поэтому появились защищённые ветки, где историю менять нельзя и там внезапно появляются коммиты исправления исправлений
S>Сделайте еще один шаг вперед: откройте для себя тестирование веток перед вливанием в мастер и не будет у вас никаких "исправлений исправлений"

S>Для примера: у нас CI запускается на новые коммиты и мастере и любой ветке с именем "ci/*".
S>* Работаете в своей ветке dev/asdf и переписываете историю как угодно
S>* от dev/asdf делаете форк ci/asdf и пушите в систему CI — получаете ответ: хорошо/плохо
S>* по результату исправляете или мержите/пулл реквестите в мастер

S>В итоге чистая история и счастливые коллеги с минимальными затратами
Согласен это идеальная ситуация.
К сожалению на данный момент запуск только ночных тестов занимает пару часов.
Поэтому перед слиянием запускается только минимальное количество тестов, а на завтра можно посмотреть если вылезли новые проблемы.
А полный запуск всех тестов занимает день-два.

В общем можно работать в полной безопасноти но тогда фичи будут добавляться в лучшем случае по одной в день.

Здравствуйте, B0FEE664, Вы писали:

BFE>Если кто-то в твоё отсутствие собрал exe-шник и отдал подставив в него какой-то другой заголовочный файл, то история будет объяснять, почему так произошло. А когда у вас история не соответствует собранным исполняемым модулям, то как вы будете воспроизводить ошибки?
Кто-то "на коленки" что-то собрал из локально модифицированных исходников? Ну ок. Это его проблемы
Момент "отдал" такой продукт любом мало-мальски нормальном окружении невозможен.

S>>2. "Чистая история" где каждый коммит можно собрать и протестировать сильно облегчает жизнь.
BFE>Или усложняет, потому что новая собранная версия не соответствует исполняемым скомпилированным модулям.
Извините, но это предложение трудно понять

P.S. Решение любой "локальной" проблемы начинается с git status

P.P.S. Это тема такой же каминг аут как и тема про С... Такое ощущение, что многие застрялили лет 15-20 назад и разработка продолжается в духе "Вась, собери на своем компе релиз для заказчика, а то у меня тут версия библиотеки FooBar неправильная".

Здравствуйте, _NN_, Вы писали:

S>>В итоге чистая история и счастливые коллеги с минимальными затратами
_NN>Согласен это идеальная ситуация.
_NN>К сожалению на данный момент запуск только ночных тестов занимает пару часов.
_NN>Поэтому перед слиянием запускается только минимальное количество тестов, а на завтра можно посмотреть если вылезли новые проблемы.
Ну так завтра и мержить, зато быть уверенным
Все более-менее большие проекты так и живут, плюс часто надо ждать код-ревью.

_NN>А полный запуск всех тестов занимает день-два.
_NN>В общем можно работать в полной безопасноти но тогда фичи будут добавляться в лучшем случае по одной в день.
Почему? Есть принципиальная проблема распараллелить тестирование для разных фич/веток?

Мы пользуемся Azure, там плата как раз за количество одновременно работающих машин, обычно у нас 2 или 3 и тестирование занимает 10-15 минут, но если надо — берем больше машин.

Здравствуйте, Skorodum, Вы писали:

S>Кто-то "на коленки" что-то собрал из локально модифицированных исходников? Ну ок. Это его проблемы
S>Момент "отдал" такой продукт любом мало-мальски нормальном окружении невозможен.

Невозможен? Это почему? Вы что, решаете технические проблемы административными способами?

S>>>2. "Чистая история" где каждый коммит можно собрать и протестировать сильно облегчает жизнь.
BFE>>Или усложняет, потому что новая собранная версия не соответствует исполняемым скомпилированным модулям.
S>Извините, но это предложение трудно понять

Что тут трудного? Если вы поменяли историю, то вы никогда не сможете уже собрать точно те модули, которые были раньше.

S>P.S. Решение любой "локальной" проблемы начинается с git status
Да? А не с выбора правильного инструмента?

S>P.P.S. Это тема такой же каминг аут как и тема про С... Такое ощущение, что многие застрялили лет 15-20 назад и разработка продолжается в духе "Вась, собери на своем компе релиз для заказчика, а то у меня тут версия библиотеки FooBar неправильная".

В разных конторах дела обстаят по разному. В некоторых старых, которым уже больше 60 лет и которые застряли в прошлом веке, без строго соблюдения отчётности и бюрократии никуда.

PS Забавно наблюдать, как новое "модное" поколение любит переписывать историю.

Здравствуйте, _NN_, Вы писали:

_NN>·>Кстати, помимо отсутствия управления историей, в hg очень убого устроены ветки. Имя ветки вшивается в коммит, поэтому требуется централизованно договариваться об их именовании, иначе получается что попало, а отсутствие возможности сделать rebase делает исправления почти невозможными.
_NN>Bookmarks похоже на то как работает Git.
Да, я знаю про них, но это тоже большая корявость. Во-первых, начнём с этого фейспалма:

Be aware that there is only one namespace for bookmarks — it is advised to prefix your local-only bookmarks to avoid conflicts with other users.

Во-вторых, они появились не сразу (в более менее юзабельном виде в 2012 году, когда github уже победил), а как раз не особо удачная попытка "сделать как в git".
В-третьих, они не позиционируются как основная модель разработки, а как с-боку-пришлёпка, да ещё и опциональная. Например, попробуй ими попользоваться в том же bitbucket как основным средством бранчевания. А некоторые тулзы могут про них вообще ничего не знать.
Т.е. они решают проблему прошитости имени бранча в коммите, но проблему машстабной распределённой разработки никак не решают и только лишь создают другие проблемы. Так что в топку.

_NN>Уникальностью названий веток на сервере нужна и в Git-е, когда работают с центральным репозиторием.
Не нужна в общем случае, можно даже определить refspec и маппить как удобно. И непонятно что ты под центральным репом понимаешь. Центров может быть и несколько, у каждого свои бранчи и правила именования.

Здравствуйте, Skorodum, Вы писали:

S>·>Они были кривыми потому что основывались на svn и hg соответсвенно, которые из-за своих корявостей не могли обеспечить полноценную distributed разработку. Так что github победил как раз благодаря git. Gitlab не успел, т.к. банально появился позднее и всегда был в догоняющих.
S>У Gitlab сейчас своя ниша есть: это сервер на стороне клиента. У Github такого же нет. Особенно актуально для России.
github enterprise же, правда дорого (что иногда не актуально для России ).
А вообще собственно даже бесплатных конкурентов gitlab полно. Поэтому непонятно почему именно на gitlab свет должен был сойтись клином. Я лично предпочёл бы gerrit.

Здравствуйте, B0FEE664, Вы писали:

BFE>Невозможен? Это почему? Вы что, решаете технические проблемы административными способами?
Попробуйте описать техническую проблему которую вы тут видите.

BFE>Что тут трудного? Если вы поменяли историю, то вы никогда не сможете уже собрать точно те модули, которые были раньше.
Очевидно, что это не так google: "Reproducible builds"

S>>P.S. Решение любой "локальной" проблемы начинается с git status
BFE>Да? А не с выбора правильного инструмента?
Интсрумент тут совершенно не при чем, можно заменить на условный "hg/svn/cvs status".

BFE>В разных конторах дела обстаят по разному. В некоторых старых, которым уже больше 60 лет и которые застряли в прошлом веке, без строго соблюдения отчётности и бюрократии никуда.
Т.е. у вас опыт либо "студент Вася на коленки" либо "Василий Петрович в НИИ по поисьменному разрешению с тремя подписями"? Сочувствую

BFE>PS Забавно наблюдать, как новое "модное" поколение любит переписывать историю.
Ок

Здравствуйте, Skorodum, Вы писали:

BFE>>Что тут трудного? Если вы поменяли историю, то вы никогда не сможете уже собрать точно те модули, которые были раньше.
S>Очевидно, что это не так google: "Reproducible builds"
Ну о каком Reproducible builds вы говорите, если у вас нет тех исходников (в силу изменения истории) из которых можно собрать сделаную ранее сборку?

BFE>>В разных конторах дела обстаят по разному. В некоторых старых, которым уже больше 60 лет и которые застряли в прошлом веке, без строго соблюдения отчётности и бюрократии никуда.
S>Т.е. у вас опыт либо "студент Вася на коленки" либо "Василий Петрович в НИИ по поисьменному разрешению с тремя подписями"? Сочувствую
Я утрировал, чтобы вы заметили всю нелепость про :

Момент "отдал" такой продукт любом мало-мальски нормальном окружении невозможен.

и

"Вась, собери на своем компе релиз для заказчика, а то у меня тут версия библиотеки FooBar неправильная".

Ну вот собрали вы продукт, а потом, по ошибке, переписали историю:

1. Или ты никогда не ошибаешься.

?

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

Здравствуйте, B0FEE664, Вы писали:

НС>>>Зачем их исправлять? Это реальная история изменения кода, она имеет определенную ценность.
S>>1. Есть мелкие опечатки и ошибки которые никакой ценности не имеют Какая ценность в коммитах типа "ой, забыл закоммитить заголовочный файл вместе с исходником"?
BFE>Если кто-то в твоё отсутствие собрал exe-шник

Никакого "другого" который собрал экзешник не будет — потому что история в старом варианте (опечатки, пропустили пару мест поправить вызов и т.п.) не выйдет за пределы локального репо.
А если и выйдет, то в варианте спец. ветки типа refs/changes/$changeno/$verno (Gerrit), ci/... (версия от Skorodum), по которой экзешники, которые надо сохранять, не создаются.

Но даже если вдруг такой временный коммит кому-то нужен (например, воспроизвёл тонкий эффект, который долго ловят), то есть 90 дней (по умолчанию), чтобы по id в reflog перебрать все варианты.

S>>2. "Чистая история" где каждый коммит можно собрать и протестировать сильно облегчает жизнь.
BFE>Или усложняет, потому что новая собранная версия не соответствует исполняемым скомпилированным модулям.

Ещё раз: не чистят историю в уже отправленном хотя бы в репу рабочей группы.