After reading this article, it makes sense to rebase to gather changes from the main branch on to my feature branch: Git workflow and rebase vs merge questions
c
There is solution for your case without switching to a completely different workflow.
Regarding getting fixes from your main branch into feature branches, as you already found out, the best is to cherry-pick those particular commits. But I prefer to have topic branches even for hotfixes instead of fixing in the mainline, that way I can properly merge those fixes into every feature blocked by them.
To maintain feature development history as clean and linear as possible all collaborators must use git pull --rebase
to get updates so no meaningless merge commits gets in the way.
If you still want to rebase a collaborative feature branch over current main development branch (for continuous integration testing or other purposes) or rewrite its history in any other way, you can do it once the feature is complete/done, just before the merge to main branch, but you should do it in a new separate local/private branch.
Here is how to recreate your on-topic changes (skip cherry-picks) in a new branch from master:
$ git checkout -b feature_final feature # jump to a new branch for grooming
$ git rebase [-i] master # rebase topic changes onto master
From there is up to you what to do with the rebased branch —push upstream for QA or directly merge to master (with --no-ff if you like to make it explicit in history).