2. Agenda
• Describe how GIT commands corresponds to
SubVersioN ones.
• Provide some commonly used workflows.
• Explain how to use GIT when your team works
with SVN.
• Give a quick overview of GIT internals
3. GIT to SVN mapping
Create the new repo:
svnadmin create repo
svn import file://repo
git init
git add .
git commit
4. GIT to SVN mapping
To revert:
svn revert path
Git checkout path
5. GIT to SVN mapping
To commit:
svn commit
git commit -a
7. GIT to SVN mapping
List:
svn list http://example.com/svn/branches/
git branch
8. GIT to SVN mapping
Moving between revisions:
svn update -r rev
svn update
git checkout rev
git checkout prevbranch
9. GIT to SVN mapping
(assuming the branch was created in revision 20
and you are inside a working copy of trunk)
svn merge -r 20:HEAD
http://example.com/svn/branches/branch
git merge branch
10. GIT to SVN mapping
Pick commit from another branch:
svn merge -c rev url
git cherry-pick rev
15. Some commonly used workflows
1. Write new features in feature branches.
2. Integrate on the master branch.
3. Deploy from the release branch.
16. Some commonly used workflows
1. Write new features in feature branches.
# create a new feature branch in the remote repo named feature_branch
git push origin master:refs/heads/feature_branch
# make sure we've got everything updated from the remote repo
git fetch origin
# create a local branch named feature_branch that tracks
# the remote feature_branch
git branch --track feature_branch origin/feature_branch
# check out the new branch
git checkout feature_branch
17. Some commonly used workflows
2. Integrate on master branch.
git merge master
git checkout master
git merge feature_branch
# this has to be in competition for one of the least intuitive
# commands ever, but it removes the remote branch
git push origin :refs/heads/feature_branch
# remove the local branch
git branch -d feature_branch
18. Some commonly used workflows
3. Deploy from the release branch.
# checkout the deploy branch
git checkout deploy
# pull the deploy branch, just to be sure everything's up to date
git pull origin deploy
# merge the master branch into the deploy branch
git merge master
# tag the release that we're about to make
git tag -a -m "My comments about this release" [tag_name]
# push it all up to the remote repository
git push --tags origin deploy
# switch back to the master branch,
# since we never do any work on the deploy branch
git checkout master
19. Some commonly used workflows
1. Pull to update your local master
2. Check out a feature branch
3. Do work in your feature branch, committing early
and often
4. Rebase frequently to incorporate upstream
changes
5. Interactive rebase (squash) your commits
6. Merge your changes with master
7. Push your changes to the upstream
20. Some commonly used workflows
1. Pull to update your local master
git checkout master
git pull origin master
21. Some commonly used workflows
2. Check out a branch
git checkout -b <branch>
22. Some commonly used workflows
3. Do work in your feature branch, committing
early and often
Hacking…
git commit
Hacking…
git commit
Hacking…
git commit
23. Some commonly used workflows
4. Rebase frequently to incorporate upstream
changes
git fetch origin master
git rebase origin/master
Or (longer way):
git checkout master
git pull
git checkout <branch>
git rebase master
24. Some commonly used workflows
5. Interactive rebase (squash) your commits
git rebase -i origin/master
25. Some commonly used workflows
6. Merge your changes with master
git checkout master
git pull
git merge <branch>
26. Some commonly used workflows
7. Push your changes to the upstream
git push origin master
27. GIT SVN
How to use GIT when your team works with
SVN?
1. Creating working copy? – no! working repo.
git svn init …
Some magic
git svn fetch
Or (if you are lucky! – I’ve never been):
git svn clone …
33. GIT internals
.git content
HEAD – the checked out branch
config – configuration options
description – description (used by GitWeb)
hooks/
index - staging
info/
objects/ - content
refs/ - pointers to commit objects in branches
34. GIT internals
Git is a content-addressable filesystem.
This means that at the core of Git is a simple
key-value data store.
You can insert any kind of content into it, and it
will give you back a key that you can use to
retrieve the content again at any time.
git hash-object – stores the file in GIT
35. GIT internals
git cat-file - provides content or type and size
information for repository objects
BLOB – basic object type. Every file is stored in it