Difference between revisions of "Git"

(New page)
(No difference)

Revision as of 15:40, 30 September 2013

This page provides details on how LIS staff can use Git to collaborate and version-control their projects. Excellent documentation on using Git is available on the web, so this page focuses on our particular work-flows rather than basic usage.

Recommended tools for working with Git


  • Git - The core Git command-line program and the Git-GUI user interface and the Gitk graphical history browser.
  • Source Tree - A nice GUI for working with Git.


  • Source Tree - A nice GUI for working with Git that includes helpers for managing SSH keys.


  • Git - The core Git command-line program and the Git-GUI user interface and the Gitk graphical history browser.

Remote Linux hosts via X11

One common work-flow is to do your work on a remote Linux host from a Mac or Windows workstation. You will usually open a remote shell via Terminal (OS X) or Putty (Windows) so that you can get a command-line on the remote Linux host. If the Linux host has Git installed, you can use it's command-line interface through your terminal. Additionally, you can usually also use the graphical Git GUI and Gitk interfaces by running an X11 server on your workstation.

The X11 has been around for decades and lets you easily run GUI programs across the network. X11 has an inverted client-server model from what most of us are used to: Your work-station runs an X11 'server' program that draws the GUI on your screen, while the X11 'client' is a program on the remote host that sends drawing commands to the server on your work-station.

  1. Install the X11-server on your workstation.
  2. Open a remote shell with SSH providing x-forwarding.
    • On OS X run ssh -X user@host Your Terminal should automatically start XQuartz when you run ssh with the -X parameter.
    • On Windows open Putty and _________.

Central Repositories

The .git/ directory in your project is a full 'repository' and contains all of the changes sets that make up your project's history. It is perfectly fine to use git without ever interacting with remote services. That said, often we need to share our projects with others to collaborate as well as to make sure that our valuable efforts are backed up. To enable sharing, we push our change-sets from our local working repository to a central repository that is accessible by others in our 'team'. For our open-source development efforts that we share freely with the world, we use GitHub as our central-repository host as it aids collaboration with others outside of the institution. For projects that we don't share with the world we run a local Gitolite server ([1]) that provides protected project hosting.


vcs.middlebury.edu hosts our private git repositories for LIS. Access to these repositories is provided via ssh (for cloning/pushing) and http (for code/change-set browsing). Adam Franco manages access to these repositories.

Web browsing

To browse code and change-sets via the web, point your browser at https://vcs.middlebury.edu/git/ and log in with your Active Directory credentials. You will only see a listing of projects that you have been granted access to -- contact Adam for additional access if required.

Setting up SSH authentication

Clone and push access to repositories is provided via ssh using password-less (public-key/private-key) authentication. Once your SSH key is configured on your work-station and granted access on the host, your command-line or GUI tools can work with all of your authorized repositories without additional configuration.

  1. Create an RSA public-key/private-key pair.
    • UNIX-like systems (OS X, Linux, etc): Use ssh-keygen -t rsa. Generally, these will be created without a passphrase locking them.
    • SourceTree on Windows: _______
  2. Send Adam your public key via email. He will add it to the server configuration to provide you access. If this is your first key, please mention which repositories you need access to.
  3. Configure your Git tools to use your new SSH key.
    • UNIX systems (OS X, Linux, etc): Tools using ssh will usually look for a key file in your home directory at ~/.ssh/id_rsa and use that by default. If you only have this one key, you shouldn't have to configure anything else. If you have multiple keys, then you can add an entry to your ~/.ssh/config to force usage of a particular key-file when communicating with vcs.middlebury.edu.
    • SourceTree on Windows: __________

Troubleshooting SSH issues

  • The first time you make an SSH connection to vcs.middlebury.edu you need to add the server's SSH public-key to your SSH client's known-hosts list. The fingerprint should be d8:b5:1b:2f:f5:89:82:ee:0a:ad:4e:8b:f4:3e:a2:b0. Note that some GUI clients are not able to prompt you to accept the public key and will fail or hang if they are the first clients you are using to contact the host. In this case, try cloning or fetching from vcs.middlebury.edu from a command-line client first.
  • If SSH public-key/private-key authentication is working correctly you should *not* be prompted for a password. If you are prompted for a password then that is an indication that they key-based authentication isn't working for some reason.