Basic Github usage - anjavdl/PHY517_AST443 GitHub Wiki

Getting Started

A good way to familiarize yourself with github is to work through the no-coding-necessary "Hello, world" tutorial:
https://guides.github.com/activities/hello-world/

To use git's many functionalities from the command line, you'll want to add an SSH key to your account:
https://help.github.com/articles/generating-an-ssh-key/

Checking out a repository

On the page of the repository you would like to check out, click on the green "Clone or download" button, select "Use SSH", and copy the shown line to your clipboard, e.g.

[email protected]:anjavdl/git_test.git

You can now "clone" the repository from your command line:

git clone [email protected]:anjavdl/git_test.git [local name]

where the third argument needs to be replaced by the line you copied from the repository. The fourth argument is optional; you can specify how you would like to name the repository on your computer. The default is to use the name of the directory, in this case git_test.

If you have already cloned a repository, and you would like to update your local copy to the most recent version, simply to

git pull

It should always do this before you start making changes - otherwise you will have to resolve conflicts.

Committing changes to your local copy

You can now edit the files on your local copy of the repository. Adding new files is done via

git add <filename>

Git really works with two repositories: one of them is your local copy, and the other one lives on the git servers. To commit your edits to the local repository, use ``git commit'':

git commit -m "Useful description of the changes you made" [filename]

The part behind -m is for the comment that accompanies your commit. If no -m argument is given, git will launch your favorite text editor to prompt you for a description. Good descriptions of your edits are an important part of good coding practices!
Note that you can specify to commit only individual files through the last argument. By default, all files that have been modified (and that are version-controlled through git) will be committed.

Committing changes to the repository without review

Pushing your changes to the repository that is hosted on the github servers is done via

git push [filename]

Note that you need to have committed your changes to your local repository first!

This is fine if your project is not a team effort, and if changes are small. For team code development, you should make changes through "pull requests" to allow code review.

Branches and Pull Requests

One of git's most useful features are "pull requests". Imagine that you have added a new feature to somebody's coding project, and you think it is now ready to become part of the main code - this is when you "request" that they "pull" the code from your repository into the main project. Pull requests give you the opportunity to have somebody review the code before merging, and to discuss the changes.

To allow for parallel coding development, work can happen on several branches of the repository. The official version lives on the master branch. Pull requests can be made from other branches back to the master branch. By default, the clone of a repository (which you created above), points to the master branch - which ensures that git pull always retrieves the most up-to-date version of the code. To move the changes you made to a new branch, do

git checkout -b newbranch

(You can replace "newbranch" with a more descriptive name.) To push your changes to the new branch, do

git push origin newbranch

You might have to issue some git add and git commit commands, too.

When you now go the webpage of the repository, you should see a message that you recently pushed a new branch, along with a green button "Compare and pull request". Clicking this button will show you a comparison of the code that changed between the two branches, and give you the option to issue a pull request, along with the possibility to give a description. This description works similar to an issue: you and the other contributors can discuss features (and problems) of the new code. Once the issues have been resolved, the repository owner can accept the pull request.

⚠️ **GitHub.com Fallback** ⚠️