git rebase squash

Как и в сотне других случаев git rebase -i.

не советуют вроде rebase -i для удаленных веток делать.
сделал в итоге сначала rebase просто на новую ветку, потом на новой rebase -i и потом уже ее запушил. Но не покидает чувство легкого беспокойства. Это у меня первая крупная работа с гитом, да. До этого только в локальных репах бедокурил

не советуют вроде rebase -i для удаленных веток делать

Зависит от того что вы с этой веткой собираетесь делать. Если то, куда вы влили за'rebase'ную ветку имеет шанс когда-либо слиться с потомками оригинальной ветки (например вы или те кто будет пользоваться вашим кодом сделаете pull из новой версии оригинала, или захотите влить свои изменения в оригинал), вы получите в репозитории и оригинальные коммиты, и то что вы на'rebase'или.

возможно я не совсем понимаю, как работает rebase. Т.е. моя ситуация следующая:

git clone <repo>
git checkout -b b1 origin\release1
[changes on b1]
git commit
[more changes on b1]
git commit
git push origin b1 # теперь b1 отправлена на сервер
[good god, another change on b1]
git commit

git checkout -b b2 origin/release1 # новая ветка от того же самого родителя
git rebase b1 # скопировал коммиты с b1 (мне так кажется, по крайней мере)
[on b2] git rebase -i HEAD~3 # squash 3 commits
git push origin b2

с первой веткой кстати кроме меня больше никто работать не будет практически 100%, по крайней мере в этот раз. А вот вторая будет когда-нибудь слита куда-то еще

Правильно ли я поступил и есть ли способ лучше?

Проще было сделать так:

git checkout -b b2 origin/release1
git merge --squash b1 && git commit

а насчёт последствий rebase в данном случае всё нормально - это твои коммиты и если их ещё никто не смержил, ты можешь переколбашивать их как угодно, тем более в отдельных ветках. В принципе, тут можно было даже не создавать вторую ветку, а изменить первую и сделать push --force, если ты уверен что никто кроме тебя её не использует.

Ок, спасибо за совет