Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

Wash your git branches




A quick vocab review

Let's look at words



What is a remote?

Related image


Where do branches live?

local vs. origin vs. your local copy of origin

we're local 



What's the difference between "origin/my-branch" and "origin mybranch"?`

space



What are integration branches?

integration


The Seven Golden Rules of git hygiene

  1. Thou shalt make a new branch off latest master for every ticket.
  2. Thou shalt include a ticket ID in every branch name and every commit.
  3. Thou shalt always PR.
  4. Thou shalt always review thy Files Changed.
  5. Thou shalt never merge thy own Pull Requests.
  6. Thou shalt delete thy merged branches.
  7. 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-gifs

Example 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 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 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-ff

If 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.

  • No labels