Note, this is not a suggestion for a global strategy for TAB, just a healthy way that our feature team can create clean, linear Pull Requests that are very easy to code review.
Create branch with feature name
- hack code
- rebase off master
- hack code
- rinse and repeat
This is more difficult if you are pairing on a branch but it's not too bad. Both engineers commit or stash their changes prior to rebasing the branch against Master and then if necessary performing a git reset:
git reset --hard me/branch-name
(where me is the remote repo containing the rebased branch)
This is a potentially dangerous change but is absolutely fine provided you understand what you are doing.
If you are having a long running branch with many engineers collaborating, this approach clearly won't work but most of the time we won't be working like that. A single feature will be owned by a single dev who will probably be pairing with a colleague so commit, rebase, reset is relatively simple to manage
Why would we want to mess with rebasing when it's dangerous and convoluted?
- sha1 add username
- sha2 refactor users object into user/person object
- sha3 merge master
- sha4 delete username, no longer needed
- sha5 merge master
- sha6 combine user and person object
- sha1 add username
- sha2 refactor users object into user/person object
- sha3 delete username, no longer needed
- sha4 combine user and person object
Which could then be rebased into: a single (or many if necessary) logical commits which is very simple to Review as part of a PR as it has a very clear delta.
i.e.
- sha1 combine user and person object
Only once the Feature has been tested and is considered ready for an external code-review or merge, should the PR be created. I don't see the point of creating a PR early on in a feature development's progress. A PR is a 'request' to pull/merge your code. Collaboration and discussion prior to the feature being ready can happen elsewhere.
Further reading: https://www.atlassian.com/git/tutorials/merging-vs-rebasing/summary