greckout query

This will list all branches matching your query as input options for git checkout

  greckout ar
  
  1) ar/cache-api-keys-1098
  2) ar/add-categories-object-to-tv-show-1382
  3) ...

When we started using git to manage our source code at work, we actually jumped in a little bit too fast. It seems like there is a lot of writing about how you can do lots of really neat things with git, but no real guide about one particular way of using git for your project. This post is going to describe how we use git day to day on a reasonably large “agile-style” project.

If you need to find out which of your local commits are not on the remote server do this:

git cherry -v

The -v option prints out the commit messages. Without it you will see only the SHA1 codes.

You may also compare against another (upstream) branch like that:

git cherry -v origin/somebranch

This tool is especially useful when you have a ton of commits after a merge and want to know the commit differences between branches.

log/*
tmp/*
storage/*
db/*.sqlite3
db/schema.rb
db/structure.sql
public/system
.project
.idea/
public/javascripts/all*
public/stylesheets/all*
public/stylesheets/*.css
config/database.yml
*~
*#*
.#*
.DS_Store
webrat-*.html
capybara-*.html
rerun.txt
coverage.data
coverage/*
dump_for_download.dump
.~lock.*
.*.swp
C:\\nppdf32Log\\debuglog.txt

As described by the linked Stackoverflow answer, run these commands:

sudo add-apt-repository ppa:git-core/ppa -y
sudo apt-get update
sudo apt-get install git
git --version

This will get you Git 2.6.4 (as of Dec 2015).

Troubleshooting

If you don't have add-apt-repository yet, install it with:

sudo apt-get install python-software-properties software-properties-common

Using the -U parameter you can change how many lines are shown above and below a changed section.

E.g. git diff -U10 will show 10 lines above and below.

• You probably haven't configured version control for your project.
• Go to Project Settings / Version Control and set the director <Project> to Git

Sometimes you may need to figure out what branches exist on a remote repository so you can pull them down and check them out, merge them into your local branches, etc. You can see the remote branches by saying

git branch -r

Or, if you want to see both local and remote branches, you can say

git branch -a

The problem isn't that Git is to hard, it's that smart developers are impatient and have exactly zero tolerance for unexpected behavior in their tools. While Git is the trendy thing right now, perhaps some day you will come across a grizzled developer who is using SVN, and when you ask him why, his answer won't make sense, because it's a Zen thing.

If you recorded a bad fix for a conflict, you can tell git to forget that bad resolution:

git rerere forget your_file.rb

Afterwards, the badly resolved file will still be in your working directory. To get it back with confict markers, say:

git checkout -m your_file.rb

Resolve the conflict again, properly now. ;)

Quick introduction to git internals for people who are not scared by words like Directed Acyclic Graph.

The linked page offers a simple yet concise explanation of how git is organized internally ('a directed acyclic graph with post-it notes'). Each feature is illustrated by a simple diagram, so you get a sound understanding of how each command affects git's structure.

git diff commit_hash -- path/to/file

Provide any commit hashes or branch names like "master" for commit_hash.

Git commands tend to come in groups. Avoid typing git over and over and over by running them in a dedicated git shell.

You might want to run git config --global help.autocorrect true before using gitsh. This will silently swallow a muscle-memory "git" prefix to your commands inside the git shell.

A nice way to stage absolutely all changes (edits, additions, deletions):

git add --all

While git branch will show you all branches and highlight the current one with an asterisk, it can be too cumbersome when working with lots of branches.

To show only the branch you are currently on, use:

git rev-parse --abbrev-ref HEAD

On case-insensitive file systems like Mac's HFS+ (per default – you may change this, but it won't work for all programs), git won't recognize when you change the casing of files in your repository.

Workaround

git mv -f oldfile.name Oldfile.name

git command line options for automating common rebasing tasks, like adding a fix to a commit that was already rebased into the history.

So you erased a whole day's work? There is hope! The linked article tells how to recover from an accidental git reset --hard.

On a Mac

You will need to install GNU find utils as described in this SO post.

I recently worked on a project with 60+ old feature branches. Most of them had been merged into master and were subsequently abandoned. We decided we wanted to clean up a bit, and git made that easy.

Make sure you understand differences between git's areas (such as stash, workspace, upstream, etc.) and what commands affect which areas.

When there's a Gemfile.lock in your working directory that you cannot remove by either checkout, reset [--hard], stash, probably Rails' Spring is the culprit and not Bundler itself.

Fix

spring stop

The author of the linked Stackoverflow post supposes Spring re-writes the Gemfile.lock on change to ensure all Spring processes are using the same gem versions. Meh.

In your ~/.gitconfig:

[core]
  editor=nano