GG
но я считаю, что если ты часто ревертишь, то ты делаешь что то не так
+
Size: a a a
2019 October 11
DB
хотя у всех свои привычки. в aosp, вон, полно коммитов с темой "DO NOT MERGE"
GG
хотя у всех свои привычки. в aosp, вон, полно коммитов с темой "DO NOT MERGE"
Надо ж где-то тестироваться ?
GG
Проблема в энтропии
GG
Хаос в коде нарастает.... Катастрофически
GG
Вот работал ты над веткой. Забросил ее. Через неделю ты гарантированно не вспомнишь что в ней было
PD
согласен с вами ребята. Но просто почему я считаю полезной git revert ??? Она помогает откатить коммиты даже если ты запушил без вреда для истории и следовательно надобности использовать форс пуш тоже отпадает. Случай такого отката очень полезен, когда воркфлоу у нас такой, что тимлид просит, чтобы мои изменения в ветке у себя на компе посмотреть
PD
Я знаю, что в нормальной организации так быть не должно, чтобы откатывать чтото, но знания того, что гит может никогда не вредят
DB
юзкейс непонятен. реверт - полезен, это без вопросов.
DB
>так быть не должно, чтобы откатывать чтото
так не бывает, чтобы нечего было откатывать. идеального кода не бывает
так не бывает, чтобы нечего было откатывать. идеального кода не бывает
DB
а это уже административный вопрос. откатить коммит целиком и залить новый, с фиксом. или просто пофиксить.
DB
оба варианта имеют право на существование. у нас они комбинируются в зависимости от целесообразности
DB
когда некогда разбираться в ошибке, и надо срочно починить бранч - проще поревертить
PD
ну у нас юзкейс гита примерно такой:
дали задание -> если есть изменения в мастере, пулл -> создал ветку на удалёнке -> создал ветку на локалке -> за upstream-ил её с удалённой -> сделал в ней свои изменения -> тимлид требует коммит на удалёнке сразу же -> коммит на локалке -> коммит в удалёнку -> тимлид смотрит
дали задание -> если есть изменения в мастере, пулл -> создал ветку на удалёнке -> создал ветку на локалке -> за upstream-ил её с удалённой -> сделал в ней свои изменения -> тимлид требует коммит на удалёнке сразу же -> коммит на локалке -> коммит в удалёнку -> тимлид смотрит
DB
>требует изменение на удалёнке сразу же
проблема не в гите. проблема - в головах
проблема не в гите. проблема - в головах
PD
а я о чём ?? Наш воркфлоу противоречит принципу работы гита.
DB
для этого придумали PR
DB
коммит должен попадать в рабочую ветку после тестов, а не перед