From 36d8c70185937c89de0818b67eee54522592feab Mon Sep 17 00:00:00 2001
From: "W. Trevor King" <wking@tremily.us>
Date: Mon, 10 Jun 2013 12:54:29 -0400
Subject: [PATCH] cheet-sheet.md: Add a Git-specific cheat sheet

READMEs and COPYING are all well and good, but this project will
probably make more sense if it has some actual content that it's
trying to development.  I'll use the cheat sheet from
http://git.tremily.us/?p=swc-version-control-git.git as an example,
but this would usually be a paper you're writing or code you're using
in your research, or something else you find interesting.

After writing the file in your text editor, staging and committing it
is the usual:

  $ git add cheat-sheet.md
  $ git commit --all --verbose

The long form options (`--all` and `--verbose`) also have short-form
aliases (`-a` and `-v`), which is why the cheat sheet suggests:

  $ git commit -a ...

That is the same as:

  $ git commit --all ...

Because I think this commit gets things into a useful state, I'll tag
it as version 1.0 and release it to the world.  You can tag the last
commit with:

  $ git tag v1.0
---
 cheat-sheet.md | 102 +++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 102 insertions(+)
 create mode 100644 cheat-sheet.md

diff --git a/cheat-sheet.md b/cheat-sheet.md
new file mode 100644
index 0000000..0b6a9bd
--- /dev/null
+++ b/cheat-sheet.md
@@ -0,0 +1,102 @@
+Basic use
+=========
+
+* Create a local repository from a public repository at `$URL`:
+
+        $ git clone $URL
+
+* Stage a (possibly new) file (or files) for the next commit:
+
+        $ git add $FILES
+
+* Remove a file (or files) with the next commit:
+
+        $ git rm $FILES
+
+* Commit any local changes to the local repository:
+
+        $ git commit -a -m "$MESSAGE"
+
+* Push any local commits to a public repository (e.g. `origin`):
+
+        $ git push origin
+
+Merging
+=======
+
+* Update your local view of a public repository (e.g. `origin`):
+
+        $ git fetch origin
+
+* Merge new commits from another branch (e.g. the `origin/master`
+  branch tracking the `master` branch of the `origin` repository):
+
+        $ git merge origin/master
+
+* Mark conflicts as resolved:
+
+        $ git add $FILES
+
+Comparing changes
+=================
+
+* Compare the current working directory to the last commit:
+
+        $ git diff HEAD
+
+Browsing history
+================
+
+* Check your local state:
+
+        $ git status
+
+* View past commits:
+
+        $ git log
+
+* Who wrote this line, and what were they thinking?
+
+        $ git blame $FILES
+        $ git show $COMMIT_HASH
+
+Recovering old versions
+=======================
+
+* Undo local changes to `$FILES` since the last commit:
+
+        $ git checkout $FILES
+
+* Checkout `$FILES` as they were during `$COMMIT`:
+
+        $ git checkout $COMMIT -- $FILES
+
+* Create a new commit backing out changes made by an old commit:
+
+        $ git revert $COMMIT
+
+Setting up a repository
+=======================
+
+* Create a new repository in the current directory:
+
+        $ git init
+
+Provenance
+==========
+
+* Tag releases:
+
+        $ git tag v1.2.3
+        $ git push --tags origin
+
+* Incorperate the tags into any releases.  For example, the Git
+  project extracts [version information][git-version-gen] when you
+  [compile the project][git-makefile].  Most Python projects just
+  increment `package.__version__` by hand
+  (e.g. [pygit2][pygit2-version]).
+
+
+[git-version-gen]: http://git.kernel.org/cgit/git/git.git/tree/GIT-VERSION-GEN
+[git-makefile]: http://git.kernel.org/cgit/git/git.git/tree/Makefile
+[pygit2-version]: https://github.com/libgit2/pygit2/blob/master/pygit2/version.py
-- 
2.26.2