KEMBAR78
git and github | PDF
git and github
darren oakley
disclaimer
• i use git daily in my work and manage to
  not have many problems
• i’ve been asked to share the basics i know
  with others
• i am not a git expert - i may (most
  probably) not be able to answer all of your
  questions
what we’ll cover

• brief discussion on version control
    - ‘traditional’ v’s distributed
• git - the basics
• github - the basics
what we won’t cover

• advanced git
 • rebase
 • sub-modules
• git-svn
version control
version control

• what most people are (probably) used to:
 • concurrent version system (cvs)
 • subversion (svn)
version control

• cvs and svn
 • central source control server
 • users check code into server
 • requires connection to the server to
    perform commits, updates etc.
distributed version
       control
• the new hotness...
 • git
 • mercurial (hg)
 • bazaar (bzr)
what’s the difference?
• not a lot really...
 • you store a complete copy of a
    repository within your working copy
   • this means you can work offline
 • there is no default ‘central’ server - if you
    want one, you (and your team) just
    nominate where it is (i.e. a github)
git
getting started

• move to a directory with code you’d like to
  manage with git:
 git init

• you’ve now created your first git
  repository!
normal workflow
local operations
working                  staging              git directory
directory                 area                (repsoitory)



                   checkout the project



            stage files



                                     commit
staging files
  git add [filenames]



• add all changed files to the staging area:
  git add .



• these changes are NOT committed yet
the git staging area

• git has a concept of a ‘staging area’
 • you first stage all of the changes that you
    are happy with
  • then you commit them
isn’t this more work?

• in short - yes
 • but it allows you to craft the exact
    commit you want - you eventually get to
    love this feature
• you can get around it if you like...
committing

git commit -m “commit message”


git commit -a -m “commit message”
branching / merging
branching

git branch
git branch [new branch name]
git checkout [new branch name]
merging

git checkout [target branch]
git merge [other branch]
git merge --squash [other branch]
rewriting history

  git rebase



• will leave that as an exercise for you to
  investigate...
remote operations
remote repositories


git push [repository] [repository branch]



git pull [repository] [repository branch]
remote operations
                                                                   user
                               repository
                                (github)

user one                                                       user



                                                      user
           repository
            (internal)


                         example - group using open source code internally with
                         modifications specific to them can easily push/pull from
user two
                         the project ‘master’
some rules i tend
to follow...
• NEVER pull when you have
  uncommitted changes - commit your
  work first

• if working on a feature, use a local
  branch, then this leaves the master
  open for other fixes

• NEVER rebase or amend commits
  that you have pushed
If you want it to work
     like cvs / svn
• simply...
 • ‘pull’ at the start of the day and at regular
    intervals (as often as you’d checkout your
    code in cvs/svn)
  • ‘push’ after every commit
github
github

• http://github.com
• popular git repository hosting site
• home to many open source projects:
 • ruby on rails, jquery to name two...
a quick hands-on
with github
the plan...

• get yourselves into pairs
• person 1:
 • create a repository
 • check in some code
 • add person 2 to project
the plan...
• person 2:
 • pull code from person 1’s repository
 • make some changes and push back to
    repository
• person 1:
 • pull these changes
the plan...

• somebody:
 • tag a release of the code
 • push this tag to github
 • stare in awe at the auto-generated tarball
if we have time...

• person 1:
 • create a local branch of the code
 • push this branch to github
• person 2:
 • pull and work with this remote branch
if we have more time


• simulate a conflict and resolve it
let’s get going...
person 1
person 2
git clone [paste ‘your clone url’]

edit something

add and commit
git push origin master
person 1
git pull origin master

see if you have the changes from your
partner
somebody
git tag rel_1.0

git push --tags
do we have time?
person 1
git branch new_feature_foo

git checkout new_feature_foo

edit something, add and commit
git push origin new_feature_foo
person 2
git remote show origin


git fetch origin new_feature_foo:new_feature_foo




git fetch [repo] [remote_branch]:[local_branch]
edit something, add and commit
git push origin new_feature_foo

cat .git/config
 - info on repository setup
simulating a conflict
person 1
without doing a git pull!

edit the file that person 2 just edited

save, add and commit changes
git push origin new_feature_foo

O_o ooops...
git pull origin new_feature_foo

(git will inform you of a conflict)

edit the file - resolve the conflict

git add, commit, push

conflict resolved! ^_^
further reading

• http://git-scm.com/documentation
• http://learn.github.com/
• http://help.github.com/
• http://www.gitready.com/
further reading
git config
some setup i find useful...
git config --global color.diff auto


git config --global color.status auto


git config --global color.branch auto


git config --global color.interactive auto
git config --global alias.st status


git config --global alias.ci commit


git config --global alias.co checkout


git config --global alias.br branch
git config --global core.excludesfile ~/.gitignore


echo "*~" >~/.gitignore


echo ".DS_Store" >>~/.gitignore

git and github

  • 1.
  • 2.
    disclaimer • i usegit daily in my work and manage to not have many problems • i’ve been asked to share the basics i know with others • i am not a git expert - i may (most probably) not be able to answer all of your questions
  • 3.
    what we’ll cover •brief discussion on version control - ‘traditional’ v’s distributed • git - the basics • github - the basics
  • 4.
    what we won’tcover • advanced git • rebase • sub-modules • git-svn
  • 5.
  • 6.
    version control • whatmost people are (probably) used to: • concurrent version system (cvs) • subversion (svn)
  • 7.
    version control • cvsand svn • central source control server • users check code into server • requires connection to the server to perform commits, updates etc.
  • 8.
    distributed version control • the new hotness... • git • mercurial (hg) • bazaar (bzr)
  • 9.
    what’s the difference? •not a lot really... • you store a complete copy of a repository within your working copy • this means you can work offline • there is no default ‘central’ server - if you want one, you (and your team) just nominate where it is (i.e. a github)
  • 10.
  • 11.
    getting started • moveto a directory with code you’d like to manage with git: git init • you’ve now created your first git repository!
  • 12.
  • 13.
    local operations working staging git directory directory area (repsoitory) checkout the project stage files commit
  • 14.
    staging files git add [filenames] • add all changed files to the staging area: git add . • these changes are NOT committed yet
  • 15.
    the git stagingarea • git has a concept of a ‘staging area’ • you first stage all of the changes that you are happy with • then you commit them
  • 16.
    isn’t this morework? • in short - yes • but it allows you to craft the exact commit you want - you eventually get to love this feature • you can get around it if you like...
  • 17.
    committing git commit -m“commit message” git commit -a -m “commit message”
  • 18.
  • 19.
    branching git branch git branch[new branch name] git checkout [new branch name]
  • 20.
    merging git checkout [targetbranch] git merge [other branch] git merge --squash [other branch]
  • 21.
    rewriting history git rebase • will leave that as an exercise for you to investigate...
  • 22.
  • 23.
    remote repositories git push[repository] [repository branch] git pull [repository] [repository branch]
  • 24.
    remote operations user repository (github) user one user user repository (internal) example - group using open source code internally with modifications specific to them can easily push/pull from user two the project ‘master’
  • 25.
    some rules itend to follow...
  • 26.
    • NEVER pullwhen you have uncommitted changes - commit your work first • if working on a feature, use a local branch, then this leaves the master open for other fixes • NEVER rebase or amend commits that you have pushed
  • 27.
    If you wantit to work like cvs / svn • simply... • ‘pull’ at the start of the day and at regular intervals (as often as you’d checkout your code in cvs/svn) • ‘push’ after every commit
  • 28.
  • 29.
    github • http://github.com • populargit repository hosting site • home to many open source projects: • ruby on rails, jquery to name two...
  • 30.
  • 31.
    the plan... • getyourselves into pairs • person 1: • create a repository • check in some code • add person 2 to project
  • 32.
    the plan... • person2: • pull code from person 1’s repository • make some changes and push back to repository • person 1: • pull these changes
  • 33.
    the plan... • somebody: • tag a release of the code • push this tag to github • stare in awe at the auto-generated tarball
  • 34.
    if we havetime... • person 1: • create a local branch of the code • push this branch to github • person 2: • pull and work with this remote branch
  • 35.
    if we havemore time • simulate a conflict and resolve it
  • 36.
  • 37.
  • 43.
  • 45.
    git clone [paste‘your clone url’] edit something add and commit git push origin master
  • 46.
  • 47.
    git pull originmaster see if you have the changes from your partner
  • 48.
  • 49.
  • 52.
  • 53.
  • 54.
    git branch new_feature_foo gitcheckout new_feature_foo edit something, add and commit git push origin new_feature_foo
  • 55.
  • 56.
    git remote showorigin git fetch origin new_feature_foo:new_feature_foo git fetch [repo] [remote_branch]:[local_branch]
  • 57.
    edit something, addand commit git push origin new_feature_foo cat .git/config - info on repository setup
  • 59.
  • 60.
  • 61.
    without doing agit pull! edit the file that person 2 just edited save, add and commit changes git push origin new_feature_foo O_o ooops...
  • 62.
    git pull originnew_feature_foo (git will inform you of a conflict) edit the file - resolve the conflict git add, commit, push conflict resolved! ^_^
  • 63.
    further reading • http://git-scm.com/documentation •http://learn.github.com/ • http://help.github.com/ • http://www.gitready.com/
  • 64.
  • 65.
    git config some setupi find useful...
  • 66.
    git config --globalcolor.diff auto git config --global color.status auto git config --global color.branch auto git config --global color.interactive auto
  • 67.
    git config --globalalias.st status git config --global alias.ci commit git config --global alias.co checkout git config --global alias.br branch
  • 68.
    git config --globalcore.excludesfile ~/.gitignore echo "*~" >~/.gitignore echo ".DS_Store" >>~/.gitignore