Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Image Modified




A quick vocab review

Let's look at
wordsImage Modified



What is a remote?

Related imageImage Modified


Where do branches live?

local vs. origin vs. your local copy of origin

we're localImage Modified 



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

spaceImage Modified



What are integration branches?

integrationImage Modified


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.

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.

...

git remote prune origin
git branch -a --merged
git 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. This. 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 you are likely to run into more merge conflicts and be working with out-of-date code the longer your branch sits aroundit is a good and important general practice.

Bonus. Thou shalt ask for help.

...

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.