Git Started

Chase Maupin
 Agenda
• What is Git
• Configuring Git
• Creating a local repository
• Cloning a remote repository
• Checking Repository Status
• Making Changes
• Viewing History
• Working with branches
• Merging Basics
• Rebasing
• Rewriting History
• Creating Patches
• Pushing Changes
• References
 What is Git?

Distributed Version Control

Key Features
Git the Picture
 Distributed Version Control
• A version control system where there
multiple users can have a copy of the
repository
– Not a single “central” repository that everone
works against
• Code is merged from individual repositories
– We agree on which repository hold the “master”
code
• No need to checkout/in individual files
• Network is not involved in most operations
– Only need access to the network when
merging/syncing to a remote repository
 Key Features
• Allows participation without “commit” rights since developers
can have their own local copies
– Developers without commit rights can send their changes as
patches
• Allows multiple developers to work on the same piece of code
at the same time
– No checkout file locks
• Allows development without network access
– Work locally in your repository
– Local repository is a complete repository
• Allows for private development
– Prototype your work locally before publishing
– Allows frequent commits on local branches and then cleanup for
submission
• Enforces accountability
– Tracks who commited which changes
• Allows for branched development/compartmentalization
– Easy to merge and rebase branches
 Git the Picture
Public Repository
Master
Private Repository

Public Branch

Local Branch

Dev A Dev B Dev C

Dev D
Configuring Git

User Information
General Setup
E-mail Setup
 User Information

• You should configure git to know who

you are
• This is done so that git can track who
made which commit
• You can configure this using:
git config --global user.name “Your Name”
git config --global user.email “your@email”
 General Setup

• Some other general setting which can

make it easier to work with git are:
git config --global core.editor “vim”
git config --global color.ui “auto”
git config --global color.branch “auto”
git config --global color.status “auto”
git config --global color.diff “auto”
 E-Mail Setup

• When sending patches to the mailing list it is

often easier/required that the patch be
embedded in an e-mail
• The below configuration setting will
configure git to send e-mail through a gmail
account
git config --global sendemail.smtpserver “smtp.gmail.com”
git config --global sendemail.smtpserverport “587”
git config --global sendemail.smtpencryption “tls”
git config --global sendemail.smtpuser “youraccount@gmail.com”
git config --global sendemail.smtppass “your gmail password”
Creating a Local Repository

Why?
How?
 Why?

• Creating a local git repository allows you

to track your code revisions without
requiring network access.
• You can create development and test
branches
– Safe way to prototype and be able to undo
mistakes
• Can later be pushed public if you decide
to share your code
 How?

• Creating a local repository is as simple as

using the “git init” command.
• The below example will make a git repository
in the directory called my_project and
populate it with initial contents
host$ cd ~/my_project
host$ git init
host$ cp <initial sources> .
host$ git add *
host$ git commit -m “initial version”
Cloning a Remote Repository

Protocols
Why Clone
 Protocols

• There are three common protocols

used to clone git repositories.
• Git Native Protocol - Most efficient way
to clone git repositories
• SSH - Uses Git native protocol over ssh
connection. Used to push changes to a
remote repository
• HTTP/HTTPS - A good backup method.
Not as fast as Git native protocol.
 Why Clone?

• Cloning is better than just downloading

a copy of the sources for the following
reasons
– It automatically creates a git repository for
you to use locally
– It allows you to track future changes and
pull them into your copy and merge them
– Depending on your configuration cloning
the repository also allows you to be able to
push changes back
Checking Repository Status

The git status Command

 The git status Command

• Displays the status of the git repository:

# On branch master Current branch

# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
# Files in the commit
# new file: file1.txt
#
# Changed but not updated:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory) Files modified that git
# knows about
# modified: test_file.txt
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed) Files that git is not
# tracking
# file2.txt
Making Changes

What is a Commit?
Adding Files to a Commit
Removing Files from a Commit
Removing Files
Moving Files
 What is a Commit?

• A commit holds information about each

change in the repository.
– Author
– Committer
– Commit Date
– Log Message
– Commit id
• Captures the state of the repository at
the time of the commit.
• Can have one or more parents
 Adding Files to a Commit

• When files are changed you must add

them to the list of files to become part
of a commit
• This is done with the “git add
<filename>” command.
• Only files that were added will become
part of a commit
– It is possible to have two files modified
and only add one of them to be committed
– In this way you can break up your changes
 Adding File to a Commit - 2

• For example, if my repository has two files

named file1.txt and file2.txt and both have
been modified I can:
– Make a single commit containing the changes to
both files:
host$ git add file1.txt file2.txt
host$ git commit
– Make two commits, one for each file:
host$ git add file1.txt
host$ git commit
host$ git add file2.txt
host$ git commit
 Removing Files from a Commit

• If you have added a file to the set of

files to be committed by mistake you
can remove it using:
host$ git reset HEAD <file>
• This resets the state of the file to its
state on the HEAD of the git tree, which
is unadded
 Removing Files
• To completely remove a file from a git repository use
the “git rm <file>” command.
• git rm will also delete the file on your file system
– However it is still in the repository for previous commits so
it is never really lost.
– This means you cannot ever really delete a file from a git
repository
• A remove operation is still a change so you must
commit that change to the repository
host$ git rm file1.txt
host$ git add file1.txt
host$ git commit
• Files being removed will show up in git status as:
– deleted: <file name>
 Moving Files
• To move/rename a file in a git repository use
the “git mv <file> <dest>” command.
• git mv will perform the mv operation add the
change to the commit list.
• A move operation is still a change so you
must commit that change to the repository
host$ git mv file1.txt file1_1.txt
host$ git commit
• Files being moved will show up in git status
as:
– renamed: file_name -> new_file_name
Viewing History

The Simple Log

As Patches
Graphically
 The Simple Log
• To view just the commit messages that make
up the history of a repository use the “git
log” command. This will display the
following information for each commit
– Commit id
– Author
– Date
– Comments
• The history is for the current branch you are
on (have checked out)
• If you switch branches the git log will change
if the new branch has commits different than
the old branch
 As Patches

• To see the changes that were made by

each commit in a patch format add the
“-p” option to the git log command. i.e.
host$ git log -p
 Graphically
• For a graphical way to view the repository
history you can install the gitk command.
• To see all branches invode gitk with the --all
option
host$ gitk --all
• The graphical screen that appears will show
– The repository history as a graph
– The full commit log of each commit
– Which files the commit affects
– The commit author
– The commit date
Graphically - 2
Working with Branches

Why Branch?
Making a Branch
Listing Branches
Switching Between Branches
 Why Branch?
• Branches allow you to group a series of
commits together
– For example you can have a branch for each
development project
• You can switch between branches to keep
you work isolated
– The changes in one branch are contained to that
branch only unless you merge them into another
branch
• Branches can share all of the repository data
they have in copy, not multiple copies
• This way one repository can look like several
copies but you only have to manage one
 Making a Branch
• To make a branch of your current branch and switch
to the new branch do:
host$ git checkout -b <new branch>
• Or you can do this the long way
host$ git branch <new branch>
host$ git checkout <new branch>
• To make a branch from a specific commit
host$ git branch <new branch> <commit id>
• To make a branch from a named commit (i.e. another
branch)
host$ git branch <new branch> <other branch>
– NOTE: This will make the branch from the commit that
<other branch> is pointing to at this time. It will not track
changes to the other branch (see later sections)
 Listing Branches

• To see all local branches use

host$ git branch
• To see all remote branches use
host$ git branch -r
• To see all branches use
host$ git branch -a
 Switching Between Branches

• To switch between branches use

host$ git checkout <branch>
 Merging Basics

What is a Merge?
How do I merge?
Dealing with Conflicts
 What is a Merge?

• A merge joins two or more commit histories

(branches)
• A merge must occur within a single
repository
– i.e. both branches must be available within the
repository
– They could be tracked remote branches
• A new commit is created at the merge point
– If there are no conflicts this is done automatically
– If there are conflicts you must fix them and make
the final commit
 How do I Merge?

• Merging is done using the “git merge”

command
• You should usually clean up your
working directory
– Commit outstanding changes, etc
• To merge other_branch onto branch
you would do
host$ git checkout branch
host$ git merge other_branch
 Dealing with Conflicts
• If a merge has a conflict you must resolve it
• Git will warn you of merge conflicts
– You can also use the “git status” command to see which files had
conflicts. They will be listed as
unmerged: <file>
• You must then edit the unmerged files to resolve the conflicts
– The conflicts will be marked with <<<<<<<<, ========,>>>>>>>>
lines
– <<<<<<<< begins the conflict with the code from the branch you
are merging into
– ======== is a delimiter between the two sections
– >>>>>>>> ends the conflict with the code from the branch you are
merging
– Remove these markers when you resolve the merge
• When the conflicts are resolved you must “git add” the file(s) to
clear their conflict state and then commit the merge
 Rebasing

What is Rebasing?
Interactive Rebasing
Rebasing vs. Merging
 What is Rebasing?
• Rebasing alters where a sequence of commits are based
• Commonly used to
– Keep commits on a development branch up-to date with another branch
(i.e. master)
– Relocate a branch
– Reorder, remove, combine, or change commits
• Commits after a rebase have different commit ids
– Thus the change is the same but the commit is new
Updating A Branch Relocate A Branch

A B C A B C

D E F D E F

G H

A B C G’ H’
A B C
D’ E’ F’
D E F
 Interactive Rebasing
• By using the -i option to rebase you can enter
interactive mode
• Interactive mode allows you to change the commits
with:
– reordering commits = Just change their order in the list
– removing commits = Just remove the commit entry from the
list
– reword = Change the commit message
– edit = stop the rebase process so you can amend a commit
– squash = combine a commit with the previous commit
– fixup = like squash but discards the commit’s log message
• Often used to clean up a series of commits before
making patches for submission or pushing changes
 Rebasing vs. Merging
• Rebasing makes new commit ids unlike
merging
• Old commits that have been removed
(stranded are gone)
– Anyone based off these commits can also
become stranded
• Anything relying on these commit ids will be
confused by the rebase
– i.e. other branches or other clones of a repository
• Rebasing is usually used on local branches
and repositories
• Once a branch or repository is shared
merging should be used
Rewriting History

Amending Commits
Reordering Commits
Editing Commits
Squashing Commits
Removing Commits
 Amending Commits

• Using the --amend option with “git

commit” will modify the current commit
• Useful for changing the both the
content of the files as well as the
commit message.
• You still have to “git add” your
changes but then you use
host$ git commit --amend
• This way you do not have two commits
but instead only one.
 Reordering Commits
• Using interactive rebase you can reorder your
commits.
• For example if I have three commits on a branch
made from master that I want to reorder I can do
host$ git rebase -i master
• This would bring up a list of commits like
pick c77ad7f commit message 1
pick 8aadde7 commit message 2
pick 9cdf6ba commit message 3
• To reorder the commits I just change the order in the
list and exit the editor
pick c77ad7f commit message 1
pick 9cdf6ba commit message 3
pick 8aadde7 commit message 2
 Editing Commits
• To edit the current commit you can use the “git
commit --amend” option as mentioned before.
• To edit a previous commit you need to use
interactive rebase
– To change the commit message change the “pick” line to
“reword”
– To change the whole commit change the “pick” line to
“edit”
• For example, to edit the second commit in a list I
would change the list to look like
pick c77ad7f commit message 1
edit 8aadde7 commit message 2
pick 9cdf6ba commit message 3
• When I exit the editor the rebase will stop on commit
two for editing
– I can then edit the sources and use “git commit --amend” to
change the commit.
 Squashing Commits
• To combine commits you need to use interactive
rebase
– Mark each commit you want to merge into the previous one
by changing the “pick” line to “squash”
• For example, to merge all of my commits into one I
would change the list to look like
pick c77ad7f commit message 1
squash 8aadde7 commit message 2
squash 9cdf6ba commit message 3
• During the rebase I will be given the option to
change the commit message to reflect the merge of
these commits.
• When the rebase finished I will now have only one
commit that contains all of the changes of the three
commits.
 Removing Commits
• To remove commit the easiest way it with the
interactive rebase command
• When presented with the list of commits just
delete the entry for the commit you want to
remove
• For example if I have the list
pick c77ad7f commit message 1
pick 8aadde7 commit message 2
pick 9cdf6ba commit message 3
• To remove commit two I would change the list to
look like
pick c77ad7f commit message 1
pick 9cdf6ba commit message 3
 Creating Patches

What is a Patch?
Specifying the Patch Set
Patch Options
Sending Patches
 What is a Patch?

• A patch is a file in a format that

represents the changes between two
versions of a file.
• The differences are marked as line
deletions and additions
• When applied a patch will modify the
original sources to contain the changes
the patch specifies.
• Patches only specify the differences so
it is easy to see what changed.
 Specifying the Patch Set
• This is where branching becomes useful in git
• To create a patch set you need to specify the range
of commits to use
• When using branches you can just specify branch
names.
• For example if my current branch was created from
the “master” branch I can make a patch set of the
changes on my branch using
host$ git format-patch master
• I could also specify to create patches of changes
since a particular commit id
host$ git format-patch <commit id>
• To make a patch set of only the last n commits use
host$ git format-patch -<n>
 Patch Options
• When making a patch set containing more than one
patch use the --numbered option
– This creates the patch header to contain a series numbering
to indicate the order of the patches.
– i.e. [PATCH 1/3] means patch 1 of 3
– It is OK to always use the --numbered option
• When making a patch set containing file moves and
copies use the --find-copies-harder option
– This option will simplify the patch so that a move operation
does not look like a removal of a file and an addition of the
same file
• Both of these options are generally safe to specify
all the time
 Sending Patches
• To send you patches to a mailing list like the
openembedded-devel list you can use the git
send-email command
– This command will send the specified patches to
the mailing list embedded in an e-mail
– NOTE: some lists like arago-dvsdk-devel prefer
patches as attachments instead of embedded so
do not use git send-email
• You must configure git for e-mail to use this
command
• The general format is
host$ git send-email <patches> -to <list>
Pushing Changes

Pull Before You Push

Pushing to Mainline
 Pull Before You Push

• It is generally a good idea to do a “git pull”

before you push your changes
• Since git allows for distributed development
someone else may have already pushed
changes to the repository
• You need to get those changes and fix any
conflicts first
– Git will warn you if you try to push to a repository
and the changes cannot be merged
 Pushing to Mainline
• Assuming you cloned the git repository
using the SSH protocol you will usually have
a master branch that is tracking the master
branch on the remote repository
• To push the changes from your branch to the
remote repository use the “git push”
command.
host$ git push <remote name> <branch>
• The default remote name is “origin”. So to
push your master branch you would do:
host$ git push origin master
• There are ways to shortcut this command but
this is the safest format to use
 References

• Use the man pages

• http://processors.wiki.ti.com/index.php/Git
• http://book.git-scm.com/
• Version Control With Git 1st Edition,
O’Reilly, Jon Loeliger,
ISBN#9780596158187