Your SlideShare is downloading. ×
Git and eclipse
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Git and eclipse

1,597

Published on

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.

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.

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,597
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
31
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • 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
  • Transcript

    • 1. Git
      Can GIT make your life easier?
      8/31/2010
    • 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)
    • 15. Inventive Designers – The output innovators
      Demo
      EGitand Gerrit
      15
    • 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
    • 17. EGit Features
      8/31/2010
      Inventive Designers – The output innovators
      17
      git rebase
      • git remote
      git pull
    • Resources
      Gitdocumentation http://git-scm.com/documentation
      Pro Git book http://progit.org/book
      EGitUser Guide http://wiki.eclipse.org/EGit/User_Guide
      GitHubhttps://github.com/
      8/31/2010
      Inventive Designers – The output innovators
      18
    • 33. Inventive Designers – The output innovators
      Questions?
      19

    ×