Raw Notes: DrupalCampNYC8 - Git with It: Drupal Development Done Better

Presented by Joshua Jabbour

Centralized Version Control

• Requires a central server where the repository lives
• In order to interact with the repository, you must have network access and contact the central server
• Actions must be communicated to the central repository in order to be recorded and versioned; can't commit remotely
• Once a change is committed, it cannot be safely edited; a second commit must be made to undo it
• Once you commit, everyone else can download your changes... even the bad ones
• These issues with centralized version control discourages people from using version control, committing frequently, etc

Decentralized Version Control

• No central server is required. Changes can be sent to or received from any repository at any time, or not sent or received at all.
• Most actions are local; changes only need to be shared with remote repositories as desired and when convenient
• As long as a commit hasn't been shared with anyone else, you can edit it or undo it at will
• Others have access to your changes only after you share them; your local history is therefore separate from the remote history.
• This is more conducive to using version control heavily, making frequent commits

Git Basics

• Getting Started
  • After installation, introduce yourself to git: git config --global user.name "Your Name"; git config --global user.email "youremail@here.com"
  • Download some GUI helpers like GitX or SmartGit
  • Referring to revisions: "ebc344db0404f0ee3a634d4889c101e869a8b419" is the full commit number but can be abbreviated to "ebc344"; HEAD is most recent commit in current branch, HEAD^ is commit before most recent one, HEAD^^^ or HEAD-3 are three commits back
• Working on your copy
  • The working copy is the files and folders in your project. It represents your project at a specific point in time.
  • But in Git, your working copy is also a full repository; this is where the magic happens, you have every single change that's been made right there within the history of your working copy.
  • git init - create your repository in the current directory; creates the .git folder within the current directory where your repository lives.
  • git add . - add all of the files in your working copy to your git repository
  • git commit -a -m "Your message here" - Commit all files to your git repository along with an explanatory message describing the commit.
  • git clone [url] - clone the entire specified repository
• Be committed
  • With Git, it's best to work in small bits
  • Rule of thumb: if you can't summarize your changes in a sentence, you've gone too long without committing
  • Think of your local git repo as YOURS, you can clean it up before sharing, meticulously document your work in small chunks
  • git status - what's been changed since your last commit
  • git diff
  • git commit -a - commit all updated files (already being tracked in your repository)
• Your Repository
  • Your local repo is yours and yours alone
  • You decide when and what to push to another repo
  • Commit early and commit often; you can always clean up your commit history before pushing
  • However, once a commit has been shared (especially with a central repository) it should be considered sacrosanct since someone else might have pulled down that commit already
• On Stage
  • The staging area (also referred to as the index) is a temporary holding area for changes
  • When a file or changeset is added to the staging area, it is not yet committed to the repository
  • The staging area allows you to build up your commit file by file or even line by line
  • git add file1 newfile folderA/file3 newfolder8 - fine-grained specification of what you want to add to the git repo for this commit
  • Demonstration of staging changes line by line using GitX; look into git add -p to do that from the command line
• Branching
  • Branching is one of Git's killer features, not because it's new but because it's so easy and cheap
  • Branching is a database, another path that we're working down
  • When working on features, always create a topical branch for the particular thing you're working on
  • Always working in your trunk/master branch is not a good idea
  • git branch - creates the branch
  • git checkout - switch to that branch
  • git checkout -b - create and switch to that branch
  • Branches aren't directories in Git; the working copy always contains the state of the active branch
  • Branches are really just pointers to a commit, as are tags
  • Branches let you separate out your work on a particular issue or feature from the master branch; you can do all of your work there, if it turns out to be worthwhile you merge it back into master, if it's not worthwhile you can blow it away (git branch -d ) and get rid of all those commits entirely
• Out on a Branch (Remote Branching)
  • Remote branches are similar to local branches, except that they can be shared across repositories
  • Remotes are referred to by [repo]/[branch]
  • Most collaborative open source software uses forked repos and shared branches
• Merging
  • Many merges can be done automagically by Git
  • git merge
  • Some merges will require human intervention with git mergetool
• Rebasing (All Your Rebase Are Belong To Us)
  • Rebasing is a primary function of Git: "redo my changes using another revision as a new base"
  • git rebase
  • In some ways it's similar to merging, but instead of adding your changes at the end of the stream, it puts them in place in the midst of a stream
  • Rebasing is done automatically every time you pull changes from another repository
  • Interactive rebasing (git rebase -i) allows you to alter your local commits, squash them into one for merging or pushing, etc
• Fetch and pull
  • When you want to get changes from another repo you fetch - git fetch or git fetch origin or git fetch [repo]
  • After fetching you merge the new commits into your local tree - git merge [repo]/branch
  • Pulling is a shortcut; fetch followed by an automatic merge - git pull or git pull origin or git pull [repo]
  • Pushing sends commits to a remote repo; should only be done with canoncial repos (if you want to share with other users' repos, usually you'll have them pull from yours instead - git push or git push [repo] [branch]
• Reset (didn't get covered)
• Gitify your Subversion
  • Git includes a built-in Subversion client
  • Use Git to control your local commits, then push them to a central SVN repo
  • A couple of things work differently, but you still have the full power of Git within your local repository
  • git svn clone [url] - check out SVN repo and put it in a new git repo on your machine
  • git svn dcommit - effectively a push to the SVN repo
  • git svn fetch - works like normal git fetch
  • git svn rebase - a fetch and then an apply (like git pull)
  • git config --global alias.spull '!git-svn rebase' (handy alias to make life easier)
• Git intermediate
  • Stash away your work for now - git stash or git stash --save "short note" - not a real commit
  • git cherry-pick [revision] - bring one commit from another branch into this one
  • Hashes everywhere - everything in Git is referenced by a SHA1 hash; tags, branch names, etc are really just shortcuts to them
• Git tools and resources displayed very quickly, guessing they'll be in slides or notes online!