Git Practices

Rules

Never commit directly to master
Rebase to bring in changes from master when you become aware of changes to master (rebase early and often)
Before doing a PR, rebase on master
PRs during normal development require at least one reviewer
PRs when approaching freeze require at least two developers
PR author can always request multiple reviewers

When starting a new feature...

After making changes to your files, stage the files:

git add myfile.txt

If you want to stage all changed files, use:

git add -A

Then commit the staged changes to your local branch:

 git commit -m "My commit message"

If there are changes on master you want to bring in
- If you have uncommitted changes, commit or stash
```
git stash
```
- Rebase from master
```
git checkout master
git pull
git checkout my_feature_branch
git rebase master
```
  or
```
git pull --rebase origin master
```
  (note: does not update master branch locally)
- Resolve any merge conflicts
  - After staging the resolved files, git rebase --continue
  - Or if things went terribly wrong, git rebase --abort
At any point you want to push your branch to the remote
- First time:
```
git push -u origin my_feature_branch
```
- Subsequent times
```
git push
```
- BUT... if you rebased since last push, then...
```
git push -f
```
Create your pull request on GitHub when ready
- Rebase before creating the pull request
- If changes are needed during review, just push on the same branch
Pull requests must pass any automated tests before being merged
Pull requests must have at least one reviewer before being merged

Create a feature branch and treat it like master
- Authors create personal branches off feature branch
- Submit PRs against the feauture branch
When done, submit PR for feature branch against master

If you have lots and lots of not-too-meaningful commits, you can combine them into a single commit via the squash feature of git.