• File states
    Git has three main states that your files can reside in: committed, modified, and staged. Committed means that the data is safely stored in your local database. Modified means that you have changed the file but have not committed it to your database yet. Staged means that you have marked a modified file in its current version to go into your next commit snapshot. Each file in your working directory can be in one of two states: tracked or untracked. Tracked files are files that were in the last snapshot; they can be unmodified, modified, or staged. Untracked files are everything else – any files in your working directory that were not in your last snapshot and are not in your staging area. When you first clone a repository, all files will be tracked and unmodified.
  • Cloning an Existing Repository
    $ git clone [url]

    For example,
    $ git clone https://github.com/libgit2/libgit2
    This creates a directory named “libgit2”, initializes a .git directory inside it, pulls down all the data for that repository, and checks out a working copy of the latest version. If you want to clone the repository into a directory named something other than “libgit2”, you can specify that as the next command-line option:
    $ git clone https://github.com/libgit2/libgit2 mylibgit
  • Checking the Status of Your Files
    $ git status
    On branch master
    Your branch is up-to-date with 'origin/master'.
    nothing to commit, working directory clean
    This means you have a clean working directory – in other words, there are no tracked and modified files. The command also tells branch name.Let’s say you add a new file to your project, a simple README file. If the file
    didn’t exist before, and you run git status, you see your untracked file like
    $ echo 'My Project' > README
    $ git status
    On branch master
    Your branch is up-to-date with 'origin/master'.
    Untracked files:
    (use "git add <file>..." to include in what will be committed)
    README
    nothing added to commit but untracked files present (use "git add" to track)
    New README file is untracked, because it’s under the “Untracked files” heading in status output. Untracked basically means that Git sees a file that didn’t have in the previous snapshot (commit).
  • Tracking New Files
    In order to begin tracking a new file, you use the command git add.

    $ git add README If you run your status command again, you can see that your README file is now tracked and staged to be committed:
    $ git status
    On branch master
    Your branch is up-to-date with 'origin/master'.
    Changes to be committed:
    (use "git reset HEAD <file>..." to unstage)
    new file: README
  • Staging Modified Files
    If you change a previously tracked file called CONTRIBUTING.md and then run your git status command again, you get something that looks like this:
    $ git status
    On branch master
    Your branch is up-to-date with 'origin/master'.
    Changes to be committed:
    (use "git reset HEAD <file>..." to unstage)
    new file: README
    Changes not staged for commit:
    (use "git add <file>..." to update what will be committed)
    Recording Changes to the Repository
    (use "git checkout -- <file>..." to discard changes in working directory)
    modified: CONTRIBUTING.md
    The CONTRIBUTING.md file appears under a section named “Changes not staged for commit” – which means that a file that is tracked has been modified in the working directory but not yet staged. To stage it, you run the git add command. 
    $ git add CONTRIBUTING.md
    $ git status
    On branch master
    Your branch is up-to-date with 'origin/master'.
    Changes to be committed:
    (use "git reset HEAD <file>..." to unstage)
    new file: README
    modified: CONTRIBUTING.md
    Suppose you remember one little change that you want to make in CONTRIBUTING.md before you commit it. You open it again and make that change, and you’re ready to commit. However, let’s run git status one more time:
    $ vim CONTRIBUTING.md
    $ git status
    On branch master
    Your branch is up-to-date with 'origin/master'.
    Changes to be committed:
    (use "git reset HEAD <file>..." to unstage)
    new file: README
    modified: CONTRIBUTING.md
    Changes not staged for commit:
    (use "git add <file>..." to update what will be committed)
    (use "git checkout -- <file>..." to discard changes in working directory)
    modified: CONTRIBUTING.md
    Now CONTRIBUTING.md is listed as both staged and unstaged. Git stages a file exactly as it is when you run the git add command. If you commit now, the version of CONTRIBUTING.md as it was when you last ran the git add command is how it will go into the commit, not the version of the file as it looks in your working directory when you run git commit. If you modify a file aft er you run git add, you have to run git add again to stage the latest version of the file.
  • Ignoring Files
    $ cat .gitignore
    *.[oa]
    *~
    The first line tells Git to ignore any files ending in “.o” or “.a” – object and archive files that may be the product of building your code. The second line tells Git to ignore all files whose names end with a tilde (~).
  • Viewing Your Staged and Unstaged Changes
    git diff is  used to answer these two questions: What have you changed but not yet staged? And what have you staged that you are about to commit? It shows the exact lines added and removed – the patch, as it were.
    To see what you’ve changed but not yet staged, type git diff with no other arguments:
    $ git diff
    diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
    index 8ebb991..643e24f 100644
    --- a/CONTRIBUTING.md
    +++ b/CONTRIBUTING.md
    @@ -65,7 +65,8 @@ branch directly, things can get messy.
    Please include a nice description of your changes when you submit your PR;
    if we have to read the whole diff to figure out why you're contributing
    in the first place, you're less likely to get feedback and have your change
    -merged in.
    +merged in. Also, split your changes into comprehensive chunks if your patch is
    +longer than a dozen lines.
    If you are starting to work on a particular area, feel free to submit a PR
    that highlights your work in progress (and note in the PR title that it's
    That command compares what is in your working directory with what is in your staging area. The result tells you the changes you’ve made that you haven’t yet staged.If you want to see what you’ve staged that will go into your next commit, you can use git diff –staged. This command compares your staged changes to your last commit:
    $ git diff --staged
    diff --git a/README b/README
    new file mode 100644
    index 0000000..03902a1
    --- /dev/null
    +++ b/README
    @@ -0,0 +1 @@
    +My Project
  • Committing Your Changes
    Anything that is still unstaged – any files you have created or modified that you haven’t run git add on since you edited them  won’t go into this commit. To commit enter
    $ git commit
    If you want to skip the staging area, Git provides a simple shortcut. Adding the -a option to the git commit command makes Git automatically stage every file that is already tracked before doing the commit, letting you skip the git add part.
  • Removing Files
    To remove a file from Git, you have to remove it from your tracked files (more accurately, remove it from your staging area) and then commit. The git rm command does that, and also removes the file from your working directory so you don’t see it as an untracked file the next time around. Another useful thing you may want to do is to keep the file in your working tree but remove it from your staging area. In other words, you may want to keep the file on your hard drive but not have Git track it anymore.  To do this, use the –cached option:
    $ git rm --cached README
  • Moving Files
    If you want to rename a file in Git, you can run something like:
    $ git mv file_from file_to
    and it works fine. In fact, if you run something like this and look at the status, you’ll see that Git considers it a renamed file.
  • Viewing the Commit History
    If you have cloned a repository with an existing commit history, you’ll probably want to look back to see what has happened. One can use git log command. One of the more helpful options is -p, which shows the difference introduced in each commit. You can also use -2, which limits the output to only the last two entries.  If you want to see some abbreviated stats for each commit, you can use the –stat option. Another really useful option is –pretty. This option changes the log output to formats other than the default. However, the time-limiting options such as –since and –until are very useful. For example, this command gets the list of commits made in the last two
    weeks:
    $ git log --since=2.weeks
    You can also filter the list to commits that match some search criteria. The –author option allows you to filter on a specific author, and the –grep option lets you search for keywords in the commit messages
  • To commit again to the current commit, run commit with the –amend option:
    $ git commit --amend
    This command takes your staging area and uses it for the commit. If you’ve made no changes since your last commit (for instance, you run this command immediately after your previous commit), then your snapshot will look exactly the same, and all you’ll change is your commit message.
  • Unstaging file
    git reset
  • Unmodifying a Modified File, use $ git checkout
    $ git checkout -- CONTRIBUTING.md
    $ git status
    On branch master
    Changes to be committed:
    (use "git reset HEAD <file>..." to unstage)
    renamed: README.md -> README
  • Showing Remotes
    To see which remote servers you have configured, run the git remote command. It lists the shortnames of each remote handle you’ve specified.
    $ git remote -v
    origin https://github.com/schacon/ticgit (fetch)
    origin https://github.com/schacon/ticgit (push)
  • Adding Remote Repositories
    To add a new remote Git repository as a shortname, run git remote add <shortname> <url>:
    $ git remote
    origin
    $ git remote add pb https://github.com/paulboone/ticgit
  • Fetching and Pulling from Your Remotes
    To get data from your remote projects, you can run:
    $ git fetch [remote-name]
    git fetch origin fetches any new work that has been pushed to that server since you cloned (or last fetched from) it. It’s important to note that the git fetch command only downloads
    the data to your local repository – it doesn’t automatically merge it with any of your work or modify what you’re currently working on.
  • When you have your project at a point that you want to share, you have to push it upstream.
    git push [remote-name] [branch-name]
    If you want to push your master branch to your origin server (again, cloning generally sets up both of those names for you automatically), then you can run this to push any commits you’ve done back up to the server:
    $ git push origin master
  • Inspecting a Remote
    If you want to see more information about a particular remote, you can use the
    git remote show [remote-name]
    If you run this command with a particular shortname, such as origin, you get something like this:
    $ git remote show origin
    * remote origin
    Fetch URL: https://github.com/schacon/ticgit
    Push URL: https://github.com/schacon/ticgit
    HEAD branch: master
    Remote branches:
    master tracked
    dev-branch tracked
    Local branch configured for 'git pull':
    master merges with remote master
    Local ref configured for 'git push':
    master pushes to master (up to date)
    It lists the URL for the remote repository as well as the tracking branch information. The command helpfully tells you that if you’re on the master branch and you run git pull, it will automatically merge in the master branch on the remote after it fetches all the remote references. It also lists all the remote references it has pulled down.