This presentation gives an introduction to git and EGit was presented at the Belgian Eclipse User Group meeting of August 31th hosted by Inventive Designers.
2. Agenda About me Introduction to Git Demo Conclusions 8/31/2010 Inventive Designers – The output innovators 2
3. About me Nick Van den Bleeken R&D Manager at Inventive Designers Member of the XForms WG at W3C 8/31/2010 Inventive Designers – The output innovators 3
4. Survey Who is not using source control? SVN? CVS? Git? 8/31/2010 Inventive Designers – The output innovators 4
5. What is Git? Distributed Version Control System Scalable and Fast Non-linear, custom workflows Subversion-Style Workflow Integration Manager Workflow Dictator and Lieutenants Workflow … 8/31/2010 5 Inventive Designers – The output innovators
6. Git andEclipse EGit: Eclipse Team Provider for Git JGit: lightweight Java library implementing Git Eclipse is moving to Gitas SCM (ETA end 2010) 8/31/2010 6 Inventive Designers – The output innovators
7. Git vs SVN/CVS 8/31/2010 7 Inventive Designers – The output innovators Distributed (git) Centralized (CVS) Full local history Cheap local branching Fast Rebase patches easily Powerful merging No No Slow Patches go stale Merging is a pain
8. Git Basics (1) 8/31/2010 Inventive Designers – The output innovators 8 Stores data as snapshots, not differences (Images taken from http://progit.org/book)
9. Git Basics (2) Nearly every operation is local Git has integrity Git generally only adds data 8/31/2010 Inventive Designers – The output innovators 9
10. Git Basics (3) 8/31/2010 Inventive Designers – The output innovators 10 The staging area (Images taken from http://whygitisbetterthanx.com)
11. Git Typical usage 8/31/2010 Inventive Designers – The output innovators 11 Working directory Staging area Local repo remote repo git add git commit git push git fetch git checkout git merge
12. Branches and tags 8/31/2010 Inventive Designers – The output innovators 12 Branches Creating a branch is quick (write 41 bytes) Long running / Topic branches Tags Lightweight tag branch that doesn’t change Annotated tag Check summed Tagger info Tagging message Optionally signed (GNU Privacy Guard) (Images taken from http://progit.org/book)
13. rebase merge Merging Git determines the best common ancestor to use for its merge base (different than CVS) 8/31/2010 Inventive Designers – The output innovators 13 (Images taken from http://progit.org/book)
14. rebase Merging Git determines the best common ancestor to use for its merge base (different than CVS) 9/1/2010 Inventive Designers – The output innovators 14 (Images taken from http://progit.org/book)
16. Conclusion Git is very powerful Git is scalable and fast Git supports convenient branching and merging All revisions of every file are locally available Git is the feature SCM of Eclipse 8/31/2010 Inventive Designers – The output innovators 16
git doesn’t just checks out the latest snapshot of the files,but fully mirrors the repository. -> full backup Nearly every operation is localWorkflowSubversion-Style Workflow (centralized model where all developers push to the same server -> shared repository)Integration Manager Workflow (a single person who commits to the 'blessed' repository, and then a number of developers who clone from that repository, push to their own independent repositories)Dictator andLieutenants Workflow (Linux kernel -> people are in charge of a specific subsystem of the project and merge in all changes for that subsystem, nother integrator (the 'dictator') can pull changes from only his/her lieutenants and the push to the 'blessed' repository)
For example the Mozilla repository is reported to be almost 12 GiB when stored in SVN using the fsfs backend. Previously, the fsfs backend also required over 240,000 files in one directory to record all 240,000 commits made over the 10 year project history. This was fixed in SVN 1.5, where every 1000 revisions are placed in a separate directory. The exact same history is stored in Git by only two files totaling just over 420 MiB. SVN requires 30x the disk space to store the same history. An SVN working directory always contains two copies of each file: one for the user to actually work with and another hidden in .svn/ to aid operations such as status, diff and commit. In contrast a Git working directory requires only one small index file that stores about 100 bytes of data per tracked file. On projects with a large number of files this can be a substantial difference in the disk space required per working copy. As a full Git clone is often smaller than a full checkout, this means that Git working directories (including the repositories) are typically smaller than the corresponding SVN working directories. There are even ways in Git to share one repository across many working directories, but in contrast to SVN, this requires the working directories to be colocalized.
Most operations in Git only need local files and resources to operate — generally no information is needed from another computer on your network. (e.g.: browse the history of the project)Everything in Git is check-summed before it is stored and is then referred to by that checksum -> change on disk -> checksum fails => can’t lose information in transit or get file corruption without Git being able to detect it. (SHA-1)Git evens keeps your stashes (Stashing takes the dirty state of your working directory — that is, your modified tracked files and staged changes — and saves it on a stack of unfinished changes that you can reapply at any time.)
Git directory stores the metadata and object database for your project. This is the most important part of Git, and it is what is copied when you clone a repository from another computer.Working directory is a single checkout of one version of the project. These files are pulled out of the compressed database in the Git directory and placed on disk for you to use or modify.Staging area is a simple file, generally contained in your Git directory, that stores information about what will go into your next commit. It’s sometimes referred to as the index, but it’s becoming standard to refer to it as the staging area.
Creating a new branch is as quick (lightweight) and simple as writing 41 bytes to a file (40 characters SHA-1 checksum of commit and a newline)Long running branches / topic branches -> possible to rebase commits on other branch (e.g.: master)TagsLightweight tag: a branch that doesn’t change -> pointer to a hashAnnotated tag: stored as a full object (check summed; tagger name, e-mail, and date; tagging message; optionally signed and verified with GNU Privacy Guard (GPG))
Git determines the best common ancestor to use for its merge base; this is different than CVS, where the developer doing the merge has to figure out the best merge base for themselves.Two parents after merge -> knows who did what after merge (not the case in CVS)Integrate changes from one branch into another:MergeRebase -> re-apply changes ‘on C4’
Git determines the best common ancestor to use for its merge base; this is different than CVS, where the developer doing the merge has to figure out the best merge base for themselves.Two parents after merge -> knows who did what after merge (not the case in CVS)Integrate changes from one branch into another:MergeRebase -> re-apply changes ‘on C4’
Book translated into German, Chinese, Japanese and Dutch.GitHub is a web-based hosting service for projects that use the Git revision control system