Getting Started With Git

Getting Started With Git

Git is a modern (SCM) source code management system written by Linus Torvalds. Like all his software, he names it after himself.

(This page is intended for UCSC Genome Browser developers.)
We are currently in the process of migrating from CVS to Git.

Setting Up Your Own Personal Git Kent Repository

To create your personal git repository of the kent source, please use the following simple directions:

 cd $HOME
 
 git config --global user.name "Your Name Here"
 git config --global user.email yourlogin@soe.ucsc.edu

If you like colors:

 git config --global color.diff auto
 git config --global color.status auto
 git config --global color.branch auto

If you have an existing old test local git repo ~/kentgit, please remove it before proceeding.

 mv kent kent-cvs    # move your old kent directory out of the way
 git clone yourlogin@hgwdev.cse.ucsc.edu:/scratch/kentrepo.git/ kent
 cd kent

/scratch/kentrepo.git is our shared kent repository. We access it via SSH.

Sharing Changes With Others

Git is a distributed SCM so it works a bit differently from CVS. Each user has their own local project repository which includes the full history of all changes ever made. This allows one to work offline and had other advantages besides. However, for simplicity there is a shared repository that people push changes to from their local repository. More complex configurations are possible, such as hierarchical. Probably the shared repository approach is fine for our group.

 git pull origin    # equivalent to cvs up -dP, this pulls in changes by others.

 git push master origin   # equivalent to cvs commit, only do this when your changes are ready to share with others.

Some simple real-world git usage

Here is an example of some git commands used to modify a file, check on it, diff it, check it in, push it up to shared repo:

 vi doSomethingCool.csh
 git diff --help
 git diff --name-status  # show only the names of files that changed
 git diff  # show detailed diff
 git status     # another way to see info about changes
 git add doSomethingCool.csh   # notice that this adds it our list of things
                           # to be committed together in the next commit.
                           # Whether it is a new file, or just a change, you do a git add.
                           # Several related things can and should be committed at the same time as a unit.
 git commit -m 'made some useful changes ...'  # Commits to your local repo only.
                           # Make the comments useful.
 git diff       # check that the changes got committed
 git status     # another way to see info about changes and so on

 git diff origin   # but what about diffing to the shared-repo?
 git push origin master    # push my change up to be shared with all
 git diff origin   # verify that there are no more outstanding changes
 git status  # check info again

Warning:

 git commit -a      # DO NOT USE. Commits ALL changes in your local-repo (dangerous!)

-a automatically adds ANY and ALL changes in your local-repo to the "cache/commit index" list of things to commit for existing tracked files. Unlike CVS, it is not influenced by your current directory location. Any tracked files that you have modified, for instance common.mk will get checked in.

git diff

git diff does a lot of things. You can see just names or full details. You can diff between different specific commits, between branches, between repositories, between your sandbox and your commit-list, between your commit-list and the head, etc.

Branches

Your default branch in your own repository is called master. Because we imported cvs history, we all have a lot of branches already. There is also a master or head branch on the shared-repository.

You can and should easily create additional branches in your local repository. This requires NO TAGGING, and it's fast and convenient. You can switch back and forth between the master branch for a quick fix and some more involved detailed development branch, or make a quick branch to test some idea, or another friends code. It's cheap to leave these local branches, they don't clog up the shared repository, and you can also clean up ones that you no longer need. Merging stuff between branches is usually pretty easy and smooth. Note that if you have outstanding changes that would be lost when switching branches, you can tuck them away with the git stash command. Then you should be able to switch branches. But you need to later use your stash and delete it to tidy up.

Git is also big on making sure digital corruption does not creep in, and it will detect it automatically if it happens.