Open main menu

CDOT Wiki β

Git Cheatsheet and Gotchas

Revision as of 13:14, 9 January 2013 by Chris Tyler (talk | contribs) (Getting Started)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Git is a distributed source code revision control application written by Linux kernel designer Linus Torvalds for the purpose of managing the kernel.

Concepts

Git tracks changes amongst files by finding which lines are changed between modifications and generating a diff for each file. A diff tracks the changed lines between a file at snapshot A and the snapshot before it. Change sets are groupings of diffs and represent a desired change to the code. These changes are applied to the repository by committing them.

Each time a diff is committed, an incrementally-built history of the changes grows longer. The diff for the current commit is appended to the front of a list and contains the changes made since the last commit. With each commit tracking the changes made since the last commit and containing a pointer to the last commit, a historical record is formed. That prior commit represents the accumulation of commits that came before it and so the entire history of a file (and all files) can be determined by following the chain back to the first commit.

The use of pointers makes it easy to traverse along files.

Getting Started

There are two situations when getting started: building a repository from the ground up or extending an existing code base. To create a new repository, use the init command:

git init newRepo

and to clone a repository use the clone command:

git clone existingRepo newRepo

In these cases, newRepo is the name of the new local repository to create and existingRepo is the name of the repository to copy files from - this can be a local directory name or a URL.

Modifying and Committing

As far as Git is concerned: all files have three stages that they must go through for a change to be logged.

  • Modification
  • Staging
  • Committing

First, a file must be modified (changed) before any changeset can be submitted to the server. Once modified and saved, the file must then be staged to be committed. This step creates a diff for the file and prepares it to be committed, and must be done whether a file is modified or added. The add command takes as many arguments as you have file names, like this:

git add fileNameA.html [fileNameB.html]

Note that this only works for modifications/additions. Deletions must use the "rm" command:

git rm fileNameB.html

These two commands manage the staging (indexes) for files so that when a commit occurs, change sets for all staged files are merged together and committed. When committing, be sure to add a descriptive comment with the -m flag:

git commit -m "Committing fileNameA.html"

If you're ever not sure about what stages different files are at or what has gone on, you can always view the status of your repo and your file stages by calling the status command:

git status

Branching

A branch represents a divergence in code paths and is implemented as a pointer to a commit. Branches are desirable whenever a change in the code is to be made that may affect the stability of the rest of the code base (bug fixes, new features, new versions). Though all work is done on a branch: even your start branch! Your start branch is known as trunk or the working copy or master, and may be branched off of whenever desired (using the branch command). After making a branch, you will not be automatically switched to it and modifications won't be applied. You can switch branches using the checkout command) A branch can be made and used in a few ways:

git branch newBranch
git checkout newBranch
git checkout -b newBranch

The first two lines of code will make the branch and switch to it separately, but the third line will do both in one step.

Branches are cheap and require no code duplication: branches are achieved by duplicating a file pointer to the last commit on the trunk. When a commit occurs on the branch, this pointer is then moved ahead to the new commit, which then points back to the trunk at the point it was branched. This way the branch knows about all the changes that occurred in master up until the point of branching (but not after). The pointer to the last commit on a branch is called HEAD.

Changes on a branch are applied back to trunk by merging them. To merge, you must switch to the branch to merge onto (in this case trunk) and call the merge command specifying the branch to merge:

git checkout master
git merge newBranch

Remoting

Gotchas

External Resources