Using Git and Tools
Uploaded by
kellotiUsing Git and Tools
Uploaded by
kellotiUsing Git and Tools
December 2, 2010
Global Settings
• In Git Extensions, Settings Settings Global
Settings tab
– User name
– Merge tool
• Kdiff3
– Editor
• Don’t use notepad or notepad++
• Use Word pad, Vim, or Git Extensions editor
Commits (Changesets)
• ID, person, date, message, file changes, changed rev ID
• Revisions IDs are non-sequential hashes like GUIDs
o 160-bit hash can be referred to with shorthand
f2060444ae8908d365589ad3ec1cdd08f2388d58
f20604
HEAD refers to the latest branch and HEAD~5 is 5th from
latest
Viewing the graphical history of the code shows the natural
progression of how code evolves
• Git provides great visualization tools for viewing history
o Git GUI
o Git Extensions
Refs and Objects
• "refs" are commits, tags, and branches
• Tags are just commits with a friendly name
o Description, person who created it, date, signature hash
• Branches are like tags except that they change
Remotes
• "origin" is the default place you push to & pull from
o define other origins to push to friends or folders
• By default, push & pull act on current branch
• By default, push & pull don't affect tags
origin/master vs. origin/HEAD
• HEAD is a dynamic tag referring to the latest known commit
of a remote
• “tip of the current branch”
• There is one HEAD per repository (remotes + local)
The Basics: Cloning
• Clone is like checkout in SVN
• A clone is an entire standalone repository
o Full history of all public branches
• Working copy := A local, version controlled copy of a
repositories files & directories
o The repository is in the .git folder
o A bare clone is a clone without a working copy
The Basics: Updating
Pull versus Fetch (Stack Overflow)
• Fetch retrieves the latest changes from the remote
o safe - just updates your .git folder, not your working copy
• Pull does a fetch and then merges into the current branch
o Before pulling [or merging] you must stash, commit, or
revert your current changes
The Basics: Merging
• Reasons to merge:
o merging branches
o Resolving conflicts when pushing
• Git attempts to auto-merge first
o Doesn't require a commit if succeeded
• Then manual merge
o use kdiff to merge between 2 or 3 sources
local, remote base, & remote head
o Requires commit & message
The Basics: Commit & Push
• Merge into master branch (optional)
• Stage files
o Stage partial files with Git extensions
• Commit
• Push
o Your team doesn't know what you did until you push
changes to them!
Going back (revert & amend)
• Revert
– Go back to a specific revision
– “--hard” or “force” means that all current pending changes
will be lost
• Commit --amend
– Amend a past commit message
• Rebase interactive can be used to delete commits
Branching
• Easy local branching
o Make a branch for everything you do
o Freedom to abandon changes and come back later
o Great for unexpected escalations
o Sandbox for sketchy solutions or major changes
• Easy public branching
o maintain production, acceptance, and development
branches
o Use of "rebase" to apply bug fixes in several branches
Rebase
• http://book.git-scm.com/4_rebasing.html
• Change the "base" of the branch to a newer version
o i.e. Making a change in production
Dev
branch
Prod patch
from an
escalation
Rebase
"rebase mywork on C4" will replay C5 & C6 changes on C
Rebase
Rebase vs Merge
Rebase: Example
Cherry pick
• Another alternative to merging
• Pick commits from one branch and apply them to
another
• Git uses history to intelligently apply changes even
after significant refactoring
Submodules
• A repository within a working copy
o Has it's own ".git" folder, you commit separately to it
o parent repo knows what version to use via the
“.submodules” file
• Great for dependencies
Handy features
• statistics
• bisect
o tracing where in commit history a test started to fail
• commit --amend
o For when you committed too soon
• branch & revert master
o if you decide down the line that you should have been
working on a separate branch, just do the branch and
reset master back to "origin/master"
• Auto-rename
• Git will understand when you renamed a file. There won’t
be “delete” & “create” operations, just one single rename
and history will be maintained. No commands necessary
Server: gitolite and SSH
• People are authenticated per computer they log in from
o private keys
o authentication is purely for assigning read/write privileges
• gitolite is an SSH servlet that manages users, groups and
repositories
o Use SSH to get a repo listing
o Your public key is kept in ~/.ssh/id_rsa.pub
o Each time you use your key on a new host it asks for your
permission and logs the host into ~/.ssh/authorized_hosts
Terminology
• Branch – A duplication of the code where changes
can be made in parallel to the main branch
• Tag – a commit that is given a name
• Origin – the central server that you originally cloned
from
• HEAD – The tip of the current branch
• Remote – a repository that you push to & pull from
• Fetch – retrieve the latest history from origin
• Pull – fetch & merge into latest branch
• Push – send your commits to origin to be shared with
the rest of the team
Reference
• http://progit.org/book/
• In Git bash, help files open into browser
– Git --help
– Git <cmd> --help
