GitHub at UiO

2.1   SSH-keys

GitHub uses SSH keys to authenticate users who want to connect to the Git service.

1. If you do not already have an RSA key, create a new one:

   ssh-keygen -t rsa -b 4096
   

You will be prompted to choose where to save the id_rsa file and also for a passphrase. At UiO, all SSH keys must be protected with a passphrase, so choosing an empty passphrase is not allowed.

2. Once you have this key ready, you can upload the .pub file that was created, or that you already have associated with your SSH key. To do this, log in to github.uio.no and click on the profile picture icon in the top right corner. This will bring up a menu where you can choose "Settings". Once you have navigated to "Settings", there is a link called "SSH keys". Click on "Add SSH key" and you will see a form where you can paste the content from your pub file. It is very important to paste from the file named id_rsa.pub and not from id_rsa, as the latter is your private key that you should not share with anyone else.

2.2   Creating a new repository

You can create a new repository by either clicking on the plus icon in the top right corner and selecting "create new repository" or by going to https://github.uio.no/new. Here, you can choose whether it should be a public repository, accessible to all UiO users who are logged in, or a private repository that only you have access to.

2.3   Creating an organization

If you are collaborating on multiple projects with a group of people, it can be useful to use an organization to easily organize multiple repositories. By clicking on the plus icon in the top right corner, you can choose "Create new organization" and be taken to the form for creating it.

Rights management within the organization can be done at a granular level, allowing for both public and private repositories that are accessible to all UiO users, as well as a defined list of users.

A concrete example of how to use this is by using it in a classroom setting. There may be a repository that is only accessible to teaching assistants and one that is only accessible to students.

2.4   Further documentation

GitHub's development team has documented their GitHub Enterprise application quite well, so if you have any questions, you can find most of it explained in the application itself and by searching the documentation pages found here: https://docs.github.com/en/free-pro-team@latest/github/creating-cloning-and-archiving-repositories https://docs.github.com/en/free-pro-team@latest/github/using-git

4.1   Adding a file locally

To add a file:

git add <filname>

The file must already exist.

See also git-add(1).

4.2   Committing changes locally

To commit changes:

git add [files...]
git commit [files...]

If you don't want to control which files it applies to, you don't need to specify files. Git will search through the entire directory to determine what has changed. An editor will appear where you should write the commit message. Alternatively, you can specify it on the command line:

git commit -m '<message>' [files...]

You can also choose to perform the "add" in the same process, i.e., you don't need to do a separate "git add", but only if the file already exists in Git:

git commit -a [files...]

Things can be combined:

git commit -a -m '<message>' [files...]

See also git-commit(1).

Pushing changes to the central repository

"git commit" will only commit changes locally, in your local repository. To get it into the Git server, you need to use push:

git push

See also git-push(1).

4.3   Fetching changes from the central repository

You can update your local repository from the central one using pull:

git pull

See also git-pull(1).

6.1   Merging

If you are satisfied with the changes made in a branch, you can merge it into another branch, for example, from a test branch to a production branch. In the example, we merge the content of test into main:

1. Make sure the active branch is the one you want to merge into:

   $ git checkout main
   Switched to branch 'main'
   

2. Run git merge:

   $ git merge test
   Updating bdebdfc..10c644c
   Fast-forward
    myfile.txt |    1 +
    1 files changed, 1 insertions(+), 0 deletions(-)
   

   If you encounter a conflict, it will look like this:

   Auto-merging myfile.txt
   CONFLICT (content): Merge conflict in myfile.txt
   Automatic merge failed; fix conflicts and then commit the result.
   

   Any conflicts must be resolved before the merge can be completed.

3. Finally, commit the changes:

   $ git commit -a -m 'message'
   [el6 5ad8e86] message
   

For more information, see git-merge(1).

6.2   Deleting a branch

This is done as follows:

$ git branch -d test
Deleted branch test (was 8f08040).

This assumes that you have already performed a git merge. If the changes in 'test' are to be discarded without further action, use git branch -D test.

For more information, see git-branch(1).

7.1   Colors in diff and other output

To get colors from git diff and other Git commands, you can set the following in ~/.gitconfig:

[color]
        ui = auto

This can also be set using git config:

git config --global color.ui auto

7.2   Aliases for Git commands

Aliases for Git commands can be set in the following way:

[alias]
        <alias> = <command>

Example:

[alias]
        co = checkout

This can also be set with git config (example):

git config --global alias.co checkout

7.3   Using meld as a merging tool

Meld is a GUI program (GNOME) for visualizing and assisting with merging. If you want Git to start Meld automatically in case of merge conflict, you can set it in ~/.gitconfig:

[merge]
        tool = meld

Or with git config: git config:

git config --global merge.tool meld

Remember to also install Meld:

sudo yum -y install meld

7.4   Displaying active branch in prompt

To make bash display the active branch in the prompt, you can set PS1 as follows in ~/.bashrc:

if [ -f /etc/bash_completion.d/git ]; then
    source /etc/bash_completion.d/git
    export GIT_PS1_SHOWDIRTYSTATE=true
    export GIT_PS1_SHOWUNTRACKEDFILES=true
fi
export PS1='[\u@\h \W$(declare -F __git_ps1 &>/dev/null && __git_ps1 " (%s)")]\$ '

This will make the bash prompt look like this:

[user@host directory-name (main)]$

In addition to showing the branch you're working on, it will also show if you're in a merge or rebase:

[user@host directory-name (main*)]$
[user@host directory-name (main+)]$
[user@host directory-name (main%)]$

• On the first line, a file has been modified
• On the second line, a file has been modified and git add has been done but not git commit
• On the third line, a new file has been created that is not in git

These can obviously be combined.

8.1   Why git?

Git is currently (2023) the most popular version control system, at least within free software. Git has several characteristics that are very appealing. Here are the most important ones:

Good support for non-linear development

Git easily supports quickly creating new branches in development (branching) and merging of branches (merging). Git has special tools for visualizing and navigating a non-linear development history. A branch in Git is very lightweight, it is only a reference to a single commit. The entire branch structure can be constructed by looking back at such references.

Distributed development

Like some other similar version control tools (but unlike Subversion and CVS), Git gives each developer a local copy of the entire development history. Changes can be copied from one repository to another. These changes are imported as additional branches and can be merged in the same way as a locally developed branch.

Compatibility with existing systems and protocols

Repositories can be published via well-known protocols such as HTTP, FTP, and rsync. In addition, there is a dedicated Git protocol that can be used over a regular socket or via ssh. Git also supports being used alongside Subversion or CVS.

Efficient handling of large projects

Git has a very good reputation for being efficient and fast, even when dealing with large projects with many files and complicated development history. Git does not slow down as the history gets larger.

Cryptographic Authentication of History

The Git history is stored in such a way that the name of a revision (i.e., a commit) depends on the complete history leading up to that particular commit. Once the history is published, it is theoretically impossible to change older versions without it being noticed.