git

It’s high time I started to integrate myself into the external world of programmers. This means breaking away from my old habits and trying to learn some of the new and accepted habits of programmers. I’ve used systems like SVN and even briefly CMVC before, but they’re all been a bit tedious. I did have a brief stint with casual use of Hg, which I found quite pleasant. But seeing that atm, GitHub is the cat’s meow, I figured git should be on my list of things to learn. Namely so that I can start using it for my personal projects, which implies I’ll be starting some personal projects. Yeah, I think it’s been enough time that I’m beginning to get that programmer’s itch.

Cheatsheet

So, git’s pretty popular and there are dime a dozen tutorials out there so this isn’t a tutorial by any means. There are also quite a number of cheatsheets out there for git, so this isn’t really going to be a comprehensive one of those either. Instead, I’m going to use this space as my workbook of git commands I find useful that I need to keep in mind. It’s a conglomeration of information, as I learn it, from various sites:

• git Book : Online git reference manual, you can also get the ebook for free. See the sidebar on the book page for more versions. Used it for the server setup reference.
• Try GitHub : A nice interactive way to start, but really, only good for the pure basics
• git Immersion : A pretty good lab series to help get you up and running to perhaps an intermediate level
• Think Like a git : Good intro to the graph theory of git. Makes understanding git a bit easier. Plus basic to intermediate examples.
• The Thing About git : Some nice tips on handling some complex sounding merge issues.
• git Cheatsheet : Looks like it has most of the commands you could want. Now I just need to learn them…
• git Ages 4 and Up : The information in the video is good, but the presentation is much to be desired. It’s nice that it’s casual, but the details can get a little lost. I do like it for the way it showcases how git works in the background with all the staging and branching. Good for a conceptual understanding of git.
• git Bootcamp on GitHub : Some good, quick tutorials
• Git Magic : An all purpose reference for git.

As time passes, I’ll add more to the list as those commands become relevant to me. But for now, these are the ones I’m thinking should be useful for what I want to do:

Setup

• git config --global user.name "<public name>" : The name to associate with your commits.
• git config --global user.email "<public email address>" : This email will be visible to everyone sharing the repo.
• I had to remove these from the .gitconfig file as they interfered with being able to add a minimized jQuery to the repository. So use at your own discretion and YMMV.
  • git config --global core.autocrlf input : Line endings. Set to true for Windows users
  • git config --global core.safecrlf true
• git config --global credential.helper cache : Cache your credentials (defaults to 15 minutes) for https:// git URLs
  • git config --global credential.helper 'cache --timeout=3600' : Cache for 1 hour instead
• Add these to your ~/.gitconfig file for some alias access to common commands. [alias]
co = checkout
ci = commit
st = status
br = branch
hist = log --pretty=format:\"%h %ad | %s%d [%an]\" --graph --date=short
type = cat-file -t
dump = cat-file -p


Setup - GitHub

• GitHub is a great place to start experimenting with git. They have their setup page which is useful to get up to speed quickly. If you’re on Windows or Mac, there’s a native GitHub client which can handle everything for you. If you’re on Linux, apparently you’re a command line ninja so no GUI for you. That’s a shame, especially considering Linus uses git to host the Linux kernels so you’d think Linux would be a popular enough platform, especially for developers.
• I’m using the https protocol to clone/push to my repositories. Perhaps I’ll try out the ssh protocol at some point in time, but I can live with having to input my password once in a while. It’s not like I push that often, and there’s also a cache so when I do, I only have to redo it every once in a while. The git protocol is only really for read only as it’s not secure for transmitting passwords.

Initialization

• Starting a new project locally
  • mkdir <newprojectname>
  • cd <newprojectname>
  • git init : Sets up the initial repository. Call it in a new directory you want to turn into a git reop.
• Connecting a local project to a new project on GitHub [source]
  • Assuming you went through the GitHub repository creation process and told it to automatically generate a README and/or LICENSE file for you:
  • From your local repository:
    • git remote add origin <url to .git repo>
    • git pull origin master to pull the bare files from GitHub
    • git push to push your local content up to GitHub (origin master)
• Copying a project from a remote repository
  • (project directory will be created for you)
  • git clone <url to .git repo> <optional local directory name> : Downloads the entire remote repository so you can work on it locally.

Basics

• git status : Show the current status of modified files, staged files.
• git add <filename> : Adds the file to staging.
• git rm <filename> : Removed the file from git and filesystem.
• git commit -m "<message>" : Commits files in staging with message.
• git commit -am "<message>" : Add files that have been modified and commits.
• git commit --amend -m "<message>" : Amend to previous commit (rolls it into one).
• git log : Show history.
• git log --pretty=format:"%h %ad | %s%d [%an]" --graph --date=short : Pretty version.
  • git hist : Aliased version (see .gitconfig setup above).
  • git hist --all : Show history for all branches.
• git checkout <hashcode/tag/branch/etc> : Use this to move to a certain commit.
• git checkout master : Move to the most recent version.
• git tag <tagname> : Tag a commit with a specific name.
• git tag -d <tagname> : Removes the tag with the specific name.
• git checkout <tagname> : Checkout the version right before the tag.
• git tag : List all the tags.
• git remote : Shows remote associated repositories. “origin” is the parent repo.
• git remote show <remotereponame> : Shows information about the remote repository.
• Cloning a git repository:
  • This should be done from one directory above your repo
  • git clone <sourcereponame> <targetreponame> : Clones only the master branch of the remote repository (omit <targetreponame> to use the default name)
• “Download” a remote branch:
  • git branch -r : List the remote branches. Find the one you want.
  • git branch --track <localbranchname> <remoterepositoryname>/<remotebranchname> : Clones a specific branch

Intermediate

• See the differences in files
  • git diff : between what’s in git and the working directory changes.
  • git diff --cached : between what’s in git and the staged changes.
• Move a file to a new directory:
  • git mv <sourcefile> <targetdirectory>
  • or
  • mv <sourcefile> <targetdirectory>
  • git add <targetdirectory>/<sourcefile>
  • git rm <sourcefile>
• Switch to a branch:
  • git checkout <branchname>
• Create a new branch with the specified name:
  • git checkout -b <branchname>
  • or
  • git branch <branchname> : Create it
  • git checkout <branchname> : Switch to it
• Merge branches: Preserves commit history. Good for distributed projects.
  • git checkout <branchname> : Checkout the branch
  • git merge <anotherbranchname> : Merge target branch into current branch
• Show branches
  • git branch : Shows branches
  • git branch -r : Shows remote branches
  • git branch -a : Shows all branches
• Rebasing: Compacts the commit history into something more streamlined. Short branches that really didnt need to be branches
  • git checkout <branchname> : Checkout the branch
  • git rebase <anotherbranchname> : Rebase target branch into current branch
• Updating new content from a remote repository.
  • git pull : Default pulls from “origin/master”
  • or
  • git fetch : Fetches changes from the remote origin, but does not move HEAD, no commit, no merge.
  • git merge <remotereponame>/<remotebranchname> : Like “origin/master”

Advanced

• Create a bare repository.
  • git --bare init : Creates an empty, bare repository on a server for others to push and pull from.
  • git clone --bare <sourcereponame> <targetreponame>.git : Creates a bare repository meant as a central hub for sharing.
• Add a remote repository
  • git remote add <remotereponame> <remoterepository>
• Add a new git repository to an existing local project (without an existing remote repository)
  • git remote add origin <git url> : Where git url can be git@<hostname>:/path/to/repository.git
• Set the newly added remote repository as the default (or you can change origin/master to whatever source/branch you need).
  • git push --set-upstream origin master
• Remove a remote repository.
  • git remote rm <remotereponame>
• Change a remote repository [source]
  • git remote set-url origin <remote git url>
• Push commits to a remote repo.
  • git push : Pushes commits across all branches
  • git push <remotereponame> <remotebranchname>
• Moving a section of a repository to a new repository [source]
  • source: git subtree split -P <name-of-folder> -b <name-of-new-branch>
  • target: git pull </path/to/big-repo> <name-of-new-branch>
  • source: git rm -rf <name-of-folder>

Tips

• To undo changes to a file you’ve made:
  • git checkout <filename>
• To undo a file sent to staging (via add):
  • git reset HEAD <filename> : To remove from staging
  • git checkout <filename> : To revert the changes
• To undo a commit (by making a new commit from a previous commit):
  • git revert <HEAD/hash/tag/etc> : To revert to the commit state
• To undo a commit (by removing the previous commit):
  • git reset --hard <hash/tag/etc> : To reset to the specified commit state

Did I miss any that are useful? Anything wrong with the above? Better tips? Let me know :).

Bonus - Contributing via GitHub

• On GitHub, fork the project in question. You now have your own copy in your own repository.
• git clone your new repository locally.
• git remote add upstream <original repository url> to treat the original repository as a master too.
• If you want to pull changes from the original, got fetch upstream to get the changes and git merge upstream/master to merge them into your new code.
• Work on your project and do the changes you want.
• Do the usual git add ., git commit, and git push origin master (which will push the new code to your forked repository on GitHub)
• Once all your changes are in your forked repository, you want to create a “Pull Request” so that the original repository owner is notified of changes you want to merge into their repository.
• Just follow these GitHub instruction to create a pull request.

Bonus - GitHub SSH connection

• Basically, read through this.
• It’ll be useful to have this set if you want to use it with Maven. The relevant maven <scm> is:

<scm>
    <url>https://github.com/[github name]/[github project]</url>
    <connection>scm:git:ssh://github.com/[github name]/[github project].git</connection>
    <developerConnection>scm:git:git@github.com:[github name]/[github project].git</developerConnection>
</scm>

Bonus - Server Setup

Sometimes, you just need your own git server running privately for one reason or another, say for a stealth project :). I’m not going to go into detail with the setup since the Git Book does a great job of running through the steps needed to get it working.

• Git on the Server

The one note to this is that once you initially push your current repository to the new server, I cant seem to make just git push work. Instead I have to fully specify it as git push origin master. The solution was to just pull a clean clone of the newly minted central repository. I’m not quite sure why, and I’m pretty sure there’s some configuration trick to make git push default to git push origin master.

Update to the above. To set origin master as the default for git push:

git push --set-upstream origin master

Of course, you will have to set the remote repository first. But that should do the trick.

This was another post that evernote ate. this one isn’t a creative post so a rewrite didnt really make it any better, though I guess I relearned the material as I went through recollecting notes to post.