A quick vocab review | |
---|---|
What is a remote? | |
Where do branches live? local vs. origin vs. your local copy of origin | |
What's the difference between " | |
What are integration branches? |
The Seven Golden Rules of git
hygiene
- Thou shalt make a new branch branch off latest master for every ticket.
- Thou shalt include a ticket ID in every branch name and every commit.
- Thou shalt always PR.
- Thou shalt always review thy Files Changed.
- Thou shalt never merge thy own Pull Requests.
- Thou shalt delete thy merged branches.Thou shalt ask for help
- Thy branches shall be short-lived.
1. Thou shalt make a new branch for every ticket.
...
Example branch creation,
git checkout -b featurehawkeye/derek/EECS-123--/remove-cat-gifs
Example git commit,
git commit -m 'EECS-123: Remove cat gifs'
Find Trello card IDs here:
at the beginning of the URL's final path part.
3. Thou shalt always PR.
Even the "Oh but I just need to update this log message..." commits.
It If the work is related, it is totally okay to add commits to an existing PR (by committing to the same branch and pushing before the PR is merged).
4. Though shalt always review thy Files Changed.
.
If you added a library or contrib module, GitHub may not show the whole diff. In that case, review the diff with your git app of choice.After making a PR, always actually review the diff–line-by-line–to make sure each and every change is actually intended. E.g.,
- Did I really mean to commit:
console.log('IT WERKZZZ!')
- I see a bunch of deleted code; did I futz a merge conflict resolution?
- I see a bunch of new code that isn't mine; did I accidentally commit some files?
5. Thou shalt never merge thy own Pull Requests.
...
If you find this isn't the case on one of your projects, get with DerekHawkeye, we'll work something out.
...
The person who merges a PR should delete the branch (except for integration branches). BUT, you should still go and check for your messes on GitHub and Pantheon.
\
...
git remote prune origin
git branch -a --merged
git push origin :my-branch-one :my-branch-two
7. They branches shall be short-lived.
Don't let your branches sit around for more than a few days, a week at most. This, of course, depends on the velocity of the project and with how many team members you work, but you are likely to run into more merge conflicts and be working with out-of-date code the longer your branch sits around.
Bonus. Thou shalt ask for help.
Being unsure is not only okay but helpful to the whole team.
Ask questions in Slack ; Get and get help with merge conflicts; Demonstrate vulnerabilitydon't wipe out your teammates' hard work.
...
Everybuddy, put these in your ~/.gitconfig
If you actually care why, read this Kalawiki page.
[branch]
autosetuprebase = always
[core]
mergeoptions = --no-commit --no-ff
...
Also for the retentive folks: - ESLint vs. JSHint? - Always delete branches (non-integration) branches from GitHub after PR merge.