Many times have I seen a green developer throw up their hands at a rebase attempt, after which we learn they were doing this:
git checkout master; git pull
git checkout -b fb
git commit
git commit
# new changes arrive on master branch
git checkout master; git pull;
git checkout fb; git merge master
git commit
# "went to the git brownbag and heard about rebase for the first time,
# missing that part up front about not intermingling merges with rebases
# and not having a good mental model of git
git rebase master
# WTF conflict everywhere! rebase sucks
The flow you have described works (besides the last ‘git rebase master’), though. When ‘git merge master’ is run, the developer either get conflicts (which can be then fixed) or not. After that ‘git push’ and you can open a PR. I certainly don’t see anything wrong with that flow.
Comments
Many times have I seen a green developer throw up their hands at a rebase attempt, after which we learn they were doing this:
The flow you have described works (besides the last ‘git rebase master’), though. When ‘git merge master’ is run, the developer either get conflicts (which can be then fixed) or not. After that ‘git push’ and you can open a PR. I certainly don’t see anything wrong with that flow.