Почему нужно перестать использовать Git rebase

Ну, можно для начала CI настроить с прогоном тестов на каждый коммит (в любую ветку).

Почему нужно перестать использовать Git rebase

Думаете, разбиение этого патча на 500 коммитов сильно упростит ревью?
Может просто не надо такие монструозные ветки делать?

Почему нужно перестать использовать Git rebase

Зачем делать эту тривиальнейшую процедуру, если её можно и не делать?

Чтобы не было битых коммитов и чтобы была удобная в работе история коммитов.

Откуда им взяться в случае c merge?

Оттуда что сначала идёт merge, а потом уже проверка. И, как тут уже писали, придётся доп.коммит с исправлениями после merge делать.

Почему нужно перестать использовать Git rebase

Повторный rebase — это тривиальнейшая процедура, уже без конфликтов в 99% случаев. Зато в master не будет ни одного битого (с т.з. тестов) коммита, а в случае с merge их так просто не избежать.
Главный аргумент статьи провалился из-за банального непонимания автора как правильно делать rebase. Из "бонусов" merge остались только уродливые merge-коммиты из master в ветку и обратно, которые типо интересно кому-то будет смотреть.

Почему нужно перестать использовать Git rebase

Из комментариев уже понял… Только это никаких проблем при использовании rebase не вызывает. Т.к. никто в здравом уме не будет вливать ветку после rebase до того как она пройдёт все тесты.

Почему нужно перестать использовать Git rebase

Другими словами, в случае rebase это обнаружится до вливания ветки в master, а в случае с merge — после. Вот и приехали.

Почему нужно перестать использовать Git rebase

Статью то я читал… только она о каких-то вымышленных проблемах, которые мне за 8 лет использования rebase ни разу не встретились… Потому что по факту после rebase у вас остаётся всё такая же отдельная ветка, на которой вы всё так же запускаете тесты, и если что-то поломалось, то сначала выясняете в чём проблема, исправляете её, делаете ещё раз ребейз (начиная со второго раза это всегда легко), прогоняете тесты ещё раз, и убедившись, что всё работает, вливаете эту ветку в master.
Таким образом, битые коммиты после ребейз теоретически возможны, если прокралась какая-то ошибка, которая: 1) не мешает компиляции и запуску проекта; 2) не отлавливается тестами. Впрочем, сюрприз, такую ошибку вы и после merge ещё не скоро заметите. Только с линейной историей отследить и исправить её будет гораздо легче, вот и вся разница.

P.S. Ребейз всегда делается интерактивный, ума ни приложу, кому и зачем может захотететься запустить его в неинтерактивном режиме.

Почему нужно перестать использовать Git rebase

И squash и fixup вполне могут добавить осмысленности, Вы просто в каких-то розовых облаках витаете, где каждый коммит в рабочей ветке идеально продуман, логически выверен и не имеет ни единой опечатки. Отсюда и связь с водопадом, потому что на практике такое корпение над каждым коммитом в рабочей ветке — это пустая трата времени.
Объединение всех коммитов фичи в 1 — иногда оправдано, иногда — нет, но в целом если в ветке после rebase осталось больше 7 коммитов, то у вас что-то не так с определением границ фич.

Почему нужно перестать использовать Git rebase

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

Вот, кстати, да. Статья написана так, как-будто после rebase ветка сразу объединяется с master, хотя по факту (при адекватной разработке) слияние будет только после прохождения тестов в ребейзнутой ветке.

Почему нужно перестать использовать Git rebase

Вот для их осмысления и существует rebase. Или вы к модели водопада предлагаете вернуться?

Почему нужно перестать использовать Git rebase

Вот-вот… Сначала что-то монструозное пилят в отдельной ветке полгода, без единого ребейза на master… А потом rebase виноват в том, что надо несколько часов потратить на него для сохранения нескольких сотен коммитов :-)

Почему нужно перестать использовать Git rebase

Допустим, мы удалили из master зависимость, которая всё ещё используется в feature. 

Это что имеется в виду? Удалили коммит из master, серьёзно?

Решение конфликтов посреди rebase длинной цепочки коммитов часто превращается в непростую задачу

Абсолютно эквивалентную по сложности решению конфликтов при merge большой ветки.

Для этого мы могли бы использовать интерактивный rebase.

Кхм, а кто-то реально использует неинтерактивный?

P.S. Вся статья — какая-то голая риторика, без единого практически значимого аргумента. То, что по время rebase можно допустить ошибку — это не проблема rebase, такую же ошибку можно и во время merge допустить.

Разработка прибыльной Android игры двумя школьниками

Вы для начала заработайте своим приложением больше 2 млн. © ст.171 УК РФ, а потом уже следователей начинайте бояться xD
Хотя возможна и обратная ситуация, можно, имея ИП, попасть под ст.198 УК РФ "Уклонение физического лица от уплаты налогов", если вы продажу лицензий на приложение пытаетесь выдать за предпринимательскую деятельность.

Я б в программеры пошёл, пусть меня научат

if / господи, как же пишется if на паскале?, забыл уже всё… /

if (i mod 2 = 0) then
  ...

Я б в программеры пошёл, пусть меня научат

А у нас в школе в начале 2000-х не было интернета, а был как раз Бейсик-Агат. В 11-м классе правда поставили новые компы и перешли на QBasic.
Но по сути, я начал программировать c Object Pascal уже в универе.

Я б в программеры пошёл, пусть меня научат

Можно с C# начать, тогда можно не месяц, а хоть целый год ему посвятить. Языки с динамической типизацией, имхо, нельзя новичкам давать.

Разработка прибыльной Android игры двумя школьниками

Ну на тему работы с AppStore как физ.лицо есть целая статья с комментариями юристов. Думаю, для PlayMarket те же положения по авторскому праву будут иметь силу.
Но я отвечал не на эту часть сообщения belator… И процитированная часть насчёт связи НДФЛ с отчислениями в фонды — это точно полный бред с т.з. НК РФ.

Go: 10 лет и растём дальше

На Elixir:

1..10000 
|> Enum.map(&Task.async(fn ->
  IO.puts("worker #{&1} started job")
  :timer.sleep(1000)
  IO.puts("worker #{&1} finished job")
end))
|> Enum.map(&Task.await/1)

Разработка прибыльной Android игры двумя школьниками

Даже если это можно было бы как-то квалифицировать как НДФЛ, то отчисления в пенсионный фонд и на медстрахование никто не отменял.

Вам бы самому налоговый кодекс почитать, прежде чем советы давать… Отчисления в пенсионный фонд и на медстрахование платят юр.лица за штатных сотрудников и ИП.
Физ.лица платят только НДФЛ со своих доходов. Как пример, договор подряда не подразумевает никаких отчислений в фонды.

Не рычите на фрилансера

Если со стороны заказчика смотреть, то по сравнению с наймом компании 1000 руб/час — это очень-очень дешево. Такие расценки были лет 7 назад у региональных компаний на саппорт сайтов уровня корпоративный/визитка, при этом по факту выделяется время обычного программиста средней руки. Так что по нынешним меркам, чтобы нанять через компанию сеньора с зарплатой 160-180к платить придётся ближе к 5000 руб/час, иначе компания разорится )))