Да, деплой на staging лучше всё-таки с ручным управлением оставить. Чтобы тестировщики сами могли определять, какую ветку они в текущий момент тестируют и она не изменилась случайно, только из-за того, что новый PR пришёл.
Странная у Вас логика… Типа между версиями один автор мог закоммитить только 1 фичу?
Рефакторинг — да, может затронуть много строк, но если делать 1 вид рефакторинга в 1 коммите (а это по сути и есть границы технической фичи), то никаких проблем не возникнет, вне зависимости от кол-ва затронутых строк.
Нужно смёржить мастер в ветку, прогнать тесты, поправить код, сделать git commit --amend, а потом уже мёржить ветку в мастер.
Ну вариант, да. Хотя лично для меня все эти мерджи master в ветку выглядят как какое-то дикое извращение.
Вы вроде не выступаете за то, чтобы делать squash при мёрже?
У меня нет строгого правила, что должен остаться обязательно 1 коммит, т.к. иногда удобнее сделать 3-5 коммитов в одной ветке, чем дробить это на 3-5 минифич. Но ветки по 100 коммитов, или как тут писали на 10000 значимо измененных строк, я не одобряю.
Видимо под удобной в работе историей вы имеете в виду линейную. Чем она удобна? В чём преимущество перед нелинейной?
Ну тут имхо очевидно. Что может быть проще прямой линии? Всё красиво и откатывать при необходимости можно фичи целиком, а не по 100 коммитов. Зачем засорять себе восприятие какими-то коммитами, которых по факту никогда не было в master? Чтобы найдя к-н опечатку вооружиться git bisect в поисках коммита, в котором она была сделана? Чтобы что? Чтобы revert сделать? А если там ещё изменения есть кроме той опечатки… И эти все пляски с бубном вместо того, чтобы за пару секунд исправить опечатку и закоммитить исправление? Или это так важно найти кто виноват и оштрафовать его на ползарплаты?
Повторный rebase — это тривиальнейшая процедура, уже без конфликтов в 99% случаев. Зато в master не будет ни одного битого (с т.з. тестов) коммита, а в случае с merge их так просто не избежать.
Главный аргумент статьи провалился из-за банального непонимания автора как правильно делать rebase. Из "бонусов" merge остались только уродливые merge-коммиты из master в ветку и обратно, которые типо интересно кому-то будет смотреть.
Из комментариев уже понял… Только это никаких проблем при использовании rebase не вызывает. Т.к. никто в здравом уме не будет вливать ветку после rebase до того как она пройдёт все тесты.
Статью то я читал… только она о каких-то вымышленных проблемах, которые мне за 8 лет использования rebase ни разу не встретились… Потому что по факту после rebase у вас остаётся всё такая же отдельная ветка, на которой вы всё так же запускаете тесты, и если что-то поломалось, то сначала выясняете в чём проблема, исправляете её, делаете ещё раз ребейз (начиная со второго раза это всегда легко), прогоняете тесты ещё раз, и убедившись, что всё работает, вливаете эту ветку в master.
Таким образом, битые коммиты после ребейз теоретически возможны, если прокралась какая-то ошибка, которая: 1) не мешает компиляции и запуску проекта; 2) не отлавливается тестами. Впрочем, сюрприз, такую ошибку вы и после merge ещё не скоро заметите. Только с линейной историей отследить и исправить её будет гораздо легче, вот и вся разница.
P.S. Ребейз всегда делается интерактивный, ума ни приложу, кому и зачем может захотететься запустить его в неинтерактивном режиме.
И squash и fixup вполне могут добавить осмысленности, Вы просто в каких-то розовых облаках витаете, где каждый коммит в рабочей ветке идеально продуман, логически выверен и не имеет ни единой опечатки. Отсюда и связь с водопадом, потому что на практике такое корпение над каждым коммитом в рабочей ветке — это пустая трата времени.
Объединение всех коммитов фичи в 1 — иногда оправдано, иногда — нет, но в целом если в ветке после rebase осталось больше 7 коммитов, то у вас что-то не так с определением границ фич.
после ребейза запустим тесты, увидим, что код сломан, и поправим в том коммите, где сломалось. Ребейз надо делать не один раз, а столько, сколько надо для достижения результата.
Вот, кстати, да. Статья написана так, как-будто после rebase ветка сразу объединяется с master, хотя по факту (при адекватной разработке) слияние будет только после прохождения тестов в ребейзнутой ветке.
Вот-вот… Сначала что-то монструозное пилят в отдельной ветке полгода, без единого ребейза на master… А потом rebase виноват в том, что надо несколько часов потратить на него для сохранения нескольких сотен коммитов :-)
Допустим, мы удалили из master зависимость, которая всё ещё используется в feature.
Это что имеется в виду? Удалили коммит из master, серьёзно?
Решение конфликтов посреди rebase длинной цепочки коммитов часто превращается в непростую задачу
Абсолютно эквивалентную по сложности решению конфликтов при merge большой ветки.
Для этого мы могли бы использовать интерактивный rebase.
Кхм, а кто-то реально использует неинтерактивный?
P.S. Вся статья — какая-то голая риторика, без единого практически значимого аргумента. То, что по время rebase можно допустить ошибку — это не проблема rebase, такую же ошибку можно и во время merge допустить.
А у нас в школе в начале 2000-х не было интернета, а был как раз Бейсик-Агат. В 11-м классе правда поставили новые компы и перешли на QBasic.
Но по сути, я начал программировать c Object Pascal уже в универе.
Ну на тему работы с AppStore как физ.лицо есть целая статья с комментариями юристов. Думаю, для PlayMarket те же положения по авторскому праву будут иметь силу.
Но я отвечал не на эту часть сообщения belator… И процитированная часть насчёт связи НДФЛ с отчислениями в фонды — это точно полный бред с т.з. НК РФ.
Да, деплой на staging лучше всё-таки с ручным управлением оставить. Чтобы тестировщики сами могли определять, какую ветку они в текущий момент тестируют и она не изменилась случайно, только из-за того, что новый PR пришёл.
Странная у Вас логика… Типа между версиями один автор мог закоммитить только 1 фичу?
Рефакторинг — да, может затронуть много строк, но если делать 1 вид рефакторинга в 1 коммите (а это по сути и есть границы технической фичи), то никаких проблем не возникнет, вне зависимости от кол-ва затронутых строк.
Ну вариант, да. Хотя лично для меня все эти мерджи master в ветку выглядят как какое-то дикое извращение.
У меня нет строгого правила, что должен остаться обязательно 1 коммит, т.к. иногда удобнее сделать 3-5 коммитов в одной ветке, чем дробить это на 3-5 минифич. Но ветки по 100 коммитов, или как тут писали на 10000 значимо измененных строк, я не одобряю.
Ну тут имхо очевидно. Что может быть проще прямой линии? Всё красиво и откатывать при необходимости можно фичи целиком, а не по 100 коммитов. Зачем засорять себе восприятие какими-то коммитами, которых по факту никогда не было в master? Чтобы найдя к-н опечатку вооружиться git bisect в поисках коммита, в котором она была сделана? Чтобы что? Чтобы revert сделать? А если там ещё изменения есть кроме той опечатки… И эти все пляски с бубном вместо того, чтобы за пару секунд исправить опечатку и закоммитить исправление? Или это так важно найти кто виноват и оштрафовать его на ползарплаты?
Ну, можно для начала CI настроить с прогоном тестов на каждый коммит (в любую ветку).
Думаете, разбиение этого патча на 500 коммитов сильно упростит ревью?
Может просто не надо такие монструозные ветки делать?
Чтобы не было битых коммитов и чтобы была удобная в работе история коммитов.
Оттуда что сначала идёт merge, а потом уже проверка. И, как тут уже писали, придётся доп.коммит с исправлениями после merge делать.
Повторный rebase — это тривиальнейшая процедура, уже без конфликтов в 99% случаев. Зато в master не будет ни одного битого (с т.з. тестов) коммита, а в случае с merge их так просто не избежать.
Главный аргумент статьи провалился из-за банального непонимания автора как правильно делать rebase. Из "бонусов" merge остались только уродливые merge-коммиты из master в ветку и обратно, которые типо интересно кому-то будет смотреть.
Из комментариев уже понял… Только это никаких проблем при использовании rebase не вызывает. Т.к. никто в здравом уме не будет вливать ветку после rebase до того как она пройдёт все тесты.
Другими словами, в случае rebase это обнаружится до вливания ветки в master, а в случае с merge — после. Вот и приехали.
Статью то я читал… только она о каких-то вымышленных проблемах, которые мне за 8 лет использования rebase ни разу не встретились… Потому что по факту после rebase у вас остаётся всё такая же отдельная ветка, на которой вы всё так же запускаете тесты, и если что-то поломалось, то сначала выясняете в чём проблема, исправляете её, делаете ещё раз ребейз (начиная со второго раза это всегда легко), прогоняете тесты ещё раз, и убедившись, что всё работает, вливаете эту ветку в master.
Таким образом, битые коммиты после ребейз теоретически возможны, если прокралась какая-то ошибка, которая: 1) не мешает компиляции и запуску проекта; 2) не отлавливается тестами. Впрочем, сюрприз, такую ошибку вы и после merge ещё не скоро заметите. Только с линейной историей отследить и исправить её будет гораздо легче, вот и вся разница.
P.S. Ребейз всегда делается интерактивный, ума ни приложу, кому и зачем может захотететься запустить его в неинтерактивном режиме.
И squash и fixup вполне могут добавить осмысленности, Вы просто в каких-то розовых облаках витаете, где каждый коммит в рабочей ветке идеально продуман, логически выверен и не имеет ни единой опечатки. Отсюда и связь с водопадом, потому что на практике такое корпение над каждым коммитом в рабочей ветке — это пустая трата времени.
Объединение всех коммитов фичи в 1 — иногда оправдано, иногда — нет, но в целом если в ветке после rebase осталось больше 7 коммитов, то у вас что-то не так с определением границ фич.
Вот, кстати, да. Статья написана так, как-будто после rebase ветка сразу объединяется с master, хотя по факту (при адекватной разработке) слияние будет только после прохождения тестов в ребейзнутой ветке.
Вот для их осмысления и существует rebase. Или вы к модели водопада предлагаете вернуться?
Вот-вот… Сначала что-то монструозное пилят в отдельной ветке полгода, без единого ребейза на master… А потом rebase виноват в том, что надо несколько часов потратить на него для сохранения нескольких сотен коммитов :-)
Это что имеется в виду? Удалили коммит из master, серьёзно?
Абсолютно эквивалентную по сложности решению конфликтов при merge большой ветки.
Кхм, а кто-то реально использует неинтерактивный?
P.S. Вся статья — какая-то голая риторика, без единого практически значимого аргумента. То, что по время rebase можно допустить ошибку — это не проблема rebase, такую же ошибку можно и во время merge допустить.
Вы для начала заработайте своим приложением больше 2 млн. © ст.171 УК РФ, а потом уже следователей начинайте бояться xD
Хотя возможна и обратная ситуация, можно, имея ИП, попасть под ст.198 УК РФ "Уклонение физического лица от уплаты налогов", если вы продажу лицензий на приложение пытаетесь выдать за предпринимательскую деятельность.
А у нас в школе в начале 2000-х не было интернета, а был как раз Бейсик-Агат. В 11-м классе правда поставили новые компы и перешли на QBasic.
Но по сути, я начал программировать c Object Pascal уже в универе.
Можно с C# начать, тогда можно не месяц, а хоть целый год ему посвятить. Языки с динамической типизацией, имхо, нельзя новичкам давать.
Ну на тему работы с AppStore как физ.лицо есть целая статья с комментариями юристов. Думаю, для PlayMarket те же положения по авторскому праву будут иметь силу.
Но я отвечал не на эту часть сообщения belator… И процитированная часть насчёт связи НДФЛ с отчислениями в фонды — это точно полный бред с т.з. НК РФ.