Git Acquainted
Upcoming SlideShare
Loading in...5
×
 

Git Acquainted

on

  • 1,687 views

An overview of version control with a brief introduction to the basics of Git.

An overview of version control with a brief introduction to the basics of Git.

Statistics

Views

Total Views
1,687
Views on SlideShare
1,685
Embed Views
2

Actions

Likes
2
Downloads
20
Comments
0

2 Embeds 2

http://devoh.com 1
http://www.slideshare.net 1

Accessibility

Categories

Upload Details

Uploaded via as Apple Keynote

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • My hope tonight is to give you an introduction to version control with Git.
  • I’m Tyler Hunt, and @tylerhunt on Twitter.
  • I have a little blog and software company called Devoh.
  • Before we jump into talking about git, I want to first take a step back.
  • I want to start off talking a bit about version control. <br /> Why is it important? Why should you use it?
  • So you don&#x2019;t have to have files like this lying around.
  • It keeps a history of all of the changes ever made to your files. <br /> If you need to revert back to an old version, or figure out why something was changed, the history is always there for you.
  • And if you&#x2019;re working in a team, even if it&#x2019;s just two people, version control is a must. <br /> It&#x2019;s the best way to synchronize your development efforts. <br /> It&#x2019;s also a great way to keep an audit trail of who made which changes.
  • A repository is a complete collection of all of the files in a project and their full version history.
  • A branch is a way to duplicate the resources in a repository to allow parallel modifications to be made. This lets you start on a feature, and then switch branches to work on something else. Also, used to maintain separate development and production branches.
  • RCS, Revision Control System, was an early attempt at version control that only worked with individual files. CVS, Concurrent Versions System, was originally devised as a set of scripts on top of RCS to allow multiple files to be managed.
  • Subversion was designed as a mostly-compatible replacement for CVS. <br /> It fixed some of the limitations of CVS, like it&#x2019;s lack of knowledge about directories.
  • Git was created by Linus Torvalds as a replacement for BitKeeper, which was the version control software used for the Linux kernel at the time.
  • The reason Linus even thought about creating a new version control system was over a licensing change with BitKeeper that meant it was no longer free for kernel developers to use. <br /> An open source solution prevents this from happening.
  • Git&#x2019;s biggest advantages over Subversion is its distributed nature. <br /> With Git, there&#x2019;s no longer a single master repository, but all repositories are equal.
  • Without a centralized repository, there&#x2019;s an implicit layer of redundancy. <br /> If the repository on the server is corrupted, you can simple copy up your local repository.
  • Git was designed to be fast for non-linear development styles. <br /> It makes it trivial to create and change branches.
  • Let&#x2019;s jump in now and show how its used. <br /> I&#x2019;m not going to cover installation since it varies depending on your platform.
  • First, we&#x2019;ll make a new directory for our project. <br /> Then we&#x2019;ll switch to that directory and initialize a new repository there. <br /> This creates a .git directory inside our project where all of the metadata will be stored.
  • Here we create a new file, and then check the status of our repository. <br /> The output of `git status` shows that there&#x2019;s one &#x201C;untracked&#x201D; file. <br /> It also tells us how we can start tracking that file.
  • Here, we&#x2019;ve added the file to the repository, and then checked its status again. <br /> The file has been added to what&#x2019;s called the &#x201C;index.&#x201D; This is like a staging area for commits. <br /> Now that the file has been added, we can do the actual commit.
  • Here we commit the contents of the index using a command line argument for the commit message. Leave off the message will open an editor where you can write your message. <br /> Now our working directory is clean, meaning all of our changes have been committed.
  • We we make changes, git will let us know which files have been modified. <br /> Doing a `git diff` shows the modifications that have been made since the last commit. <br /> It&#x2019;s a good idea to review your changes before adding and committing.
  • Now let&#x2019;s take a look at branching and merging. <br /> Branches are a way to isolate the changes you&#x2019;re making from the rest of the project. <br /> It&#x2019;s a good practice to create a branch for each new task.
  • `git branch` show us all of the local branches in our repository. <br /> `git checkout -b` will create a new branch and switch to it. <br /> `git checkout` will switch branches.
  • Now let&#x2019;s switch back to our documentation branch and write some more documentation. <br /> Then we&#x2019;ll commit our changes. Next, we&#x2019;ll switch back to master and merge them in. <br /> Normally you wouldn&#x2019;t do the merge until the code is complete, tested, and ready to deploy.
  • `git log` will show us the history of all of our commits on the current branch. <br /> As you can see here, the commit from our documentation branch is now on master. <br /> Merging is like copying all of the new commits from one branch into another.
  • GitHub is a social network for coding. <br /> It&#x2019;s a web service providing hosted git repositories, with a focus on ease of collaboration.
  • We&#x2019;re going to use GitHub to create a new repository for our project. <br /> You can create as many public repositories as you like for free.
  • Once the repository has been created, you&#x2019;ll get a screenful of instructions. <br /> Here are the steps they give for pushing your local repository up for the first time. <br /> Remotes are simply non-local repositories. Pushing to a remote syncs it up with your local.
  • Once you&#x2019;ve pushed the code up to GitHub, it&#x2019;s easy for anyone else to work with it. <br /> `git clone` is used to make a local copy of a remote repository. <br /> Here, we&#x2019;re cloning our newly created GitHub repository using it&#x2019;s public clone URL.
  • The social power of GitHub is really manifested in the fork feature. <br /> This creates a clone of someone else&#x2019;s repository under your own account. <br /> You can then work on it, push up your changes, and then submit a &#x201C;pull request.&#x201D;
  • This is where you&#x2019;ll set up the name and email address that identifies you as a comitter. <br /> GitHub will also use this to identify match up your commits with your GitHub account. <br /> You can also create aliases here for git commands, like &#x201C;stat&#x201D; for &#x201C;status.&#x201D; Helpful for SVN.
  • Each repository can have a .gitignore file in its root. <br /> This file specifies paths and file names that you want to leave out of the repository. <br /> Temporary files and configuration files containing authentication credentials.
  • You can also tag specific commits in your repository. <br /> This is useful for marking a commit as a release of a new version of your application. <br /> It might also be used to mark when your repository was last deployed.

Git Acquainted Git Acquainted Presentation Transcript

  • Git Acquainted An introduction to version control with Git
  • Tyler Hunt @tylerhunt
  • homegrown apps
  • −−− git +++
  • Version Control
  • index.html.bak.4
  • History
  • Collaboration
  • Basic Concepts
  • Repository
  • Branch
  • History
  • RCS & CVS Mid 80s
  • Subversion Early Aughts
  • Git Mid Aughts
  • Open Source
  • Distributed
  • Redundant
  • Non-linear
  • Basics
  • > mkdir project > cd project > git init Initialized empty Git repository in /project/.git/
  • > touch README > git status # On branch master # # Initial commit # # Untracked files: # (use "git add <file>..." to include in what will be committed) # # README nothing added to commit but untracked files present (use "git add" to track)
  • > git add README > git status # On branch master # # Initial commit # # Changes to be committed: # (use "git rm --cached <file>..." to unstage) # # new file: README #
  • > git commit -m ‘Added file for documentation.’ [master (root-commit) 63b94ad] Added file for documentation. 0 files changed, 0 insertions(+), 0 deletions(-) create mode 100644 README > git status # On branch master nothing to commit (working directory clean)
  • > echo ‘Documentation’ > README > git status # On branch master # Changed but not updated: # (use "git add <file>..." to update what will be committed) # (use "git checkout -- <file>..." to discard changes in working directory) # # modified: README # no changes added to commit (use "git add" and/or "git commit -a") > git diff README diff --git a/README b/README index e69de29..c3f01bd 100644 --- a/README +++ b/README @@ -0,0 +1 @@ +Documentation > git commit -m 'Updated documentation.' [master a382e49] Updated documentation. 1 files changed, 1 insertions(+), 0 deletions(-)
  • Branching
  • > git branch * master > git checkout -b documentation Switched to a new branch "documentation" > git branch * documentation master > git checkout master Switched to branch "master" > git branch documentation * master
  • > git checkout documentation Switched to branch "documentation" > echo ‘More Documentation’ >> README > git commit README -m ‘Wrote more documentation.’ [documentation fbe3fdd] Wrote more documentation. 1 files changed, 1 insertions(+), 0 deletions(-) > git checkout master Switched to branch "master" > git merge documentation Updating a382e49..fbe3fdd Fast forward README | 1 + 1 files changed, 1 insertions(+), 0 deletions(-)
  • > git log commit fbe3fdd6c09f2de540866108348bb33b7ee6b620 Author: Tyler Hunt <tyler@tylerhunt.com> Date: Wed Dec 2 23:30:32 2009 -0500 Wrote more documentation. commit a382e49c9dadaff6b65a948a7736367391a0c625 Author: Tyler Hunt <tyler@tylerhunt.com> Date: Wed Dec 2 23:29:17 2009 -0500 Updated documentation. commit 63b94ad5c0c035d915370b5101af22bc1270b5a9 Author: Tyler Hunt <tyler@tylerhunt.com> Date: Wed Dec 2 00:23:20 2009 -0500 Added file for documentation.
  • > cat README | sed -e 's/More/Less/' > README > git commit README -m ‘Less is more.’ [master 80e7a3b] Less is more. 1 files changed, 1 insertions(+), 1 deletions(-) > git checkout documentation Switched to branch "documentation" > cat README | sed -e 's/More/More and More/' > README > git commit README -m ‘More is more.’ [documentation ed8b839] More is more. 1 files changed, 1 insertions(+), 1 deletions(-) > git checkout master Switched to branch "master" > git merge documentation Auto-merging README CONFLICT (content): Merge conflict in README Automatic merge failed; fix conflicts and then commit the result.
  • > git stat README: needs merge # On branch master # Changed but not updated: # (use "git add <file>..." to update what will be committed) # (use "git checkout -- <file>..." to discard changes in working directory) # # unmerged: README # no changes added to commit (use "git add" and/or "git commit -a") > cat README Documentation <<<<<<< HEAD:README Less Documentation ======= More and More Documentation >>>>>>> documentation:README > vi README
  • > git add README > git commit [master 29c758b] Merge branch 'documentation'
  • > git log commit 29c758b5e64b5a7c4a8ecc1776e1a124236c6257 Merge: 80e7a3b ed8b839 Author: Tyler Hunt <tyler@tylerhunt.com> Date: Wed Dec 2 23:46:08 2009 -0500 Merge branch 'documentation' Conflicts: README commit ed8b83965b9b089c6a354c40883c602d288a6e4a Author: Tyler Hunt <tyler@tylerhunt.com> Date: Wed Dec 2 23:42:56 2009 -0500 More is more. commit 80e7a3b3ccc3e0714e8ab9108e3d3ac3a1e175bb Author: Tyler Hunt <tyler@tylerhunt.com> Date: Wed Dec 2 23:42:01 2009 -0500 Less is more.
  • Collaborating
  • > git remote add origin git@github.com:tylerhunt/project.git > git push origin master Counting objects: 18, done. Delta compression using 2 threads. Compressing objects: 100% (6/6), done. Writing objects: 100% (18/18), 1.38 KiB, done. Total 18 (delta 1), reused 0 (delta 0) To git@github.com:tylerhunt/project.git * [new branch] master -> master
  • > git clone git://github.com/tylerhunt/relax.git Initialized empty Git repository in /project/.git/ remote: Counting objects: 18, done. remote: Compressing objects: 100% (6/6), done. remote: Total 18 (delta 1), reused 0 (delta 0) Receiving objects: 100% (18/18), done. Resolving deltas: 100% (1/1), done.
  • Tips
  • ~/.gitconfig
  • .gitignore
  • Tags
  • Questions