The document provides an overview of version control systems and introduces Git and GitHub. It discusses the differences between centralized and distributed version control. It then covers the basics of using Git locally including initialization, staging files, committing changes, branching and merging. Finally, it demonstrates some common remote operations with GitHub such as pushing, pulling and tagging releases.
2. 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
3. what we’ll cover
• brief discussion on version control
- ‘traditional’ v’s distributed
• git - the basics
• github - the basics
4. what we won’t cover
• advanced git
• rebase
• sub-modules
• git-svn
6. version control
• what most people are (probably) used to:
• concurrent version system (cvs)
• subversion (svn)
7. version control
• cvs and 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)
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 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
16. 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...
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’
26. • 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
27. 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
31. the plan...
• get yourselves into pairs
• person 1:
• create a repository
• check in some code
• add person 2 to project
32. the plan...
• person 2:
• 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 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
35. if we have more time
• simulate a conflict and resolve it