Git clients

Git Bash
Command line Git client Git Bash git for windows
Git Extensions –
Git Extensions is the only graphical user interface for Git that allows you control Git without using the commandline Git Extensions


Getting started

Create a new repository on the command line

echo # KingstonDataScienceWebSite >>

git init
git add
git commit -m "first commit"
git remote add origin
git push -u origin master

Push an existing repository from the command line

git remote add origin
git push -u origin master

Basic Commands

You can get a Git project using two main approaches. The first takes an existing project or directory and imports it into Git. The second clones an existing Git repository from another server.

Initializing a Repository in an Existing Directory

If you’re starting to track an existing project in Git, you need to go to the project’s directory and type

$ git init
Initialized empty Git repository in c:/Users/Administrator/gitHubWork/.git/
  1. git/git Bash Make sure a SSH cert with blank password has been setup Generating SSH keys
  2. If you get “Could not open a connection to your authentication agent.”, run eval $(sshagent)

Cloning an Existing Repository

You clone a repository with git clone [url]

If you’re familiar with other VCS systems such as Subversion, you’ll notice that the command is “clone” and not “checkout”
$ git clone
Cloning into 'resourcestopxe'...

Checking the Status of Your Files

The lifecycle of the status of your files
$ git status
On branch master
Untracked files:
  (use "git add <file>..." to include in what will be committed)


nothing added to commit but untracked files present (use "git add" to track)

Tracking New Files

In order to begin tracking a new file and staged to be committed. If you commit at this point, the version of the file at the time you ran git add is what will be in the historical snapshot. The git add command takes a path name for either a file or a directory; if it’s a directory, the command adds all the files in that directory recursively.

$ git add README

$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    new file:   README

Staging Modified Files

Let’s change a file that was already tracked. If you change a previously tracked file, use git add which is a multipurpose command – you use it to begin tracking new files, to stage files, and to do other things like marking merge-conflicted files as resolved.

$ git status
On branch 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)
  (use "git checkout -- <file>..." to discard changes in working directory)


For example, let’s say you’ve changed two files and want to commit them as two separate changes, but you accidentally type git add * and stage them both. How can you unstage one of the two? Right below the “Changes to be committed” text, it says use git reset HEAD <file>… to unstage. So, let’s use that advice to unstage the file:

$ git add .
$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>.

$ git reset HEAD

Ignoring Files

These are generally automatically generated files such as log files or files produced by your build system. In such cases, you can create a file listing patterns to match them named .gitignore with the following:


Setting up a .gitignore file before you get going is generally a good idea so you don’t accidentally commit files that you really don’t want in your Git repository.

  • Blank lines or lines starting with # are ignored
  • You can negate a pattern by starting it with an exclamation point (!).
  • You can end patterns with a forward slash (/) to specify a directory.
  • An asterisk (*) matches zero or more characters
  • [abc] matches any character inside the brackets (in this case a, b, or c)
  • A question mark (?) matches a single character
  • brackets enclosing characters separated by a hyphen([0-9]) matches any character between them (in this case 0 through 9).
  • You can also use two asterisks to match nested directories **

Viewing Your Staged and Unstaged Changes

If the git status command is too vague for you – you want to know exactly what you changed, not just which files were changed – you can use the git diff command.

  • To see what you’ve changed but not yet staged, type
     git diff

    with no other arguments.

  • 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 --cached

    to see what you’ve staged so far.

Committing Your Changes

Remember that 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. They will stay as modified files on your disk. Default commit message contains the latest output of the git status command commented out and one empty line on top.

$ git commit -m "Story 182: Fix benchmarks for speed"
[master 463dc4f] Story 182: Fix benchmarks for speed
 2 files changed, 2 insertions(+)
 create mode 100644 README

Remember that the commit records the snapshot you set up in your staging area. Anything you didn’t stage is still sitting there modified; you can do another commit to add it to your history. Every time you perform a commit, you’re recording a snapshot of your project that you can revert to or compare to later.

  • Git Commit and Add combined – skips the stagin area
$ git commit -a -m 'added new benchmarks'

$ git commit -m 'initial commit'
$ git add forgotten_file
$ git commit --amend

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 next time you commit, the file will be gone and no longer tracked.

$ git rm
$ git commit

Moving Files

If you rename a file in Git, no metadata is stored in Git that tells it you renamed the file. Thus it’s a bit confusing that Git has a mv command. If you want to rename a file in Git, you can run something like

$ git mv file_from file_to

Git figures out that it’s a rename implicitly, so it doesn’t matter if you rename a file that way or with the mv command.

Viewing the Commit History

$ git log
$ git log --pretty=oneline
$ git log --pretty=format:"%h - %an, %ar : %s"
$ git log --pretty=format:"%h %s" --graph

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:

Unmodifying a Modified File

It’s important to understand that git checkout — [file] is a dangerous command. Any changes you made to that file are gone – you just copied another file over it. Don’t ever use this command unless you absolutely know that you don’t want the file.

Showing/Add Your Remotes

To be able to collaborate on any Git project, you need to know how to manage your remote repositories. Remote repositories are versions of your project that are hosted on the Internet or network somewhere.

$ git remote -v
  • To add a new remote Git repository as a shortname you can reference easily, run git remote add [shortname] [url]:

Fetching and Pulling from Your Remotes

The command goes out to that remote project and pulls down all the data from that remote project that you don’t have yet. After you do this, you should have references to all the branches from that remote, which you can merge in or inspect at any time.

$ git fetch [remote-name]

If you clone a repository, the command automatically adds that remote repository under the name “origin”. So, 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 pulls 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. You have to merge it manually into your work when you’re ready.

Use the git pull command to automatically fetch and then merge a remote branch into your current branch

git pull

Pushing to Your Remotes

When you have your project at a point that you want to share, you have to push it upstream. The command for this is simple: 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


Typically people use this functionality to mark release points (v1.0, and so on). You can see that you’ve tagged the commit. When you have tagged your work REMEMBER to push the tags into the Git repo.

$ git tag -a v1.4 -m 'my version 1.4'
$ git tag
$ git show v1.2
$ git push --tags

Checking out Tags

If you want to put a version of your repository in your working directory that looks like a specific tag, you can create a new branch at a specific tag with git checkout -b [branchname] [tagname]:

$ git checkout -b version2 v2.0.0
Switched to a new branch 'version2'

Moving Files from one Git Repository to Another, Preserving history

  • Move directory 1 from Git repository A to Git repository B.
  • Exclude some folder as Git repository A contains other directories that we don’t want to move
  • Perserve the Git commit history for the directory we are moving.

1. Get files in repository A ready

Make a copy of repository A so you can mess with it without worrying about mistakes too much.  It’s also a good idea to delete the link to the original repository to avoid accidentally making any remote changes (line 3).  Line 4 is the critical step here.  It goes through your history and files, removing anything that is not in directory 1.  The result is the contents of directory 1 spewed out into to the base of repository A.  You probably want to import these files into repository B within a directory, so move them into one now (lines 5/6). Commit your changes and we’re ready to merge these files into the new repository.

git clone <git repository A url>
cd <git repository A directory>
git remote rm origin
git filter-branch --subdirectory-filter <directory 1> -- --all
mkdir <directory 1>
mv * <directory 1>
git add .
git commit

2. Merge files from repository A into new repository B

Make a copy of repository B if you don’t have one already.  On line 3, you’ll create a remote connection to repository A as a branch in repository B.  Then simply pull from this branch (containing only the directory you want to move) into repository B.  The pull copies both files and history.  Note: You can use a merge instead of a pull, but pull worked better for me. Finally, you probably want to clean up a bit by removing the remote connection to repository A. Commit and you’re all set.

git clone <git repository B url>
cd <git repository B directory>
git remote add repo-A-branch <git repository A directory>
git pull repo-A-branch master
git remote rm repo-A-branch

You will now see the files in the repository B being updated with the latest code from repository A.


Duplicating a repository

To create a duplicate of a repository without forking, you need to run a special clone command against the original repository and mirror-push to the new one.

In the following cases, the repository you’re trying to push to–like exampleuser/new-repository orexampleuser/mirrored–should already exist on GitHub. See “Creating a new repository” for more information.

Mirroring a repository

To make an exact duplicate, you need to perform both a bare-clone and a mirror-push.

Open up the command line, and type these commands:

git clone --bare
# Make a bare clone of the repository

cd old-repository.git
git push --mirror
# Mirror-push to the new repository

cd ..
rm -rf old-repository.git
# Remove our temporary local repository

If you want to mirror a repository in another location, including getting updates from the original, you can clone a mirror and periodically push the changes.

git clone --mirror
# Make a bare mirrored clone of the repository

cd repository-to-mirror.git
git remote set-url --push origin
# Set the push location to your mirror

As with a bare clone, a mirrored clone includes all remote branches and tags, but all local references will be overwritten each time you fetch, so it will always be the same as the original repository. Setting the URL for pushes simplifies pushing to your mirror. To update your mirror, fetch updates and push, which could be automated by running a cron job.

git fetch -p origin
git push --mirror