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
masterfor 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.
Make very sure your local copy of master is up-to-date with origin before branching!
1 ticket = 1 branch: Don't mix work from different issues.
...
Example branch creation,
git checkout -b feature/derekhawkeye/EECS-123--/remove-cat-gifsExample 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 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 ; 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...
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: - ESLint vs. JSHint? - Always delete branches (non-integration) branches from GitHub after PR merge.