Skip to content

Instantly share code, notes, and snippets.

@jasonhwest
Created August 2, 2016 19:06
Show Gist options
  • Save jasonhwest/66d84debf1c42793d8154f099c96e90f to your computer and use it in GitHub Desktop.
Save jasonhwest/66d84debf1c42793d8154f099c96e90f to your computer and use it in GitHub Desktop.

GIT

  • create a new repository
    • create a new directory, open it and perform a git init to create a new git repository.
  • checkout a repository
    • create a working copy of a local repository by running the command git clone /path/to/repository when using a remote server, your command will be git clone username@host:/path/to/repository
  • add & commit
    • You can propose changes (add it to the Index) using git add <filename> git add * This is the first step in the basic git workflow. To actually commit these changes use git commit -m "Commit message" Now the file is committed to the HEAD, but not in your remote repository yet.
  • pushing changes
    • Your changes are now in the HEAD of your local working copy. To send those changes to your remote repository, execute git push origin master Change master to whatever branch you want to push your changes to. If you have not cloned an existing repository and want to connect your repository to a remote server, you need to add it with git remote add origin <server> Now you are able to push your changes to the selected remote server
  • branches
    • create a new branch named "feature_x" and switch to it using git checkout -b feature_x switch back to master git checkout master and delete the branch again git branch -d feature_x a branch is not available to others unless you push the branch to your remote repository git push origin <branch>
  • update & merge
    • to update your local repository to the newest commit, execute git pull in your working directory to fetch and merge remote changes. to merge another branch into your active branch (e.g. master), use git merge <branch> in both cases git tries to auto-merge changes. Unfortunately, this is not always possible and results in conflicts. You are responsible to merge those conflicts manually by editing the files shown by git. After changing, you need to mark them as merged with git add <filename> before merging changes, you can also preview them by using git diff <source_branch> <target_branch>
  • tagging
    • it's recommended to create tags for software releases. this is a known concept, which also exists in SVN. You can create a new tag named 1.0.0 by executing git tag 1.0.0 1b2e1d63ff the 1b2e1d63ff stands for the first 10 characters of the commit id you want to reference with your tag.
  • log
    • in its simplest form, you can study repository history using.. git log You can add a lot of parameters to make the log look like what you want. To see only the commits of a certain author: git log --author=bob To see a very compressed log where each commit is one line: git log --pretty=oneline Or maybe you want to see an ASCII art tree of all the branches, decorated with the names of tags and branches: git log --graph --oneline --decorate --all See only which files have changed: git log --name-status These are just a few of the possible parameters you can use. For more, see git log --help
  • replace local changes
    • In case you did something wrong, which for sure never happens ;), you can replace local changes using the command git checkout -- <filename> this replaces the changes in your working tree with the last content in HEAD. Changes already added to the index, as well as new files, will be kept. If you instead want to drop all your local changes and commits, fetch the latest history from the server and point your local master branch at it like this git fetch origin git reset --hard origin/master

Research

Configuration

  • git config --global url."https://github.com/".insteadOf git@github.com:
  • git config --global url."https://".insteadOf git://

CLI

  • Update Master/Branches
git checkout master         # switches to the master branch
git pull origin master      # updates local master with changes from remote master
git checkout <branch>       # switch to working branch(es)
git merge master            # merge changes from local master into working branch
  • New Branch
git checkout -b <branch>    # create a local branch
  • Commits
git add <files>             # add files to the stage for a commit
git commit -m 'commit msg'  # commits staged files to local repo
  • Push PR to Stash
git push -u origin <branch>
STASH - Create a PR and add some reviewers
  • Delete Branch after PR
STASH - merge the PR to master in Stash and delete your branch
git checkout master          # switches to the master branch
git pull origin master       # updates local master with changes from remote master
git remote prune origin      # deletes all stale remote-tracking branches under origin
git branch -d <branch>       # deletes the local branch
  • Setup and Ad Hoc
	# clones the specified url in the given dir
	git clone <url> <directory>

	# rename the current branch
	git branch -m <newname>

	# show files committed to git branch
	git log --name-status --oneline origin..HEAD

	# compares the files ignoring whitespace
	git diff -b <filename>
git add -p
  • Rather than git add everything or individual files, this -p will allow you to step through each change, or hunk, and decide if you’d like to commit it. This is really handy if you have made two different changes to the same file and want to commit them separately.
git log -5 --pretty --oneline
  • View your last 5 latest commits each on their own line.
git shortlog -sn
  • Quickly get a list of contributors and see how many commits each person has.
git log --all --graph --decorate --oneline --simplify-by-decoration
  • This one is the best – you need to see what it does visually. You’ll never remember this one so put it in your ~/.gitconfig file under [alias] wow = log --all --graph --decorate --oneline --simplify-by-decoration
git checkout pr/123
git diff --shortstat "@{0 day ago}"
  • See how many lines of code you have written today.
git checkout -
  • It’s like the jump button on your TV remote – jump back to to your last branch.
git reset --soft HEAD~3
  • A soft reset will keep your changes but allow you to “uncommit” something. Instead of doing a squash, Dan prefers to dial back HEAD any number of commits and then add & commit everything into a single commit.
git reflog
  • David says it best — “Don’t worry, it’s probably saved somewhere”. Git reflog allows you to see every step you have made with git allowing you to retract and reinstate your steps.
git stash, then git stash pop
  • Stash let’s you squirrel away unstaged changes, do some work, and then apply those changes back on. git stash will stash those changes and put them into your list — I like to think of this as an array of changes. Now to get them back you can git stash apply but what Sam is suggesting here is that you use git stash pop instead which will also bring back your changes, but it removes them from your stash “array”.
git log -S puppy
  • Search the commit history for the word puppy and display matching commits.
git latest = for-each-ref --count=30 --sort=-committerdate refs/heads/ --format='%(refname:short)’
  • Allows you to view your latest branchces – this is helpful for when your branch names are based on bug IDs that you have a hard time remembering.
git config --global help.autocorrect -1
  • Mistype or misspell a git command? Immediately re-run the correct command. You can use -1 to 1000 to wait a full second before the command is re-run.
git commit --amend
  • Great for squashing staged files into your last commit.
git cherry-pick [hash]
  • As long as the commit has been fetched somewhere, you can cherry pick that code in your own branch without having to merge the entire thing.
git remote update --prune
  • Remove local branches that have been deleted from your remote (like GitHub). You can always run git remote prune origin --dry-run to see what will be deleted before going all in.
git rebase -i HEAD~4
  • Interactive rebase allows you to pick and choose which commits you can pick, squash, reword, edit, or fixup
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment