GitHub User Guide

ITaP Research Computing operates a local instance of GitHub. This instance offers all the features of github.com, however, under the control of and hosted by ITaP and is integrated with Purdue Career Accounts. Each research group can be provided with and given full control over an organization within the GitHub instance where repositories can be created and access configured as desired. Repositories can also be made private to groups to protect work not meant to be publicly available. It provides the full functionality of paid memberships with github.com, at no cost to Purdue researchers.

There are many resources available on the Internet about using GitHub. Most guides and tutorials for github.com will apply to our instance of GitHub. Some links to external documentation are provided below, as well as several pages within our site describing GitHub.

Tutorials provided by GitHub covering the basics of using Git and GitHub.

Getting Started

The GitHub instance is offered at no cost to Purdue research groups, current students and faculty, or any Purdue person performing academic not-for-profit research. To get started with GitHub head to the github.itap.purdue.edu to access the system.

Access to this service is only available from campus networks. You will need to use Purdue's VPN to access this service from off campus.

Managing Users

All users of your GitHub repositories will need to have a Purdue Career Account. Any non-Purdue collaborators will need to have a Request for Privileges (R4P) filed by your business office to create a Purdue Career Account for them before they can be given access to any repositories on the Purdue GitHub. If your project is largely a shared, multi-institution project, you should strongly consider use of github.com instead of Purdue's private GitHub.

Creating repositories

You may create repositories to share within your organization, or create personal repositories. Head to the GitHub instance and click the New Repository button. Choose your organization or your username and give it a name. Select either Public or Private access for your repository. Public repositories are visible to anyone on the internet. Private repositories are only visible to those you choose. In either, only those you choose are able to modify the repository. Commit privileges and private repository viewing access requires a Purdue Career Account.

Organization and Teams

Essentially, an organization is a place to house your research group's work. Multiple repositories may be created inside the organization. You may create teams, or lists of users, for each project. You can then assign the team to a repository, and give the team appropriate permissions to the repository. Organizations and teams are further described by GitHub.

Link to section 'Creating an Organization' of 'Organization and Teams' Creating an Organization

To create an organization start by going to your user settings by clicking your profile picture in the top right of the UI and selecting "Settings"

Next, click the 'Organizations' tab in the user settings sidebar.

Then, click 'New Organization' in the top right.

Follow the wizard to finish creating an organization.

Link to section 'Managing Organizations and Teams' of 'Organization and Teams' Managing Organizations and Teams

To add members to a team, begin by switching your dashboard context to the organization. This can be done by clicking your username in the left sidebar and switching the context to that of your organization.

Next, click "View organization" in the sidebar to be brought to the organization home page.

From here, click the "People" tab

Using the 'Add member' button, new users can be added to your organization. Due to the way our authentication mechanism is tied to Purdue Career accounts, the user must have logged in to the Github instance at least once to be invited to an organization. All currently existing members of the github.rcac.purdue.edu instance have been already added to this instance.

Promoting and Demoting Managers/Owners

GitHub organizations each have one or more managers, or owners. Owners of an organization have more permissions within that organization than regular members. Compare permission levels to determine which is best for all members of your research group.

Any existing member of an organization can be promoted to Owner status by an existing Owner. Users will need to be a member of the organization before they can be promoted.

To promote an existing Organization member:

  • Navigate to github.itap.purdue.edu
  • From the dropdown (typically defaults to your username), select your Organization
  • Click the "View Organization" button in the upper right
  • Alternatively, navigate directly to github.itap.purdue.edu/yourorganization
  • Select the People tab (next to Repositories)
  • Find the member to be promoted, and select Owner from the dropdown now labeled "Member"

To demote an existing Organization owner:

  • Repeat steps above, except change Owner dropdown to Member

Using Git

GitHub provides an excellent guide on the basics of using Git and Github. Guides are also available on other topics. All of these guides are applicable to our instance, except you will use https://github.itap.purdue.edu as the URL instead of https://github.com.

ITaP Research Computing Github vs github.com

The GitHub Enterprise instance is a licensed product offering from GitHub itself. It is an instance of the GitHub product on github.com, and is completely independent. The system is controlled and hosted by ITaP and uses Purdue Career Accounts for access control. It provides the full functionality of paid memberships with github.com, at no cost to Purdue researchers.

Citing code in academic literature

Projects within GitHub can be tagged with a Digital Object Identifier (DOI) to make your code citable in academic literature.

Using SVN

Native Subversion repositories are no longer offered. However, if you are more comfortable using SVN commands, or have code that requires it, GitHub repositories may be interacted with using Subversion commands.

Regular maintenance

Regular maintenance on ITaP Research Computing GitHub is scheduled for the first Wednesday of every month, 3:00pm to 5:00pm. Operations requiring connection to the central server (e.g. new check-outs or pull requests, etc) may time out during the maintenance period. Operations with your own local repository will not be affected.

Moving Repositories

Follow the steps below to move a full Git repository, with history, from one remote server to another. You can move an entire repository or allow choose which branches and tags to include.

For the sake of this tutorial, the original repository will be https://github.rcac.purdue.edu/foo/bar and it will be moving to https://github.itap.purdue.edu/foo/bar.

1) Create an empty repo on the new Git server:

You need to have an empty target repository to push your cloned repository to. Do not add any of the suggested README or LICENSE auto-generated files as they will not be needed.

Link to section 'Entire Repository' of 'Moving Repositories' Entire Repository

If you want to copy the entire repository you can use the following steps instead.

2) Create a local repository. In this example, we're cloning into a directory called temp-dir:

git clone --mirror https://github.rcac.purdue.edu/foo/bar temp-dir

Note: git clone –mirror implies –bare and does not generate a working copy.

3) Go into the temp-dir directory.

cd temp-dir

4) Link your local repository to the newly created repository using the following command:

git remote set-url origin https://github.itap.purdue.edu/foo/bar

5) Push all branches and tags:

git push --mirror https://github.itap.purdue.edu/foo/bar

A Note on Pull Refs

When migrating a repo, you may errors like the following:

! [remote rejected] refs/pull/100/head -> refs/pull/100/head (deny updating a hidden ref)
! [remote rejected] refs/pull/101/head -> refs/pull/101/head (deny updating a hidden ref)

You will see this refs/pull errors if your repository has ever had a Pull Request. refs/pull is a private, read-only ref created by GitHub, in part, to allow for linking back to a Pull Request and its discussion thread, etc. These references cannot be mirrored but they do not prevent mirroring the rest of the repo and its history. These errors can be safely ignored.

Link to section 'Selective Branches' of 'Moving Repositories' Selective Branches

2) Create a local repository. In this example, we're cloning into a directory called temp-dir:

git clone https://github.rcac.purdue.edu/foo/bar temp-dir

3) Go into the temp-dir directory.

cd temp-dir

4) To see available branches of https://github.rcac.purdue.edu/foo/bar:

git branch -a

5) Checkout all the branches that you want to copy:

git checkout branch-name

6) Fetch all the tags from https://github.rcac.purdue.edu/foo/bar:

git fetch --tags

7) Check that your local branches and tags look correct:

git tag
git branch -a

8) Link your local repository to the newly created repository using the following command:

git remote set-url origin https://github.itap.purdue.edu/foo/bar

9) Push all branches and tags:

git push origin --all
git push --tags

There should now be a full copy of the repository at https://github.itap.purdue.edu/foo/bar.

It's a good idea to archive the old repository at https://github.rcac.purdue.edu/foo/bar to avoid having other users making commits to the old repository. See below for more information on how to archive a repository on GitHub.

Link to section 'Moving GitHub Wikis' of 'Moving Repositories' Moving GitHub Wikis

You can also migrate GitHub wikis using the above procedure because wikis are simply Git repositories that follow the special naming convention [repo-name].wiki.git. As with repositories, an empty wiki at the destination (e.g., https://github.itap.purdue.edu/[owner]/[repo-name]/wiki) must first be created before you try pushing to it.

Link to section 'Archiving GitHub repositories' of 'Moving Repositories' Archiving GitHub repositories

Archiving a repository lets users know that the repository is no longer used. When archiving a repository, all of its issues, pull requests, code, labels, milestones, projects, wiki, releases, commits, tags, branches, reactions, and comments become read-only. To make any changes to an archived repository it must be unarchived first.

To archive a repository, navigate to the main page of the repository and click the Settings tab for the repository. Scroll down and find the Danger Zone where you should click the Archive this repository button. Read the warnings and type the name of the repository foo/bar in the confirmation box and click the button to archive the repository.

To unarchive a repository, follow the same instructions as archiving the repository, all the buttons will be replaced with ones to unarchive the repository.

For more information about archiving repositories you can visit GitHub's documentation and click the button to archive the repository.

Helpful?

Thanks for letting us know.

Please don’t include any personal information in your comment. Maximum character limit is 250.
Characters left: 250
Thanks for your feedback.