A small presentation for developers with good SVN knowledge that are going to working with Git. The presentation also contains an example of repository creation on github and a simple scenario of collaboration between two developers

1. From SVN to Git
with a pinch of GitHub
Marco De Stefano
"

2. SVN features
 Centralized version control
 Commit as atomic operation
 Versioning mantained for directories and le metadata
 Client/Server protocol sends diffs
✘ Renaming of les causes loss of the history
✘ .svn directories in the whole project
✘ Lack of management tools (e.g. deleting part of the history)

3. SVN commands
 >svn checkout (co)
 >svn commit (ci)
 >svn status (st)
 >svn update
 >svn revert
 >svn add/rm
 >svnadmin create
 …

4. Centralized vs. Distributed version control
 “Centralized VCS systems are designed with the intent that there is One
True Source that is Blessed, and therefore Good. All developers work
(checkout) from that source, and then add (commit) their changes, which
then become similarly Blessed.”
 “Distributed VCS systems are designed with the intent that one repository
is as good as any other, and that merges from one repository to another
are just another form of communication. Any semantic value as to which
repository should be trusted is imposed from the outside by process, not
by the software itself.”
 “The real choice between using one type or the other is organizational - if
your project or organization wants centralized control, then a DVCS is a
non-starter. If your developers are expected to work all over the country/
world, without secure broadband connections to a central repository, then
DVCS is probably your salvation. If you need both, you're fu***d.”

5. Centralized vs. Distributed version control

6. Centralized vs. Distributed version control

7. Git features
 Distributed version control
 Strong support for non-linear development (branches and merges)
 Efficient handling of large projects (e.g. Linux Kernel)
 Pluggable merge strategies
 .git directory in project root
✘ More disk space required
✘ Not for Windows  (but there is a native porting, msysgit)

8. Git commands
 >git init
 Creates a .git subdirectory in your project
 Your working directory becomes a git repository
You use git init to make an existing directory of content into a new Git repository.
You can do this in any directory at any time, completely locally

9. Git commands
 >git clone <url> [path]
 Copies a project in your working directory
 It copies all the project history locally
 You will get a directory with the main branch of the project
You use git clone to get a local copy of a Git repository

10. Git commands
 >git add [ lepattern…]
 Adds le contents to your staging area
 Used for new les and modi cations to existing les
 Possible to skip this operation (with commit –a option)
You use git add to start tracking les and to stage changes to already tracked les
i.e. whenever you want to include le changes in the next commit

11. Git commands
 >git status [-s]
 Shows the status of the les (working directory and staging area)
 Gives context and hints – displays which (but not how) les changed
 -s option gives short output (with no hints – similar to svn st)
You use git status to see if anything has been modi ed and/or staged since the
last commit

12. Git commands
 >git diff [--cached / HEAD] [--stat] [ lepath]
 Shows a patch of content changed since last commit and not yet staged
 --cached option shows the staged changes, HEAD shows both staged and
unstaged changes
 --stat option gives short output
You use git diff to see how (line by line) les have been modi ed and/or staged
since the last commit

13. Git commands
 >git commit [-a] [-m ‘commit message’]
 Records a snapshot of the staging area in the current branch
 -a option adds to the snapshot all the unstaged changes
 -m option allows to insert the commit message directly
You use git commit to record a snapshot of the staged changes. This snapshot can
then be compared, shared and reverted to, if you need to

14. Git commands
 >git reset [--hard] <HEAD/commit> [-- les…]
 Unstages changes that have been staged
 With --hard options, the repository changes to the last commit state
 Possible to unstage single les
You use git reset HEAD to unstage les previously staged with git add, to avoid
including them in the next commit

15. Git commands
 >git rm [--cached] [ les…]
 Removes les from the staging area – and from the working directory
 --cached option allows to retain the le in the working directory
You use git rm to remove les from being tracked in Git

16. Git commands
 >git mv <source> <destination>
 Has the same behaviour of:
 >git rm --cached <source>
 >mv <source> <destination>
 >git add <destination>
You use git mv to rename les under version control

17. Git commands
 >git branch [-d <branchname>] [branchname]
 A branch is a context where you can switch
 Without arguments, it lists out the local branches and points out the current
one
 With a branch name, it creates a new branch – the default one is named master
 -d option will delete branchname
You use git branch to list current branches, create new branches and delete
unnecessary branches

18. Git commands
 >git checkout [[-b] <branchname>]/ [-- les…]
 Swithces to branchname
 -b option will create branchname and switch immediately to it
 -- followed by one or more les, reverts the content of these les to the
last commit state
You use git checkout to switch among branches, optionally creating them; you
also use it to revert the data of any le to the last commit

19. Git commands
 >git merge <branchname>
 Merges the diffs between the current branch and branchname into the
current one
 The branch branchname doesn’t change
You use git merge to combine another branch context into the current one

20. Git commands
 >git log [--oneline] [--graph] [--decorate] [branchname]
 Shows commit history of branchname (the current one if not speci ed)
 The --oneline options shows only the rst row of the commit message
 The --graph option shows a graph of branches and merges
 The --decorate option shows information on branches involved in merges
You use git log to list out the commit history

21. Git commands
 >git remote [-v] [add <url> <alias>]/[rm <alias>]
 Lists the remote repository aliases stored, -v options also shows the urls
 Possible to have different push and fetch urls
 add allows to add the repository at url under the local-remote alias
 rm allows to remove the alias local-remote
You use git remote to list out the remote repositories and the urls they’re using.
You can also add and remove local-remote repositories

22. Git commands
 >git fetch <alias/--all>
 Downloads branches and data from a remote repository
 --all option allows to download data from all remote repositories
 Cannot checkout a remote repository
You use git fetch to synchronize your repository with a remote repository,
fetching all the data not already existing in your local repository

23. Git commands
 >git pull <alias>/<--all>
 Fetches from a remote repository and tries to merge it into the current branch
 Has the same behaviour of:
 >git fetch <alias>
 >git merge <alias>
You use git pull to synchronize your repository with a remote repository, fetching
all the data not already existing in your local repository and merging it into the
current branch

24. Git commands
 >git push <alias> [branch]
 Pushes local branches and data to a remote repository
 If no branch is speci ed, the current branch is used
 The local branch to push has to be up-to-date
You use git push to update a remote repository with changes made locally

25. Git commands
 >git revert [-n] <HEAD/commit>
 Reverts the contents of the current branch to the commit state
 It makes a new commit on the current branch!
 With -n options the data is reverted and isn’t committed
You use git revert to revert the data in the current branch to a speci ed state

26. Git commands
 >git stash <save/pop>
 Allows to record the current state of the working directory
 Doesn’t make a commit
 Save allows to create a stash, pop puts the stashed changes back on the
working directory
You use git stash to temporarily stash (and afterwords recover) the data in the
current branch, e.g to proceed with a pull request

27. Tips
 Enable console colors
 >git con g --global color.diff auto
 >git con g --global color.status auto
 >git con g --global color.branch auto
 Set name and email
 >git con g --global user.name <Name and Surname>
 >git con g --global user.email <email>
 Set aliases for commands, e.g.:
 >git con g --global alias.history ‘log --oneline --graph --decorate’
 >git con g --global alias.st ‘status -s’
 >git con g --global alias.ci ‘commit -m’
 >git con g --global alias.co checkout

28. GitHub
 Web-based hosting service for software
development projects that use Git
 Possible to have public repositories (free if they
require less than 300MB)

29. GitHub – Create a repo

30. GitHub – Create a repo
 >mkdir help-example
 >cd help-example
 >git init
 >touch README
 >git commit -a –m ‘ rst commit’
 >git remote add origin git@github.com:tekkub/help-
example.git
 >git push origin master

31. GitHub – Push data
 I can’t push, “Permission denied (public key)”
 To push data, you have to set up a pair of SSH keys,
and add your public key in the account options on
GitHub
 You can also con gure your GitHub account locally:
 >git con g --global github.user <username>
 >git con g --global github.token <token>
 You can nd your token under your GitHub account
settings

32. A simple scenario
 Alice created her repo, test, on github (see previous
slides), containing these les:
 README foo.txt bar.txt test.c
 Bob joins her – and he has write access to the
repository:
 >git clone git@github.com/alice/test.git test
 Bob works locally, and makes a branch:
 >cd test
 >git checkout –b text-changes
 Now he has 2 branches: master and text-changes

33. A simple scenario
 Bob modi es foo.txt and bar.txt; after that he runs:
 >git add foo.txt
 >git status –s
 M bar.txt
 M foo.txt
 The le bar.txt has been modi ed but not already
staged; however Bob runs:
 >git commit –a –m ‘modified txt files’
 >git status –s gives no output
 These les have been modi ed only in text-changes
branch

34. A simple scenario
 Bob wants to modify test.c in a new branch, without
having the *.txt les modi ed
 >git checkout master
 >git branch src-changes
 >git checkout src-changes
 Bob modi es the le test.c and after that he runs:
 >git add .
 >git commit –m ‘modified test file’
 Bob has 3 branches: master, text-changes, src-changes

35. A simple scenario
 Meanwhile, Alice modi es README and test.c, and
runs:
 >git commit –a –m ‘modified readme and test.c’
 >git push origin
 Bob tries to merge text-changes with src-changes
 >git branch
 master
 * src-changes
 text-changes
 >git merge text-changes

36. A simple scenario
 Bob tries to push the changes into the origin
 >git checkout master
 >git merge src-changes
 >git push origin
 However, Bob can’t push data to the origin, because he
is not up-to-date
 >git pull
 What happens with the le test.c? Both Alice and Bob
modi ed it

37. A simple scenario
 Git tries to merge contents – and it’s very likely to be able
to do it
 If Git can’t merge correctly, Bob will see the classic merging
style on his copy of test.c:
 <<<<<<<<< yours: test.c
 //Bob’s content
 =========
 //Alice’s content
 >>>>>>>>> theirs: test.c
 After merging, Bob can push his data to the origin
 >git push origin

38. What else?
 Git Reference
 Git Tutorial
 Git User’s Manual
 Pro Git Book
 Git Community Book
 GitHub Help
 Egit - Eclipse plugin
 Graphical frontend:
 Windows, Linux (gtk), Mac OSX, Multi-platform