Fri, 27 Mar 2009
/Coding/git:
Basic Tutorial: Use Git to Manage Your Source Code
Git[1] is a program used for distributed Source Code Management (SCM)
whose popularity is increasing rapidly. Git seems to be becoming the de
facto standard among Debian[2] people, for instance. The first link is
to kernel.org, the home of the Linux kernel, because Git was originally
created[3] by Linus Torvalds for the Linux kernel development.
Install git command line tools (Debian and derivatives):
apt-get install git-core
(Note that there is a legacy "git" package which has nothing to do with
"git" the SCM software....)
You only need to know a few simple command lines[4][5] to get an
astonishing amount of function out of git, and therefore git can be
usefully applied to even simple scenarios like bug fixing someone else's
software and submitting patches upstream. This last is the example I
will work through and demonstrate here, while trying to be more verbose
then [4] & [5].
First, download and unpack your source code. Then cd into the base
directory of the source code, and initialize git by running the
following:
git
init
This will create a .git subdirectory which will contain git's
repository (starting point plus history of changes you make to the
code).
Now if you do
git
status
you will see a long list of "Untracked files", ie. the repository is
currently empty. Lets add everything you just unpacked to the
repository:
git
add .
git
commit
Note the "." after "git add". Its the "." that specifies "everything"
under the current directory. "git commit" will prompt you for a commit
message, just type "Initial commit" and exit the editor. If you check
the status again with "git status" you should see zero untracked
changes. Now type
git
log
and you will see the record of your initial commit. Now build your
unmodified source code (Debian[6]?) just to make sure there is nothing
wrong with it.
After the build successfully completes, "git status" will show a long
list of changes even though you made no change to the source. Time to
introduce .gitignore.
Create a (hidden) file called ".gitignore" in your source directory
root, and place the following on the first line: "*.o". If you run "git
status" again you will discover that all *.o (object files) have
vanished from the listing. The object of using .gitignore is to get rid
/ not track all the build noise, and *.o files definitely qualify. I am
going to submit patches upstream, so I am pretty sure the contents of
the debian directory are not something I want to track, and have also
added a "debian*" line to .gitignore.
Now "git add ." and "git commit" again to get a clean git slate
before beginning to make source changes.
Make your first source changes ("git status" should list the
changed files). Build, install, and test the software. Let's say this
was a partial change that solves part of the problem, but not the whole
problem. This probably qualifies for another commit. "git add" the
changed files, then "git commit". You can make several change / test /
commit iterations, so that "git log" provides a detailed account of what
you did. If they do not conflict with other commits, any individual
commit can also be backed out.
Should you ever mess up and want to restore your last commit:
git-reset
--hard HEAD
should do the trick, and wipe out all changes since the last commit.
When it comes time to submit your patch upstream, git can also generate
the patch for you:
git
diff HEAD^ HEAD
will generate a diff between your very last commit, and the one that
preceded it.
[1] http://www.kernel.org/pub/software/scm/git/docs/
[2] http://www.debian.org/
[3] http://en.wikipedia.org/wiki/Git_(software)
[4] http://www.kernel.org/pub/software/scm/git/docs/everyday.html
[5] http://git.or.cz/gitwiki/QuickStart
[6] http://blog.langex.net/index.cgi/Linux/Debian/How-to-modify-source.html
posted at: 06:12 | path: /Coding/git | permanent link to this entry
