Real-World Git
Download as PPTX, PDF0 likes584 views
The document discusses essential Git practices, focusing on migrating from Subversion, branching strategies, and branch-management commands like merge, rebase, and cherry-pick. It emphasizes best practices for repository management, such as keeping one branch releasable and using Git flow for advanced branching. The text also covers the options and implications of rebasing and cherry-picking commits for effective version control.
Real-World Git
- 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