Real-World GitStuff We Didn’t Cover Last Time

Stuff to Cover

1. Migrating from Subversion

2. Branching strategies

3. Branch-management commands

a. Merge

b. Rebase

c. Interactive rebase

d. Cherry pick

Migrating from Subversion

Three aspects:

1.Import commits

2.Clean up metadata

a. Authors

b. Tags

3.eHarmony infrastructure

Best practice:Repository per artifact

Easier Waygit svn clone <subversion_url>

• Built into git, brings in all commits and branches

• Can import Subversion subdirectories

http://git-scm.com/book/en/Git-and-Other-Systems-Migrating-to-Git

• Authors looks like this in history:

rwarren <rwarren@4c93b258-373f-11de-be05-5f7a86268029>

• Subversion tags become Git branches

More Complete Way

1. Get svn2git from https://github.com/nirvdrum/svn2git

2. Build list of authors in your history

• Manually, or:

svn log ^/ --xml | grep -P "^<author" | sort -u | perl -pe 's/<author>(.*?)<\/author>/$1 = /'

More Complete Way

3. Import: svn2git <subversion_url> <local_dir> --authors <authors_file>

https://wiki.corp.eharmony.com/display/MAT/Matching+SVN+to+Git+migration

• Subversion tags are recognized as Git tags

• Authors look like this in the history:

Rick Warren <rwarren@eharmony.com>

Either Way1. Push to Git repository:

$ git remote add origin <git_url>

$ git push origin --all

$ git push origin --tags

2. Set up eHarmony stuff

a. Add build/release jobs in Jenkins

b. Add repositories to Crucible

Branching Strategies

Remember:

• Everything is a branch. It ain’t no thing, y’all.

• You can rename or rebase your branch if you screw up (but you’ll cause pain to your team)

• Stuff happens: keep one branch releasable.

What We Do in Matching

• Release from master, and keep it releasable

• Do stories on branches: “MAT-1234_feature”

• When master released, merge to branch

• Preliminary QA acceptance on branch

• Merge to master, release, accept again

Fancier: Git Flow

• master == latest release

• develop == latest integration, accumulating merges until next release

• Specialized branches, off develop:features, hot fixes, release stabilization

• Built directly into some Git clients

http://nvie.com/posts/a-successful-git-branching-model/

Rebasing• Replay the commits of one branch on top of another

branch

• Use as an alternative to merge, if you value “clean” history

http://git-scm.com/book/ch3-6.html

before after

Interactive RebasingDo any of these apply to you?

• Big, coarse commits: you fear sharing changes too early.

• Lots going on in your working copy: you lose track of what you’ve changed, and occasionally revert a file by accident.

• Five minutes after committing, you realize you missed something.

Solution: Interactive Rebase

• Commit early and often, to checkpoint each fine-grained change.

• Wait to push until ready to share.

• Squash and reorder unshared commits in the mean time.

older

newer

git rebase -i

$ git rebase -i HEAD~5

In editor:pick 2174c26 MAT-1234: Pruned dependencies

pick 4d1d456 MAT-5678: Improved validation

pick aedba8f MAT-9876: Updated API

pick 6727eca MAT-5432: Removed cruft

pick 0afb08b MAT-1098: Fixed bean name

git rebase -ipick: Keep commitreword: Change messagesquash: Combine with previous

pick 2174c26 MAT-1234: Pruned dependencies

pick 4d1d456 MAT-5678: Improved validation

pick aedba8f MAT-9876: Updated API

pick 6727eca MAT-5432: Removed cruft

pick 0afb08b MAT-1098: Fixed bean name

Word of Warning• Commits are immutable

• Rebasing doesn’t delete old commits; it just makes new ones

• Rebasing can’t remove those old commits from others’ local repositories

• Don’t rebase any commits that you’ve pushed

Cherry Pick

• Copy commit(s) from history onto current branch

• Leaves source branch alone

• Use when merging is impossible or premature

http://git-scm.com/docs/git-cherry-pick

Please Enjoy Git Responsibly