I've used git a fair bit, but I haven't done a lot of rebasing. My rudimentary understanding is that you should not rebase commits that have already been pushed (this possibly pulled), because rebasing commits actually creates new commits (i.e., the hashes are different). And, in short, this can wreak havoc.
I understand that rebasing can keep the commit history _much_ easier to follow. The Indeni git docs (e.g., https://indeni.atlassian.net/wiki/spaces/IKP/pages/63012870/Pushing+code+git) suggest a workflow that uses rebasing. Specifically:
'Once you've committed your code, you will need to push it to the main repository. Before you do, however, it's important you update your branch with whatever progress the "staging" branch has achieved while you were working on your code. To do that, run "git pull --rebase origin staging".'
This makes sense to me, so long as the local commits haven't been pushed yet. So, the workflow would be "do some work, commit, pull-rebase onto staging, and push". But, what if you're working in a shared feature branch where devs are working on shared code? Chris and I are doing that now. I'm thinking that each dev working on the feature branch should still rebase onto staging before pushing, but would also need to pull in (merge, not rebase) the feature branch before pushing...? This would mean periodic merge commits in the feature branch. In this case, the workflow would be: write some code, commit, pull-rebase onto staging, pull-merge with feature, push...
I guess the problem I'm wrestling with is that it doesn't really seem possible to rebase onto two different branches in a single push. E.g., rebase local feature commits onto staging and then try to rebase those same local commits onto somebody else's feature branch commits (ones that have been pushed to the feature remote while you were making your local changes).