СА
Вы про squash and merge?
Я про rebase -i
Size: a a a
2020 September 13
VI
я бы еще добавил, что такое уместно, когда в репу попало что-то, чего там быть не должно (креды какие-нибудь например). тогда есть совет по утилите от гитхаба https://help.github.jp/enterprise/2.11/user/articles/removing-sensitive-data-from-a-repository/
D
Не знаю, как там в gitlab, в Github'е давно есть возможность сквошить изменения при мердже кнопкой.
Но, да. Если это короткоживущая бранча - то свош - это стандартная практика.
Но, да. Если это короткоживущая бранча - то свош - это стандартная практика.
VI
я бы еще добавил, что такое уместно, когда в репу попало что-то, чего там быть не должно (креды какие-нибудь например). тогда есть совет по утилите от гитхаба https://help.github.jp/enterprise/2.11/user/articles/removing-sensitive-data-from-a-repository/
но это наверное не по теме немного
SS
> Что я забыл?
Не поощрять такое поведение. 🌚
Не поощрять такое поведение. 🌚
ха, люди боятся git push -f как огня. я считаю, что если человек догадался, что на своем собственном бранче он может делать rebase -i и push -f, то сразу можно на повышение! и если история коммитов от этого улучшается, конечно, а не git ci -m"fixed bug"
D
ха, люди боятся git push -f как огня. я считаю, что если человек догадался, что на своем собственном бранче он может делать rebase -i и push -f, то сразу можно на повышение! и если история коммитов от этого улучшается, конечно, а не git ci -m"fixed bug"
Иногда удобно видеть коментарии к немердженому PR (например, где идёт обсуждение о том, почему так делать нельзя). GitHub их иногда теряет полностью и знания теряются. Потому в большинстве случает предпочитаю делать
rebase -i перед мерджем.Y
ха, люди боятся git push -f как огня. я считаю, что если человек догадался, что на своем собственном бранче он может делать rebase -i и push -f, то сразу можно на повышение! и если история коммитов от этого улучшается, конечно, а не git ci -m"fixed bug"
ну так там же все правильно про сквош пишут
SS
ну это от культуры разработки зависит, наверное, если вы делаете 15 коммитов на бранче во время работы, а потом хотите сделать 3 осмысленных коммита, то сквош не подойдет. а если у вас 2 всего, один "fixed bug", а второй "fixed review comments", то конечно
Y
не знаю, моя политика такая: похер на красивую историю гита, накосячил - забей -> через 10 лет никто этот коммит не вспомнит и не найдет
Y
а вот потерять историю или похерить чужую работу делай force push и иже с ними в коллектиных ветках - это вот похуже косяк
Y
по этому я всех умников, которые любят форс пуши, предупреждаю об отвественности. Мол если ты похеришь работу других людей - то это не “так получилось, извините” (но естественно ничего не запрещаю, просто предупреждаю об ответственности)
ИМ
ну так в мастер с девом запретить и ок
SS
по этому я всех умников, которые любят форс пуши, предупреждаю об отвественности. Мол если ты похеришь работу других людей - то это не “так получилось, извините” (но естественно ничего не запрещаю, просто предупреждаю об ответственности)
не, ну в бранчи, с которыми не только ты один синхронизуешь, не надо конечно. а на своем дев бранче можно и красоту навести
SS
просто надо понимать, где можно, а где нет
СА
не знаю, моя политика такая: похер на красивую историю гита, накосячил - забей -> через 10 лет никто этот коммит не вспомнит и не найдет
Дело не в красивой истории. Если у тебя получается большой MR, и ты хочешь сэкономить коллеге пару часов на ревью - переразбей его на осмысленные коммиты, которые можно ревьюить по одному.
СА
А также делать rebase на мастер лучше, чем несколько раз его в свою ветку мержить.
SS
плюсую к обоим комментам
Y
Дык я ж не запрещаю. Просто говорю, что если ты живешь так: то ты никому не навредишь. А если начинаешь играться с ребейзом и форспушами - то будь добр принимать за все свои действия ответственность
IV
Как же хорошо жить в мире trunk based development :)