Recommended
More Related Content
What's hot
What's hot (20)
Similar to Source Code Management Slides
Similar to Source Code Management Slides (20)
Recently uploaded
Recently uploaded (20)
Source Code Management Slides
- 1. Version Control And how it will change your workflow
- 2. Key Topics • • • • What is version control? Why is it important? Should I be using it? What Version Control app should I use?
- 3. Version control started as scratching an itch… • It’s why we use “Save As”. You want the new file without obliterating the old one. It’s a common problem, and solutions are usually like this: – Chances are you've already rolled your own without knowing it... – Make a single backup copy (Document.old.txt). – If we’re clever, we add a version number or date: Document_V1.txt, DocumentMarch2007.txt – We may even use a shared folder so other people can see and edit files without sending them over email. Hopefully they re-label the file after they save it.
- 4. Version Control to the rescue File Management Team Management • Backup and Restore • The Ultimate Undo • Blame-Storming Credit! • Sandboxing • Synchronization
- 5. Terminology Make with the lingo jack… • • • Repository (repo) – Database storing the files Working Copy – Your local directory of files Trunk / Master * – The primary location for code in the repo. Basics • • • • • Add – Begin tracking with VC Revision – What version a file is on Head – The latest version in the repo Checkout – Download a file from the repo Check in - Upload to the repo – • • • *Some systems call this main The file gets a new version number, people can check it out Change-log / History – List of changes to the file since it was created in VC Update / Sync – Synchronize your files with Head Revert – Throw away your changes, and reload from HEAD
- 6. The Two Models Distributed Centralized Bonus Question Can anyone tell me the potential problem with using a centralized approa to version control?
- 7. Version Control What are my options? VCS Name Type Git (the topic today) Distributed SVN Centralized Bazaar Distributed Mercurial Distributed Team Foundation Server Centralized CVS (Legacy) Rating Centralized Source: http://en.wikipedia.org/wiki/Comparison_of_revisoin_control_software
- 8. Cloning the Repository Repo mkdir ~/repository && cd repository git clone git@github.com:chuckbutler/dotfiles
- 9. Basic Checkins TRUNK Milk Milk Bread Milk Bread Eggs Rev 1 Rev2 Rev3 echo git git git “Milk” >> list.txt add list.txt commit –m “Added milk to the list” push origin master
- 10. Checkout and Edit TRUNK Milk Eggs Juice Revert Check out Milk Eggs Soup Milk Eggs Soup Check in
- 11. Basic Diffs The repository has a history of changes as a file evolves. Diffs are the changes you made while editing: imagine “peeling” them off and applying them to a file TRUNK Milk R1 +Eggs Milk Eggs R2 +Juic e Milk Eggs Juice Juice + Soup R3 Milk Eggs Soup R4 To go from R1 to R2, we add eggs. Imagine peeling off that red sticker and placing it on R1 to get to R2. And from R2 to R3 we add Juice, from R3 to R4 we delete Juice and add Soup Most VCS store diffs rather than full copies of the file. This saves disk space: 4 revs of a file doesn’t mean we have 4 copies; we have 1 copy with 4 small diffs.
- 12. Diffs help us notice changes. (“How did you fix that bug?”) and even apply them from one branch to another. -- more on that in a second. git rev-list --all 1bc4b508a68c4dc85873beb0836823a0799d695a 286d7c1b00a4bf408a046ccfda1e6064d6fc5960 4a5e80a2e83671de7985852a94a6c43549c4c4ab ... Git diff 1a3a050aaf29b9411552c5a66c85698414b0611d Note: (git uses computed hash’s for revisions) Bonus Question: in the previous diagram, whats the diff from R1 to R4 + Eggs + Soup Notice how “Juice” wasn’t even involved – The direct jump from R1 to R4 doesn’t need that change, since Juice was overridden by Soup
- 13. Branching Milk Eggs Soup Milk Eggs Soup Rice R5 R6 Milk Eggs Soup Bread R7 New Feature TRUNK Milk Eggs Soup R4 Other devs continue working, committing to trunk while you work out of your branch
- 14. We branch for our new, experimental ideas. git branch noms git checkout noms Now that we have a branch, and we are working IN that branch, we can change our code and work out the kinks. Testing in isolation, knowing our changes wont hurt anyone, and our branch history is under version control It’s a tough concept for newbie's, so pretend you copied your code into a different directory.
- 15. Merging This step is the most daunting of all and hangs up most first-time use Milk Egg s Sou R5 Milk p Eggs Soup New Feature R6 Rice TRUNK Milk Egg s Sou p R4 Milk Eggs Soup Brea d +Ric e R7 Milk Eggs Soup Brea d R8 Rice Re-Integration of a branch usually winds up in conflicts – this is why it seen as difficult. You will be making good use of the diff command
- 16. git git branch experimental branch experimental * master git checkout experimental (edit file) git commit -a git checkout master (edit same file in master) git commit –a git merge experimental We now have a conflict. PANIC! What do I do? Relax, grab a beer and start resolving conflicts with git-diff
- 17. A charted example of conflicts -Eggs +Cheese R3* Bob Milk Egg s Sou p Valid Milk Cheese Checkin Juice TRUNK R3 -Eggs +Hot Dog Milk Cheese Juice R4 Conflicting Checkin (Cannot remove eggs) R3* Judy Milk Hot Dog Juice
- 18. Tagging • Version Control Systems support a method of easy identification on –stable branches that we branch out of our source-tree called “tags” • They are snapshots, of feature-complete code. Typically releases. • To learn more about this however, you’ll have to visit the git manpage or mr google
- 19. Milo proofs all my code