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 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.
- Thy branches shall be short-lived.
1. Thou shalt make a new branch for every ticket.
1 ticket = 1 branch: Don't mix work from different issues.
If you have a lot of related work that you need to QA together, make an integration branch (we'll get to that).
2. Include a ticket ID in every branch name and every commit message.
Example branch creation,
git checkout -b hawkeye/EECS-123/remove-cat-gifsExample git commit,
git commit -m 'EECS-123: Remove cat gifs'Find Trello card IDs at the beginning of the URL's final path part.
3. Thou shalt always PR.
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.
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.
This only works if we have people on hand to review + merge your commits immediately.
If you find this isn't the case on one of your projects, get with Hawkeye, we'll work something out.
6. Thou shalt delete thy merged branches.
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 origingit branch -a --mergedgit push origin :my-branch-one :my-branch-two
7. Thy branches shall be short-lived.
The longer your branch sits around, the more likely you are to run into more merge conflicts and be working with out-of-date code. Don't let your branches sit around for more than a few days, a week at most. Get them to a good stopping point and submit your pull-request. If you want to commit code from a branch that is more than a week old, make a new branch off latest master and cherry-pick your old work into the new branch.
"Can't I just merge latest master into my own branch?" you ask. Why, yes, you may, but (a) it creates merge commit bubbles and (b) navigating the possible resultant merge conflicts requires great care, skill, and time; 'tis best not to let your branches get old in the first place.
The need for this rule, of course, depends on the velocity of the project and with how many team members you work, but it is a good and important general practice.
Bonus. Thou shalt ask for help.
Being unsure is not only okay but helpful to the whole team.
Ask questions in Slack and get help with merge conflicts; don'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-ffIf you are OCD like me...
And you care about line lengths, grammar, punctuation, and other inane details, then Read Chris Beam's How to Write a Git Commit Message and follow The seven rules of a great commit message.
Also for the retentive folks: Always delete (non-integration) branches from GitHub after PR merge.