Skip to content

Instantly share code, notes, and snippets.

@yegeniy
Last active February 9, 2017 10:05
Show Gist options
  • Star 5 You must be signed in to star a gist
  • Fork 2 You must be signed in to fork a gist
  • Save yegeniy/1125520 to your computer and use it in GitHub Desktop.
Save yegeniy/1125520 to your computer and use it in GitHub Desktop.
git: commands I commonly use, relevant ramblings, and configuration.
Function to checkout and pull a git branch.

The bash function below, gcp (git checkout and pull), will check out an up-to-date version of a given branch name from the origin remote.

gcp() { if [ $1 ]; then echo "> git checkout ${1}" && git checkout $1 && echo "> git pull origin ${1}" && git pull origin $1 && git status -sb; fi }

This should fail-fast for most cases. Usage below:

~> gcp master
> git checkout master
fatal: Not a git repository (or any parent up to mount parent /Users)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
~> cd my/repo
~/my/repo> gcp master
> git checkout master
Already on 'master'
> git pull origin master
From github.com:yegeniy/yegeniy.github.io
 * branch            master    -> FETCH_HEAD
Already up-to-date.
## master
~/my/repo> gcp fakebranch
> git checkout fakebranch
error: pathspec 'fakebranch' did not match any file(s) known to git.

This could be extended to work with non-default remotes for the usage gcp remote branch.

Commands I Commonly Use

  1. Clone an existing repository:

    git clone <repo>

    (e.g. https://gist.github.com/1125520.git).

  2. Checkout and pull an existing branch:

    gcp master
  3. Create new local branch:

    git checkout -b newbranch
  4. Interact with the current working tree:

    alias tigs='tig status'

    Helpful for staging and creating commits, viewing the current diff, and even for resolving merge conflicts.

  5. Push master branch to default remote (called origin):

    git push origin master
  • Output current working tree status:

    alias gits='git status'

    useful as a sanity check.

  • Temporarily put away your current work:

    git stash
  • Resume working on the latest stashed work:

    git stash apply
  • Change latest commit:

    git commit --amend

    however, as a rule, don't do this to published commits.

  • (could be harmful.. don't blindly push --force after this). Update outdated branch with all of master branch's latest commits:

    gcp master && git checkout outdated && git rebase -i origin/master

    This changes the commit log history so that commits unique to the outdated branch are moved to after the latest commit in origin/master.

  • A safer alternative to rebasing is to merge master into your outdated branch:

    gcp outdated && git merge origin/master

    Some would argue that this approach unnecessarily pollutes your commit log.

  • To merge a completed branch (devbranch) into a sacred branch (master) use GitHub's Pull Requests, instead of doing:

    gcp master && git pull origin devbranch && git push origin master
  • Install and view the git cheatsheet locally:

    gem install cheat && cheat git | less

Configuration

As with most of the rest of this gist, this is mostly me cherrypicking the git-scm book and GitHub help pages.

$ git config --global user.name <full_name>
$ git config --global user.email <email>
$ git config --global merge.conflictstyle diff3
$ git config --global diff.algorithm patience
$ git config --global color.ui true
$ git config --global tig.color.cursor "black white bold"
# open https://help.github.com/articles/ignoring-files#global-gitignore
$ git config --global core.excludesfile ~/.gitignore_global
# OS X only:
$ git config --global credential.helper osxkeychain

Relevant Ramblings

Getting Started

For a 15 minute tutorial, check out http://try.github.io - except at the end, instead of writing git push, you should use the git push remote branch variant (much safer, as far as I understand). For a FAQ, check out https://help.github.com/ For a well-written and comprehensive book, with lots of tips, check out http://git-scm.com/documentation

Branching
  • To get the latest version of an existing branch foo (from the default remote called origin),
git checkout foo
git pull origin foo
git status -sb

or you can use this function to checkout and pull a git branch.

  • For a new branch bar: git checkout -b bar
  • To overwrite a branch bar with the current working tree: git checkout -B bar
Committing

The default git status command should give fairly useful instructions for how to stage files for a commit, assuming you're familiar with all the git vocabulary. The basic idea is that changes are staged, prior to being committed.

  1. Stage from the working directory into the staging area using git add ....
  2. Commit from the staging area into the repository using git commit.

There are many ways to accomplish this workflow. I prefer to do it with a tool called tig. Tig is a pretty intuitive text interface for git. I like to use it to prepare the commit, relying on a sane default editor (echo $EDITOR) to compose the commit message. I also find tig helpful with the following: to browse commit logs (press enter in default view), as an interface for the working tree (press Shift-s from default view), and to view diffs/blame (press d on any commit) outside of GitHub pull requests.

brew install tig
alias tigs='tig status'
tig

Commit messages are mandatory, so if you decide to cancel a commit while composing a message, make an empty commit message, then save and exit from the file.

These are pretty much the only commands you need for stashing, as long as you only stash one working state onto the stash stack.

> git stash save
> git stash apply

If you want to work with more than one set of stashes, use the list, show and apply commands for more complicated tasks, (> man git-stash for more info on the syntax)

> git stash list
> git stash show @{0}
> git stash show @{1}

Don't forget to learn about the patch-form (i.e. git stash show -p). It's particularly useful for when you are not sure which stash has the changes you're looking for.

Miscellaneous

fetch is actually a common command. It starts tracking new remote branches:

> git fetch

gc garbage collects and calls prune. There is rarely a reason to call this:

> git gc

If you delete a file accidentally, you can undo this change with a

> git checkout -- <path/to/deleted/file>

If you want to delete a remote branch, pushing nothing into it will accomplish the task. Feel free to wait a few days after merging the branch into master though.

> git push origin :feature/eugene_test1

View the merge base during merge conflicts. http://blog.wuwon.id.au/2010/09/painless-merge-conflict-resolution-in.html

> git config --global merge.conflictstyle diff3

git-svn

These are very rough instructions. Take with a grain of salt.

  • First, pull down the SVN repo with git svn clone <url>.
  • Use git locally, as you would normally, but once you are ready to push back up to the SVN repo, merge your changes into the master branch and do the following steps:
    • git svn rebase is similar to a git pull. Might help to run git svn rebase this before you push to the repository.
    • Push up changes from the master branch using git svn dcommit --rmdir. The --rmdir option will delete empty folders in the svn repo. Only include if you know what you're doing.
  • Your working tree must be clean to do a git svn dcommit or a git svn rebase, so leverage git stash and git stash apply.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment