Difference between revisions of "GitLab server"

From mi-linux
Jump to navigationJump to search
 
(19 intermediate revisions by one other user not shown)
Line 1: Line 1:
* [[Getting started with GitLab]]
+
[[Main Page]] >> GitLab server
* [[Cloning and pulling from GitLab]]
 
* [[Solving conflicts on GitLab]]
 
* [[Working environments]]
 
  
 +
== GitLab server ==
  
== Importing from repository ==
+
The University provides every student with a Git Version Control system called GitLab:
  
So far we have explained how to commit (i.e. push) changes from your local repository to the central repository. But what about the other way around? There are 2 git commands for this:
+
* [https://git-srv.wlv.ac.uk/gitlab https://git-srv.wlv.ac.uk/gitlab]
  
* [http://git-scm.com/docs/git-pull git-pull]: Pulls a copy of a project from a Git repository server to the local file system and synchronize between the two. Note that in order to pull (or push) a project, you must have either created the project (e.g., using the git init command), or cloned the project (e.g., using the git clone command, see below).
+
Please read through the following tutorials:
* [http://git-scm.com/docs/git-clone git-clone]: Creates a copy of a project on your local file system. You can use this command to "import" a project from Gitlab that was not originally created by you (e.g., by your teammates.)
+
# [[Getting started with GitLab]]
 +
# [[Cloning and pulling from GitLab]]
 +
# [[Solving conflicts on GitLab]]
 +
# [[Working environments]]
 +
# [[Working with GitLab Issues, Milestones and Labels]]
  
=== Cloning ===
+
'''Important''': Please note that you should only use this server to store files related to University coursework. Personal or work-related files should not be stored on this server.
  
If other team members wishes to work on the repository you created earlier then they will need to "clone" it first:
+
== Further reading ==
  
<pre>
+
This tutorial only acts as an introduction, please refer to the following resources for more information and further reading:
git clone https://fsegitlab.wlv.ac.uk/in9352/great-work-by-alix.git
+
* [http://git-scm.com/doc Git documentation]
</pre>
+
* [http://doc.gitlab.com/ce/ GitLab documentation]
 
 
The command above:
 
* creates a new folder
 
* creates the local repository
 
* imports all the files from the server to the local repository
 
 
 
You are essentially creating a duplicate working copy of the project locally.
 
 
 
You might make a change to an existing file, or even add new files:
 
 
 
<pre>
 
gedit index.html // make a change to the file and save
 
 
 
touch page2.html
 
git add page2.htm
 
 
 
git commit -m "Commit by team member"
 
git push -u origin master
 
</pre>
 
 
 
The commands above allow you to:
 
* make a change to the existing "index.html" file
 
* create a new "page2.html" file (empty for now) and add it to the local repository
 
* commit all changes to the local repository
 
* push all changes back to the server
 
 
 
=== Pulling ===
 
 
 
If  you already have a local copy of a repository (you either created it in the first place, or cloned it earlier), and only need to "pull" the latest changes from your team, then you'll need the "git pull" command:
 
 
 
<pre>
 
git pull origin
 
</pre>
 
 
 
'''Note''': we are reusing the alias we created earlier ("origin"), which is a shortcut for our repository's URL.
 
 
 
The command above will import all new files, as well as existing files that have been updated, into your local repository.
 
 
 
=== Working as a team ===
 
 
 
Once all developers have a local copy of your repository, it's a case of simple pulling and pushing changes to and from the central repository.
 
 
 
== Solving conflicts ==
 
 
 
But what happens if 2 developers push a change to the same file? Well, let's take a look.
 
 
 
Let's imagine that our previously created file "page2.html" contains the following, very simple HTML code:
 
 
 
<pre>
 
<!DOCTYPE html>
 
<html>
 
  <head>
 
    <meta charset="UTF-8">
 
    <title>My second page</title>
 
  </head>
 
  <body>
 
    <h1>This is our second page</h1>
 
  </body>
 
</html>
 
</pre>
 
 
 
=== Two developers make a change ===
 
 
 
Let's imagine that 2 developers "pull" the latest code above, and then both make a slightly different change, as follow (see added paragraph):
 
 
 
Developer 1:
 
<pre>
 
<!DOCTYPE html>
 
<html>
 
  <head>
 
    <meta charset="UTF-8">
 
    <title>My second page</title>
 
  </head>
 
  <body>
 
    <h1>This is our second page</h1>
 
    <p>Some text about something</p>
 
  </body>
 
</html>
 
</pre>
 
 
 
Developer 2:
 
<pre>
 
<!DOCTYPE html>
 
<html>
 
  <head>
 
    <meta charset="UTF-8">
 
    <title>My second page</title>
 
  </head>
 
  <body>
 
    <h1>This is our second page</h1>
 
    <p>Some other text about something else!</p>
 
  </body>
 
</html>
 
</pre>
 
 
 
=== Two developers push their changes ===
 
 
 
Developer 1 commits his change successfully:
 
<pre>
 
git add page2.html
 
git commit -m "commit by team member 1"
 
git push -u origin master
 
</pre>
 
 
 
Message displayed:
 
<pre>
 
1 file changed, 1 insertion(+)
 
</pre>
 
 
 
Then developer 2 tries to commit too:
 
<pre>
 
git add page2.html
 
git commit -m "commit by team member 2"
 
git push -u origin master
 
</pre>
 
 
 
But he gets an error message:
 
<pre>
 
error: failed to push some refs to 'https://fsegitlab.wlv.ac.uk/in9352/great-work-by-alix.git'
 
To prevent you from losing history, non-fast-forward updates were rejected
 
Merge the remote changes (e.g. 'git pull') before pushing again.
 
</pre>
 
 
 
The Git server tells developer 2 to "pull" the latest code again (which will include the change made by developer 1). Let's do that.
 
 
 
=== Resolving the conflict ===
 
 
 
Let's pull the code again:
 
 
 
<pre>
 
git pull origin
 
</pre>
 
 
 
This time a warning message tells us:
 
 
 
<pre>
 
CONFLICT (content): Merge conflict in page2.html
 
Automatic merge failed; fix conflicts and then commit the result.
 
</pre>
 
 
 
Indeed when reopening his local copy of "page2.html", developer 2 is presented with the following:
 
 
 
<pre>
 
<!DOCTYPE html>
 
<html>
 
  <head>
 
    <meta charset="UTF-8">
 
    <title>My second page</title>
 
  </head>
 
  <body>
 
    <h1>This is our second page</h1>
 
<<<<<<< HEAD
 
    <p>Some other text about something else!</p>
 
=======
 
    <p>Some text about something</p>
 
>>>>>>> 8c409afad98a4a8af4ac0f17a3be594802bc5895
 
  </body>
 
</html>
 
</pre>
 
 
 
As you can see both changes (i.e. both paragraphs) are included, and highlighted by Git. It is up to developer 2 to decide which one to keep and push back to the server. Here a conversation between the 2 developers should take place, and a decision made (for example, merging the wording of the 2 paragraphs!), before the change can be pushed.
 
 
 
== Working environments ==
 
 
 
There are several ways to interact with Git and GitHub.
 
 
 
=== Command line ===
 
 
 
Everything covered on this page works just fine from the command line. Again here is a reminder of the various ways you can run Git commands:
 
* ''[Windows]'' Run "Git Bash", a Git client installed in all MI labs
 
* ''[Windows]'' SSH into mi-linux.wlv.ac.uk using an SSH client such as Putty
 
* ''[Linux]'' Boot under Linux, and open a Shell window.
 
 
 
=== GitLab web interface ===
 
 
 
Once a repository is created and pushed by 1 user (from the commands line), any further work can take place from GitLab's web interface ("Files" tab). Users can :
 
* Edit exiting files and commit changes
 
* Add new files
 
 
 
The web-based text editor is rather simplistic compared to dedicated editors and IDEs, but is sufficient in a lot of cases.
 
 
 
=== Using GitLab from Eclipse ===
 
 
 
Many of you are used to working with the Eclipse IDE. This can be used with our GitLab server obviously, via the "Team" menu.
 
 
 
====Clone Git Repository====
 
 
 
First, let's see how we can clone an existing repository through Eclipse:
 
 
 
* Copy your Git Project HTTPS URL (see earlier)
 
* In Eclipse, make sure that you have the "Git Repositories" view available
 
**Go to Window --> Show View --> Other
 
**Click on Git --> Git Repositories
 
*Now in the Git window, click on "Clone a Git repository". Your copied Git repository will auto-fill
 
*Type your username and password. Choose "Store in Secure Store". Click Next, and then Next again
 
*Click Finish, and wait a few seconds for Eclipse to bring-in the Gitlab project. Your project will show under "Git Repositories" section.
 
 
 
https://mi-linux.wlv.ac.uk/wiki-images/gitlab07.png
 
 
 
====Import project====
 
Your project should now be showing under the "Git Repositories" section, but you still need to manually import it to your list of projects. To do so:
 
* In the "Git Repositories" section, right click on your repository
 
* Choose "Imports Projects" from the menu
 
* On the next window, select "Import as general project" and press "Next"
 
* On the next window, specify a project name (or accept the default one) and press "Finish".
 
 
 
https://mi-linux.wlv.ac.uk/wiki-images/gitlab09.png
 
 
 
Your project should now be showing in your usual "Package Explorer" window, alongside your other projects.
 
 
 
==== Pulling and pushing ====
 
 
 
You will find the usual git commands (pull, push etc.) under the "Team" menu, when right clicking on your project or on your files. Happy Giting!
 
 
 
https://mi-linux.wlv.ac.uk/wiki-images/gitlab12.png
 
 
 
=== Git from home ===
 
 
 
There are plenty of Git clients freely available for all major OS, see a list here:
 
* [http://git-scm.com/download/gui/linux http://git-scm.com/download/gui/linux]
 
 
 
== Working via SSH ==
 
 
 
An SSH key allows you to establish a secure connection between your computer and GitLab.
 
 
 
To generate a new SSH key, just open your terminal and use code below. The ssh-keygen command prompts you for a location and filename to store the key pair and for a password. When prompted for the location and filename, you can press enter to use the default.
 
 
 
It is a best practice to use a password for an SSH key, but it is not required and you can skip creating a password by pressing enter. Note that the password you choose here can't be altered or retrieved.
 
 
 
<pre>
 
ssh-keygen -t rsa -C "$your_email"
 
</pre>
 
 
 
Here is an extract of me running the command:
 
<pre>
 
in9352@csl-student:~$ ssh-keygen -t rsa -C "$alix.bergeret@wlv.ac.uk"
 
Generating public/private rsa key pair.
 
Enter file in which to save the key (/home/staff/acad/in9352/.ssh/id_rsa):
 
Created directory '/home/staff/acad/in9352/.ssh'.
 
Enter passphrase (empty for no passphrase):
 
Enter same passphrase again:
 
Your identification has been saved in /home/staff/acad/in9352/.ssh/id_rsa.
 
Your public key has been saved in /home/staff/acad/in9352/.ssh/id_rsa.pub.
 
The key fingerprint is:
 
04:26:cc:e8:16:2d:2a:a3:a9:91:fa:c5:39:9e:42:81 .bergeret@wlv.ac.uk
 
The key's randomart image is:
 
+--[ RSA 2048]----+
 
|  =. o          |
 
|  + +o .        |
 
| + o    .        |
 
|E +    .        |
 
|o= .    S        |
 
|= .. .          |
 
|oo  =            |
 
|o .o o          |
 
| ...o            |
 
+-----------------+
 
</pre>
 
 
 
Use the code below to show your public key.
 
 
 
<pre>
 
cat ~/.ssh/id_rsa.pub
 
</pre>
 
 
 
This is what this command produces for me:
 
<pre>
 
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQD7qUwO51qi8sQfyl2DXqjqZofFsrSVh5XQEmfSKhfo0a13IrIT9ZPBBom2JiBpaBtb3hqKyyukCr
 
dqjgymJpvw9f3FjW0MFbHFd+F1PhXQMK9knoTwxJvBk+wsIN9toqy9lUFFtu/WjbhNbDWSo1ID9YfjaTmt3S1EX8SqAa8BeO+x8UXM32q3Op9Br6vy
 
CAkZLE/o/SDrookmigjqA/MKtUnuWuvvLWz1AhIEKMNTJ0dEV/ydsYvrPm83lUhyiVcm0fXYVDMJfma5odete5eNMXZKeQ0uEdUFCnu68Q164/4Iss
 
JiFNThQZNt8FuVaKkZv8eLXIBW/nyhCwWkL+LN .bergeret@wlv.ac.uk
 
</pre>
 
 
 
Go back to [https://fsegitlab.wlv.ac.uk GitLab], copy-paste the key to the 'My SSH Keys' section under the 'SSH' tab in your '''user profile'''. Please copy the complete key starting with ssh- and ending with your username and host.
 
 
 
https://mi-linux.wlv.ac.uk/wiki-images/gitlab13.png
 
 
 
You should now be able to push to your SSH repository address. You might get this warning the first time around:
 
 
 
<pre>
 
The authenticity of host 'fsegitlab.wlv.ac.uk (134.220.4.13)' can't be established.
 
Are you sure you want to continue connecting (yes/no)? yes
 
Warning: Permanently added 'fsegitlab.wlv.ac.uk,134.220.4.13' (ECDSA) to the list of known hosts.
 
</pre>
 
 
 
* For more information: [http://doc.gitlab.com/ce/ssh/README.html GitLab documentation on SSH keys]
 

Latest revision as of 14:28, 28 January 2022

Main Page >> GitLab server

GitLab server

The University provides every student with a Git Version Control system called GitLab:

Please read through the following tutorials:

  1. Getting started with GitLab
  2. Cloning and pulling from GitLab
  3. Solving conflicts on GitLab
  4. Working environments
  5. Working with GitLab Issues, Milestones and Labels

Important: Please note that you should only use this server to store files related to University coursework. Personal or work-related files should not be stored on this server.

Further reading

This tutorial only acts as an introduction, please refer to the following resources for more information and further reading: