PR-workflow.md

Pull Requests

Read these:

• How to get the most out of pull requests
• How to write the perfect pull request.

The Emoji Consensus Model

Make use of the The Emoji Consensus Model whenever you want to leave quick feedback on a pull request.

👍 (:thumbsup:) Yes please! I actively support this.

👉 (:point_right:) Let’s discuss further. We don’t have all the facts yet.

👎 (:thumbsdown:) Veto! I feel that I have all the facts needed to say no.

👊 (:punch:) I stand aside. I neither support nor oppose this.

Ready to Open a Pull Request?

First Rebase with the master branch. Rebasing master into your branch puts your commits after the latest commit on master instead of where you originally branched from. This should always be done before creating the pull request to guarantee there are no merge conflicts.

How to: Rebase with the Master branch

1. Make sure you don't have any uncommitted changes.
2. git checkout master - checkout master branch
3. git pull origin master - pull latest changes from origin remote (GitHub)
4. git checkout <your_feature_branch> - go back to your feature branch
5. git rebase master - start rebasing master
6. If you run into a merge conflict, fix it.
7. git add -A && git rebase --continue - continue with rebase after running into a conflict
8. Repeat steps 6-7 as many times as necessary until all commits have been rebase.
9. git push origin <your_feature_branch> - Push your changes to origin (GitHub). *
10. Get feedback.
11. Make any necessary additional commits.
12. Repeat rebasing with master if necessary. * If you previously pushed the same branch to GitHub, you'll need to force push your changes since you rewrote the commit history by rebasing. DON'T FORCE PUSH TO MASTER git push origin <your_feature_branch> --force.

Ready to Merge? Squash those commits

Once you have opened the PR, send to team for feedback. Before merging you likely have a few commits, some possibly with very small changes. This is a great time to squash any commits into one more meaningful one. Squashing commits is to put the new commits from your branch on a single commit to keep a clean git history on master. Proceed with Caution: This is re-writing git history!

How to: Squash commits with Interactive Rebase

1. Make sure you don't have any uncommitted changes.
2. Check which commits you'd like to squash with git log
3. If it's the most recent few you can use that number at the end of the command, for example: git rebase -i HEAD~3
4. Your editor will open with the recent commits, the editor will show those commit you chose. Keep the keyword "pick" on the commit you want to use, then change the others. You can refer to commented out section for options. You can use f for fixup if you don't want to preserve commit messages for each, if you do, you can use s for squash.

pick v98erl4 adds this to that
f d08er42 refactor refactor
f 8ed0r90 refactor refactor refactor

5. a. Close out the editor to continue.
6. b. If you use s, a new editor window will open where you can update your final commit message for the PR. You may want to consolidate some of the comments into simpler explanations of what the PR accomplishes. Again to continue, close the editor window.
7. You will need to force push your changes since you rewrote the commit history by rebasing. Reminder: DON'T FORCE PUSH TO MASTER git push origin <your_feature_branch> --force

For additional reference, watch this video on how to squash multiple git commits.