TDDB84 Design Patterns
Getting started with Git and GitLab
An essential tool for the lab series is Git, a distributed version control system. It is assumed that you are familiar with Git and its terminology. In case you are not, we have collected a number of useful references that will easily get you started:
- Pro Git — A free book available on Git’s official website. Chapters 2.1–2.4 are highly recommended.
- Try Git — Got 15 minutes and want to learn Git? An interactive introduction to Git.
- Git Magic — Rough instructions for particular effects. Available in many languages.
- Git How To — A guided tour that walks through the fundamentals of Git, inspired by the premise that to know a thing is to do it.
- Git Cheatsheet — A handy reference for Git commands.
- Learn Version Control with Git — A step-by-step course for the complete beginner.
In this course, the management of Git repositories is done using a web-based platform called GitLab, which is deployed on one of LiU’s servers. You should be able to access LiU’s GitLab using your LiU ID.
Checking your SSH keys
Please set up SSH keys in accordance with GitHub’s or GitLab’s manual; either one should work with these projects.
- GitHub Manual — Follow steps one and two, and after this you will need to copy the content of your newly generated ida_rsa.pub to a GitLab SSH key.
- GitLab Manual — A video tutorial by the GitLab team.
What are SSH keys?
SSH keys are a way to identify trusted computers without involving passwords. The main advantage, except for not having to supply your password every time, is that your password is actually never sent over the network, and thus it is a bit safer.
Setting up a repository
The first step that you will need to do is to set up a repository. Since all project members have been given a master collaborator role, any one of you could do it. (Who owns the project makes no difference, but there should be an owner.) Note that only one of you needs to make the following steps in order for you to have a shared repository, so discuss within the group who should be responsible for this or do it together; the choice is yours.
You will need a local copy to work on at some point, so we clone this from the original repository:
home$ git clone http://gitlab.ida.liu.se/tddb84/freecol.git Cloning into 'freecol'... Username for 'http://gitlab.ida.liu.se': <YOUR_STUDENT_ID> Password for 'http://<YOUR_STUDENT_ID>@gitlab.ida.liu.se': <YOUR_STUDENT_PASSWORD> remote: Counting objects: 3084, done. remote: Compresseing object: 100% (1765/1765), done. remote: Total 3084 (delta 1249), reused 3084 (delta 1249) Receiving objects: 100% (3084/3084), 44.38 MiB | 392.00 KiB/s, done. Resolving deltas: 100% (1249/1249), done. Checking connectivity... done Checking out files: 100% (2171/2171), done.
Change the current directory to the directory of your new project and have a look at where the remote URL is pointed at:
home$ cd freecol freecol$ git remote -v origin http://gitlab.ida.liu.se/tddb84/freecol.git (fetch) origin http://gitlab.ida.liu.se/tddb84/freecol.git (push)
As you can see, it points to the old repository and not your own. This is not where we want to push our changes to. So, we need to change the location of the remote origin. This is essentially where we make it your repository, by making pushes go to your GitLab repository. Note that the <YOUR_STUDENT_ID> references the owner of the projects student ID. It is necessary for us to use ssh and not http, since the changes we are about to push to the GitLab server are fairly big, and http connections are not as reliable using GitLab, often causing the remote to hang up due to too big packages.
freecol$ git remote set-url origin ssh://firstname.lastname@example.org/<YOUR_STUDENT_ID>/<YOUR_PROJECT_NAME>.git
Now verify that the remote URL has changed and now points to the new projects URL
freecol$ git remote -v origin ssh://email@example.com/<YOUR_STUDENT_ID>/<YOUR_PROJECT_NAME>.git (fetch) origin ssh://firstname.lastname@example.org/<YOUR_STUDENT_ID>/<YOUR_PROJECT_NAME>.git (push)
Now, you should be able to push the local repository to your groups own repository.
freecol$ git push -u origin master Counting objects: 3084, done. Delta compression using up to 2 threads. Compressing objects: 100% (1765/1765), done. Writing objects: 100% (3084/3084), 44.38 MiB | 11.65 MiB/s, done. Total 3084 (delta 1249), reused 3084 (delta 1249) To ssh://email@example.com:<YOUR_STUDENT_ID>/<YOUR_PROJECT_NAME>.git * [new branch] master -> master Branch master set up to track remote branch master from origin. + Done
When this is done, all participants in the group can clone the project from your shared project location, and contribute in one common area. If you are cloning over HTTP, it might be necessary to change your password at GitLab if you have not done this before, since it seems that this cannot be verified via LiU’s authentication service. It should not be a problem to change your password to the same as you already have, as long as it is changed somehow.
When the above has been done, it is time to create separate places to store your contributions to each part. Therefore, each subgroup should create a branch of its own, named accordingly to the subgroup you are in. Note that this requires that you have already cloned the original repository.
freecol$ git checkout -b model Switched to a new branch 'model'
The above both creates a new branch called model and redirects HEAD to that branch to enable your subgroups to work separately.
Committing will work just the same as usual.
Now, when you are persisting your local changes to GitLab it is necessary to specify which branch you are pushing to at origin (at the GitLab server).
freecol$ git push origin model Counting objects: 5, done. Delta compression using up to 2 threads. Compressing objects: 100% (3/3), done. Writing objects: 100% (3/3), 330 bytes | 0 bytes/s, done. Total 3 (delta 2), reused 0 (delta 0) To ssh://firstname.lastname@example.org:<YOUR_STUDENT_ID>/<YOUR_PROJECT_NAME>.git * [new branch] model -> model
For a more extensive introduction to branching and Git, please see
git-scm.com if you would like to dive deeper into how Git works and how to
work with it.
Page responsible: Ola Leifler
Last updated: 2016-09-07