I decided to post a few of the scripts and config files I have going on github, making it easier to share files between my machines. I’m brand new to Git, so I really had absolutely no idea how it worked before I started working with github. Essentially all of my informaition came from the great introduction to Git, Pro Git, as well as the Git man files. This information is merely compiled into one page here. This post is a quick reference for myself, but if you find it useful, then great! (Note that I work on Linux machines, so this guide is very Linux-centric)
Of course, you have to start by installing Git. On Arch Linux, my distro of choice, this is as easy as the following:
# pacman -S git
However, this will vary depending on the distro you’re currently using. You’ll almost certainly find Git in your distro’s default repositories, but it’s not there or is outdated, you can grab the source for Git here: http://git-scm.com/download. Git depends on curl, zlib, openssl, expat, and libiconv, so make sure that those are all installed, too.
Start by setting your name and email address. This is essential, as it is included in every single commit you do.
$ git config --global user.name "Your Name Here"
$ git config --global user.email email@example.com
Set your prefered editor. This editor will be called when you need to type a message.
$ git config --global core.editor vim
At this time, you might also find it useful to specify a diff tool. I use vimdiff.
$ git config --global merge.tool vimdiff
If you like coloured output, use the following configuration command:
$ git config --global color.ui auto
Make sure that Git will be dealing with line breaks properly. This should set you up so that every commit converts line endings to LF, so that they are always LF in the repository you’re working with.
$ git config --global core.autocrlf input
You might find it useful to set up a few aliases, such as the following:
This makes it easier to remember the command to remove files from the staging area.
$ git config --global alias.unstage 'reset HEAD --'
Using the command “git last” will give you information about the last commit.
$ git config --global alias.last 'log -1 HEAD'
Pro Git reccomends the following for tab completion in Bash:
Download the Git source code, and look in the contrib/completion directory; there should be a file called git-completion.bash. Copy this file to your home directory, and add this to your .bashrc file:
If you want to set up Git to automatically have Bash shell completion for all users, copy this script to […] the
Initilizing a Git Repository
To start using a Git repository, it must be started first. This is as easy as the following command:
$ git init
This starts the git repository skeleton in your current directory, however, nothing is actually being tracked yet. The following goes through the process of adding a file, and then commiting it.
$ git add
$ git commit -m 'Comment about commit'
Clone a Git Repository
Cloning a Git repository will make a copy of the entire repository on your local machine. Note that this is not just a copy of the current working version, but the entire project, including all of the history. Note that in the following example, the portion in square brackets is optional, and merely specifies a custom name for the cloned repository.
$ git clone git://location/of/your/git/repository.git [my_repository.git]
Working with a Git Repository
To check the status of files (untracked, unmodified, modified, staged), use git status.
$ git status
Whenever you want to stage a file, you have to use git add to stage the current version of that file. Once staged, the file will be part of your next commit, as is. Note that if you add a file to stage it, and then change the file again, the version that is currently staged is the version before your last change.
$ git diff
can be used to see what specific changes in files have been made but have not yet been staged. This command accepts arguments. Use —-staged to show changes that have been staged and will go into your next change.
$ git add
If you don’t want git to track some files (even as untracked), use a .gitignore file to list the files. From http://progit.org/book/ch2-2.html,
Setting up a .gitignore file before you get going is generally a good idea so you don’t accidentally commit files that you really don’t want in your Git repository.
The rules for the patterns you can put in the .gitignore file are as follows:
- Blank lines or lines starting with # are ignored.
- Standard glob patterns work.
- You can end patterns with a forward slash (/) to specify a directory.
- You can negate a pattern by starting it with an exclamation point (!).
Glob patterns are like simplified regular expressions that shells use. An asterisk (*) matches zero or more characters; [abc] matches any character inside the brackets (in this case a, b, or c); a question mark (?) matches a single character; and brackets enclosing characters separated by a hyphen([0-9]) matches any character between them (in this case 0 through 9) .
Here is another example .gitignore file:
# a comment – this is ignored
*.a # no .a files
!lib.a # but do track lib.a, even though you're ignoring .a files above
/TODO # only ignore the root TODO file, not subdir/TODO
build/ # ignore all files in the build/ directory
doc/*.txt # ignore doc/notes.txt, but not doc/server/arch.txt
The final step is committing your changes once you are happy with what you have staged.
$ git commit
This will call upon your editor to write a comment about the commit. A comment is needed, otherwise the commit will abort. The option -v will tell you what files you are committing.
If you don’t want to bother with the staging area (useful for something like a simple edit of a file), you can simply change your file, and then use the command
$ git commit -a -m 'comment about the commit'
To delete a file, first remove it from the working directory, and then stop tracking it.
$ rm <filename>
$ git rm <filename>
You can use
$ git rm --cached <filename>
to remove a file from your staged area, but keep it in your working tree.
To move a file, use the mv that is built into git:
$ git mv <initial_file> <renamed_file>
Viewing the Commit History
$ git log
is used to view the commit history. It accepts flags. -p will show the diffs of the commits. –n can be used, where n is a number, to limit to n number of entries. —-stat will show some abbreviated stats for each commit. There are many different ways to show the log history. To see all of the options available, check the Git documentation with:
$ man git-log
Be careful when undoing things. Git is designed to be fairly failsafe, but you can lose data when undoing changes. You can’t always undo these undos, so proceed with caution.
If you need to change a commit for some reason (say you forgot to add a file into the commit), you can use
$ git commit --amend
to reupload your current staging area and merge it with your last commit.
Say you accidentally move a file into the staging area when you didn’t mean to, or want to unmodify a modified file. Instructions on how to undo changes are present in the output of:
$ git status
Working with a Remote Repository
While you’re working with git, you’ll in all likelyhood have be working with remote repositories. While I’m working with files, I have my local version, and I work with my remote repository on the github servers. To see your remote repositories, use:
$ git remote -v
To add a remote repository and give it a name that you can easily reference, use the command git remote add. In the following line of code, replace the square brackets with their respective fields.
$ git remote add [name_for_repo] [url]
If you want to get more information about a certain remote repository, use the command:
$ git remote show [remote_repository_name]
You can pull information out of remote repositories. The following command will pull any new data that you don’t have into a new branch on your machine.
$ git fetch [remote_repo]
Note that you can set up
git pull to somewhat automate fetching new information from remote repositories.
When you want to share your data with others, use git push to push your data upstream.
$ git push [remote-name] [branch-name]
Tagging is very useful for keeping track of things like release versions. To see all of a project’s tags, use the command:
$ git tag
There are different types of tags that are available for use. Lightweight tags are simply pointers to a certain point in the history of a project. Annotated tags contain information about the tagger, date, the tagger’s email, contain a message, and are checksummed. Signed tags contain a GPG (Gnu Privacy Guard) signature. Annotated tags are generally reccomended. You can create an annotated tag using:
$ git tag -a v[version_number] -m 'comment about version'
If you want to create a lightweight tag, use no flag. To create a signed tag, use the flag -s.
To see information about a tag, use the command:
$ git tag show [tag]
You can tag a commit after the project has moved on. View the history of the commits with a command like the following one, and then use part of the checksum to tag a particular commit.
$ git log --pretty=oneline
0b7434d86859cc7b8c3d5e1dddfed66ff742fcbc added a commit function
4682c3261057305bdd616e23b64b0857d832627b added a todo file
166ae0c4d3f420721acbb115cc33848dfcc2121a started write support
9fceb02d0ae598e95dc970b74767f19372d61af8 updated rakefile
$ git tag -a v1.2 9fceb02
Tags are not by default pushed to remote servers. To do so, you must specify them, much like remote branches.
$ git push origin [tagname]
If there are a large amount of tags you want to push, use the command:
$ git push origin --tags
Branches can be created with the command:
$ git branch [branch-name]
To delete a branch, issue the same command, but with the flag -d.
$ git branch -d [branch-name]
To switch to a previously created branch, use the checkout command.
$ git checkout [branch-name]
Merge you changes with the command merge. Issue the command from the branch you are merging into, and let [branch-name] refer to the branch that you are pulling in for the merge.
$ git merge [branch-name]
Sometimes, merges don’t go smoothly. If you have a problem with a merge, you have two options:
- View the output of
$ git status The file(s) that barfed during the merge will be listed as “unmerged”. You can manually edit the files to resolve the merge issues. Find the section(s) that Git has changed (it will list what the file is like in both branches at this point of the file), and then edit it down to what you want the end result to be. After you finish, run
$ git add [filename]
to stage the file(s), marking them as resolved.
- Use a diff tool to assist in dealing with the conflict.
$ git mergetool
Once you’ve done so, you can tell the script that you resolved the conflict.
Once you are done with your changes, run
$ git status
to ensure that everything has been resolved. Once you are happy, run
$ git commit
to finalize the merge.
Unlike the branches previously discussed, remote branches exist in remote repositories.
All of the information on this page was pulled from two sources: The wonderful book Pro Git, by Scott Chacon; and the Git man pages. Sections that I’ve pulled directly from the sources are in block quotes and attributed in the surrounding area. Everything else somehow came from one or both of these two sources, but with the surrounding writeup written by me to paraphrase the source.