|
|
# 1 First steps
|
|
|
Go to the [GitLab Main Page](https://git.webis.de/) and log in with your university account if you haven't done so already. This is the same username and password that you have been using for our CVS. On your first login, your GitLab account will be created automatically.
|
|
|
Go to the [GitLab Main Page](https://git.webis.de/) and log in.
|
|
|
|
|
|
You may not be able to see any projects yet, because you need to be granted access by one of our staff; if you registered your account some time ago and still can't access any projects, please notify the `webisstud` mailing list.
|
|
|
|
... | ... | @@ -7,14 +7,8 @@ You may not be able to see any projects yet, because you need to be granted acce |
|
|
# 2 Exploring GitLab
|
|
|
Once you have access, you will see our projects in the [Explore Projects Tab](https://git.webis.de/explore/projects/)
|
|
|
|
|
|
The projects are organized in mostly the same way that they were in CVS. Top-level folders under `code-in-progress` are now called *groups* in GitLab. For instance `webisstud` is now a group with the URL https://git.webis.de/webisstud.
|
|
|
|
|
|
You can see a list of all groups in the [Explore Groups Tab](https://git.webis.de/explore/groups)
|
|
|
|
|
|
Each former CVS module on the second level of the hierarchy is now a *project* in GitLab, and has its own Git repository. For example, the project `code-in-progress/webisstud/wstud-clickbait-ws16` is now a project `wstud-clickbait-ws16` in the group `webisstud` with the URL https://git.webis.de/webisstud/wstud-clickbait-ws16
|
|
|
|
|
|
Students will by default get read access to all groups and full write access to `webisstud` and `thirdparty`. Projects within these groups will also be listed under [My Projects](https://git.webis.de/dashboard/projects). If you need write access to other groups or repositories, please ask our staff.
|
|
|
|
|
|
|
|
|
# 3 Authentication, Cloning and Updating Projects
|
|
|
Each project page displays a clone URL under the project name. Two methods are supported: SSH and HTTPS, which have different clone URLs. The HTTPS method only uses your username and password. The SSH method is more convenient, but requires some up-front setup. You need to generate an SSH key pair, and make the public key known to GitLab. If you don't have an SSH-key pair, you can generate one by running
|
... | ... | @@ -27,8 +21,6 @@ and following the instructions. Although not required, it is recommended to set |
|
|
|
|
|
Once your SSH key has been generated, copy the contents of `~/.ssh/id_rsa.pub` (or whatever file you chose to store your public key in) into the *Key* field in your [SSH Key Settings](https://git.webis.de/profile/keys) and click *Add Key*. This will add the public key to your GitLab account, so you can use you the corresponding private key to pull from and push to GitLab via SSH. Make sure to keep the private key part in `~/.ssh/id_rsa` secret at all times! If your private key gets compromised, delete the public key from GItLab and create a new key pair to prevent others from gaining unauthorized access to our Git repositories.
|
|
|
|
|
|
If you are using the `webis` command (see next section), then `webis git init` will automatically create an SSH key pair for you if you don't have one.
|
|
|
|
|
|
Once you have an authentication method set up, you can paste the clone URL behind `git clone` into your terminal. For example, to clone the clickbait project using the HTTPS method, you would use:
|
|
|
|
|
|
```
|
... | ... | @@ -41,17 +33,12 @@ With SSH this would be: (note the different domain name) |
|
|
git clone git@webis.uni-weimar.de:webisstud/wstud-clickbait-ws16.git
|
|
|
```
|
|
|
|
|
|
Both URLs can be looked up and copied from the project page in GitLab.
|
|
|
|
|
|
To update an already cloned working copy with the latest changes from GitLab, use `git pull` to pull in the latest remote revision. `git pull` is a shortcut for `git fetch`, which retrieves the changes from the server, and `git merge`, which merges the fetched changes into your local working copy.
|
|
|
|
|
|
## 3.1 Pushing Changes, Note to CVS Users
|
|
|
## 3.1 Pushing Changes
|
|
|
Please be aware that, unlike CVS or SVN, Git is a *distributed* version control system. That means that a `git commit` only commits into your local working copy. To push the changes back to our central GitLab instance, you have to use `git push` after committing your changes. It is strongly recommended to commit often and in small atomic units with meaningful commit messages. That way you document your work progress and create a comprehensible history. Once your work is finished or at the end of a work day, you can bulk-push all your commits back to the server with a single `git push` (of course you can push more often if you like).
|
|
|
|
|
|
## 3.2 Branching
|
|
|
Other than CVS, Git makes branching easy and cheap. It is therefore quite convenient to work with different branches once you have made yourself familiar with Git. Therefore, if you are feeling comfortable enough with Git already and are working on a larger new feature, you can create and switch to a new branch with `git checkout -b branchname`. When your work is finished, you can merge the changes back into the main branch with `git merge`. If the main branch has diverged in the meantime, you can incorporate the changes using `git rebase` before merging your feature branch back in. More information about [branching and merging](https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging) and [rebasing](https://git-scm.com/book/en/v2/Git-Branching-Rebasing) can be found in the free online Git book.
|
|
|
|
|
|
## 3.3 Further Resources for Learning Git
|
|
|
## 3.2 Further Resources for Learning Git
|
|
|
If you need further instructions on working with Git from the command line, you can find many good tutorials online, such as the following:
|
|
|
|
|
|
* [Git Book](https://git-scm.com/book/en/v2)
|
... | ... | @@ -60,44 +47,7 @@ If you need further instructions on working with Git from the command line, you |
|
|
* [Git Tutorial](https://try.github.io/levels/1/challenges/1)
|
|
|
|
|
|
|
|
|
# 4 Working with the `webis` Command Line Tool
|
|
|
We provide a convenience command line tool called `webis` to help you work with Gitlab. This is installed on all of our lab machines and kept up-to-date by our staff. To install the `webis` command on your own machine, see the [Installation Instructions](webis-cmd-installation).
|
|
|
|
|
|
If this tool is already installed on your lab machine, run `webis git init` and follow the instructions to configure it. Following that, there are several ways to clone multiple projects from GitLab:
|
|
|
|
|
|
* clone all projects that you have currently checked out from CVS:
|
|
|
1. go (`cd`) to `code-in-progress` in your CVS workspace directory
|
|
|
2. run `webis git cvstree2git`
|
|
|
* clone all projects from one or more GitLab groups:
|
|
|
1. create a directory for your git workspace and switch to it
|
|
|
2. run `webis git clone-groups` and select the project group(s) you want
|
|
|
3. after pressing return, all selected project groups will be cloned
|
|
|
|
|
|
You can then import all of the cloned projects into your IDE at once.
|
|
|
|
|
|
`webis git clone-groups` can also be used for keeping your cloned working copies up to date.
|
|
|
|
|
|
|
|
|
# 5 Working with Eclipse
|
|
|
To avoid confusion with existing CVS projects, start with a new Eclipse workspace, or remove existing `code-in-progress` projects before you begin.
|
|
|
|
|
|
|
|
|
## 5.1 Cloning Projects
|
|
|
You can clone individual projects directly from Eclipse using the following method:
|
|
|
|
|
|
1. from any GitLab project page, copy the clone URL under the project name (next to 'SSH' or 'HTTPS')
|
|
|
2. In Eclipse, go to the *Git Repositories* view (*Window* -> *Show View*)
|
|
|
3. right click the *Git Repositories* view, and select *paste repository path or URI*
|
|
|
4. in the following dialog, select the appropriate protocol and click *Next*
|
|
|
5. select the `master` branch, then *Next*, then the destination directory on your local machine, and click *Finish*
|
|
|
|
|
|
## 5.2 Interacting with Git from Eclipse
|
|
|
Right click on any project in your workspace, select *Team*, and then *Pull* to download updates from GitLab into your local repository. The *Team* menu also provides options for committing your changes to your local repository and pushing your commits to GitLab.
|
|
|
|
|
|
The *Git Repositories* view allows you to update all of your local repositories at once: click the view area, press `Ctrl-A`, then right-click and select *Pull*.
|
|
|
|
|
|
|
|
|
# 6 Working with IntelliJ IDEA
|
|
|
# 4 Working with IntelliJ IDEA
|
|
|
If you use IntelliJ IDEA, there is a slightly more convenient process with the *Gitlab Projects* plugin. Go to *Configure* -> *Plugins* -> *Browse Repositories* and install the plugin. Afterwards, there is a new option *GitLab* under *Check out from Version Control*.
|
|
|
|
|
|
From there, go to *Settings* to configure the plugin, enter https://git.webis.de/ as URL.
|
... | ... | |