Thursday, 30 of June of 2016


There’s a TuftsUniversity account on GitHub.  Hopefully, it will become broadly used throughout Tufts so we can more easily collaborate and share code.  If you want access to TuftsUniversity repositories, just email Steve.  This article reviews some of the basics of working with git and GitHub.

Often, you have an existing code base and you need to get it into GitHub.  Here’s how to do it from the command line.  “cd” to the top of your source tree on your local drive.  Then, create a local git repository:

> git init

Create a file named .gitignore to specify what files should be ignored and not put under version control (config files with passwords, .dlls, .class/jar files, a tmp directory, etc.)

> emacs .gitignore

Tell git you want the files and directories in your current directory to be under version control

> git add .

To see the list of files that are under version control, use

> git status

If you need to remove any files from version control, use

> git rm –cached filename

and consider updating your .gitignore file

Commit (i.e. check in) your files to your local git repository:

> git commit -m ‘initial commit’

Use a browser to create a new repository on GitHub.  This repository should be empty, without a README file.  In this example, the GitHub repository is named SteveTest.

Connect your local git repository to the GitHub git repository you just created:

git remote add origin

Push your local repository changes up to GitHub

> git push origin master

Your code is now on GitHub, but there’s a problem.  For each project, you must decide what kind of collaborative development model it will follow.  The above example sets the repositories for collaboration using a Shared Repository Model (basically, as if you were using Subversion).  If the project has very few developers or if the project must be private and you don’t want to use many private repositories, the shared repository model works.  Every developer has a local git repository that points to the single GitHub repository that is the project’s master repository.  GitHub also supports the more flexible Fork and Pull Model of collaboration.  In this model, GitHub holds the “master” project repository as well as a fork of it for each developer.  Each developer’s local git repository points to their personal fork on GitHub.  Developers commit their changes to their local repository, push them to their personal fork on GitHub and then generate a pull request from their personal fork to the project’s GitHub master repository.


Other Tips

When pushing to GitHub, you will be prompted for your GitHub username and password (which are not your LDAP credentials).

Before doing a commit you have to let git know which files have changed and been created.  This is done via

> git add .

Or, you can use

> git commit -a

which first does a “git add .” and then does a “git commit”

git config –global core.editor “emacs”

If a password makes it to GitHub read

Git Reference: