In the (somewhat less common) case where other people are also working on the same shared remote feature branch, also rebase changes coming from it:
git rebase origin/PRJ-123-awesome-feature
At this point solve any conflicts that come out of the rebase.
----------------------
I don't know about this, we've used this before and what winds up happening is a lot of
git push --force
since the the remote feature branch's history is always being rewritten and won't match the local histories. We only rebase if the feature branch is being worked on by a single developer. And a bunch of other grief ... or am I missing something?
You can only really rebase onto one remote branch. If two people are working on feature branch PRJ-123-awesome-feature, then you both rebase onto origin/PRJ-123-awesome-feature. You have to merge with master if you wish to keep in sync.
Prior to one of you pushing to master you can opt to do a final rebase onto master, but I've always kept these long-running branches in history. I too try to avoid cluttering history with too many merge commits, but it's a very different thing if these long-running feature branches wind up as merges in history.
git rebase origin/PRJ-123-awesome-feature
At this point solve any conflicts that come out of the rebase.
----------------------
I don't know about this, we've used this before and what winds up happening is a lot of
since the the remote feature branch's history is always being rewritten and won't match the local histories. We only rebase if the feature branch is being worked on by a single developer. And a bunch of other grief ... or am I missing something?