A smattering of brief intermediate topics regarding the Git version control system, including branching strategies, interactive rebasing, and migration from Subversion.

1. Real-World Git
Stuff We Didn’t Cover Last Time

2. Stuff to Cover
1. Migrating from Subversion
2. Branching strategies
3. Branch-management commands
a. Merge
b. Rebase
c. Interactive rebase
d. Cherry pick

3. Migrating from Subversion
Three aspects:
1. Import commits
2. Clean up metadata
a. Authors
b. Tags
3. eHarmony infrastructure
Best practice:
Repository per
artifact

4. Easier Way
git 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

5. 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 = /'

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

7. Either Way
1. 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

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

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

10. 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/

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

12. Interactive Rebasing
Do 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.

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

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

15. git rebase -i
pick: Keep commit
reword: Change message
squash: 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

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

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

18. Please Enjoy Git
Responsibly