Bang a Gong, GIT It On, or Running Drupal With a GIT Repository (11/04/20 - B Gruneberg))

  • 770 views
Uploaded on

Enjoy a technical overview of working with a GIT repository, its advantages and benefits, and how to set it up.

Enjoy a technical overview of working with a GIT repository, its advantages and benefits, and how to set it up.

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
770
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
0
Comments
0
Likes
0

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

Transcript

  • 1. Welcome to: GIT … and Drupal sitting in a Tree ( yes – the data-structure ) A DrupalCape Presentation by: Perceptum Thought Squad 20/Apr/2011 Presenter: Bryan Gruneberg
  • 2. Our Journey
    • “ One Good Thief is Worth Ten Good Scholars” – Randy Pausch
    • 3. About GIT
      • The Linus Legacy
    • Understanding GIT
    • Drupal & GIT
      • drupal.org
      • 7. What Perceptum Does
      • 8. Why CI makes sense
    20/Apr/2011 Presenter: Bryan Gruneberg
  • 9. One Good Thief is Worth Ten Good Scholars the pretty pics end here... ;) Checked out “Randy Pausch on Time Management” YouTube: http://bit.ly/fWwEFF
    • http://hvrd.me/ePlh64 - Understanding Git Conceptually
    • 10. http://vimeo.com/20459209 - Using Git on Drupal.org
    20/Apr/2011 Presenter: Bryan Gruneberg
  • 11. About GIT
    • Git development began after many Linux kernel developers chose to give up access to the proprietary BitKeeper system
    • 12. Take CVS as an example of what not to do; if in doubt, make the exact opposite decision
    • 13. Support Distributed Version Control
    • 14. Strong safeguards against corruption
    • 15. HIGH PERFORMACE
    • 16. Design is a synthesis of Linus' experiences in maintaining a large distributed development project
    20/Apr/2011 Presenter: Bryan Gruneberg
  • 17. What's in a name??
    • Quoting Linus: "I'm an egotistical ***, and I name all my projects after myself. First 'Linux', now 'git'".
    • 18. Alternatively "git" can mean anything, depending on your mood:
      • Random three-letter combination that is pronounceable, and not actually used by any common UNIX command. The fact that it is a mispronunciation of "get" may or may not be relevant.
      • 19. Stupid. Contemptible and despicable. Simple. Take your pick from the dictionary of slang.
      • 20. "Global information tracker": you're in a good mood, and it actually works for you. Angels sing and light suddenly fills the room.
      • 21. "Goddamn idiotic truckload of sh*t": when it breaks
    20/Apr/2011 Presenter: Bryan Gruneberg
  • 22. GIT Characteristics
    • Strong support for non-linear development
    • 23. Distributed development
    • 24. Compatibility with existing systems/protocols (HTTP, FTP, RSYNC, SSH)
    • 25. Efficient large projects (does not get slower as the project history grows)
    • 26. Cryptographic authentication of history
      • Once published, not possible to change old versions secretly
    • Toolkit-based design (C & Sh => C)
    • 27. Pluggable merge strategies (attempted merge 1,2...,n => error)
    • 28. Periodic explicit object packing
      • Each newly created object as a file
      • 29. Packing similar files together
      • 30. Periodic packing done by GIT... or “git gc –prune” to force
    20/Apr/2011 Presenter: Bryan Gruneberg
  • 31. Understanding GIT
    • Many resources on Git walk you through which commands to run when, and expect that you should do fine if you just mimic those commands
    • 32. The other half does go through all the concepts, but they explain Git in a manner that assumes you already understand how Git works
    • 33. Merely memorizing which commands you should run at what times will work in the short run (SO DO IT!!!)
    • 34. But it’s only a matter of time before you get stuck or break something... so here is an overview of what happens inside the big-black-git-box...
    20/Apr/2011 Presenter: Bryan Gruneberg
  • 35. Repositories Important things to know...
    • GIT Repositories contain a set of commit objects
      • A set of files, reflecting the state of a project at a given point in time.
      • 36. References to parent commit objects.
      • 37. An SHA1 name, a 40-character string that uniquely identifies the commit object
    • GIT Repositories contain a set of references to commit objects
      • called heads
    20/Apr/2011 Presenter: Bryan Gruneberg
  • 38. Graphically... 20/Apr/2011 Presenter: Bryan Gruneberg
  • 39. Wordy...
    • A blob object is the content of a file.
      • Blob objects have no filename, timestamps, or other metadata.
    • A tree object is the equivalent of a directory.
      • Contains a list of filenames and the name of a blob or tree object that is that file, symbolic link, or directory's contents.
      • 40. This object describes a snapshot of the source tree.
    • A commit object links tree objects together into a history.
      • Contains
        • the name of a tree object (of the top-level source directory),
        • 41. a timestamp,
        • 42. a log message, and
        • 43. the names of zero or more parent commit objects
    • A tag object is a container that contains reference to another object and can hold additional meta-data related to another object.
      • Generally used to store a digital signature of a commit object corresponding to a particular release of the data being tracked by Git.
    20/Apr/2011 Presenter: Bryan Gruneberg
  • 44. More on commit objects (yes – that important...)
    • Parent commit objects are those commits that were edited to produce the subsequent state of the project.
    • 45. A project always has one commit object with no parents. This is the first commit made to the project repository (initial commit)
    • 46. You can visualize a repository as a directed acyclic graph of commit objects
      • pointers to parent commits always pointing backwards in time
      • 47. Starting from any commit, you can walk along the tree by parent commits to see the history of changes that led to that commit.
    • So... NB: GIT version control is all about manipulating this graph of commits
      • Whenever you want to perform an operation to query or manipulate the repository, you should be thinking, “how do I want to query or manipulate the graph of commits?”
    20/Apr/2011 Presenter: Bryan Gruneberg
  • 48. Don't lose your head...
    • A “head” is a reference to a commit object
    • 49. Each head has a name
      • By default, there is a head in every repository called master
      • 50. A repository can contain any number of heads
      • 51. At any given time, one head is selected as the “current head”
        • aliased to HEAD, all-caps.
    • **NB**
      • “ head” (lowercase) refers to any one of the named heads in the repository
      • 52. “ HEAD” (uppercase) refers exclusively to the currently active head
      • 53. This is used seen in Git documentation, and isn't always explicitly explained
    20/Apr/2011 Presenter: Bryan Gruneberg
  • 54. Looks like this... 20/Apr/2011 Presenter: Bryan Gruneberg
  • 55. Branching Scenario...
    • You build a Drupal theme
    • 56. You commit the theme code, and let customers review
    • 57. While they review, you carry on with new functionality
    • 58. They revert and ask that all <span class=header> tags to be changed to <h4> tags
    • 59. You want to fix the code for them, but you don't want them to have access to the half-baked new feature code
    20/Apr/2011 Presenter: Bryan Gruneberg
  • 60. Branching... 20/Apr/2011 Presenter: Bryan Gruneberg
  • 61. Branching... result 20/Apr/2011 Presenter: Bryan Gruneberg
  • 62. Merging
    • Once you are done working on a branch, you often want to bring those changes into a main stream of development
    • 63. Git merge
    20/Apr/2011 Presenter: Bryan Gruneberg
  • 64. Collaborating GIT allows you to share repository data from other developers
    • Git clone <repository>
    • 65. Git pull
    • 66. NB
      • YOU WILL HAVE THE ENTIRE HISTORY
    20/Apr/2011 Presenter: Bryan Gruneberg
  • 67. Collaborating... GIT allows you to share repository data with other developers
    • git push
    • 68. Essentially this is...
      • Pushing your changes to the remote
      • 69. Setting the remote-head to the remote head the pushing-repository referred to
    • If no arguments are given to git push, it will push all the branches in the repository that are set up for tracking.
    20/Apr/2011 Presenter: Bryan Gruneberg
  • 70. Drupal & GIT
    • Drupal used to use CVS (eeugh)
    • 71. Drupal now uses GIT (yay)
    • 72. Drupal.org account integrated with git account
    • 73. Drupal.org projects are all git repositories
    • 74. Drupal core is in GIT
    20/Apr/2011 Presenter: Bryan Gruneberg
  • 75. drupal.org & SSH Keys
    • Drupal.org now uses SSH Keys
      • Create keys (ssh-keygen / puttygen)
      • 76. Only share .pub!!!
      • 77. KEEP THE OTHER SECRET... SECRET!
    • You can then...
      • Create new Drupal projects (modules)
      • 78. Contribute to modules where you have been given access
    20/Apr/2011 Presenter: Bryan Gruneberg
  • 79. What Perceptum does... 20/Apr/2011 Presenter: Bryan Gruneberg
  • 80. Why CI Makes Sense 20/Apr/2011 Presenter: Bryan Gruneberg