Почему нужно перестать использовать 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 руб/час, иначе компания разорится )))

Правда ли, что люди пишут безумный код с перекрывающимися побочными эффектами, сохраняя при этом невозмутимость?

zeitweilig куда как более популярное прилагательное в немецком.

Chrome победил

По StatCounter, на который статья опирается, доля винды на десктопе сейчас — 84%.