Revision as of 12:13, 11 July 2018

Introduction

GitLab is a web interface that make the sharing of programing code easier through git, a versioning control system.
It works mostly like GitHub, which is its' "hosted by private company" equivalent (hence no one really have complete control over their code location and who can or cannot access it).

We, at GIGA, provide our members with a self hosted, secure and rock solid instance of this tool.

Because it is secure, we chose to activate users "on demand" and so, as a first step of this tutorial, those who wish to access it must send a mail to UDIMED-GIGA providing their ULiège username with the demand to be added to GitLab accesses.

Once done, visit http://app.giga.ulg.ac.be/git/ and use your ULiège credentials to log in, which will send you to that screen.

Click to enlarge

Web interface

Create a repository

As you can see here :

Click to enlarge

There are not much to go with as a new member.
Most of the projects being set as "privates", you must request from your PI or any designated IT manager access to your group's repositories.

But, before that, let's take a look at some basics starting with the creation of your own repository.

Click to enlarge

The address is always created the same way.
From http://app.giga.ulg.ac.be/git/ is added, first, the user's (or group's) name and then repository's name.

Under that "repository name" are also the description, which is most of the time skipped, and last but not least : the visibility levels.

Those being :

Private - Project access must be granted explicitly to each user.
Internal - The project can be accessed by any logged in user.
Public - The project can be accessed without any authentication.

For security reasons -again- we ask the users to set most of their work to private, and create (or change their configuration) public ones only when needed.
For, as an example, when they need to share their code at the end of their PhD or post-doc.

Explore a repository

From there, things can be as much simple as they can become more complex.
As a matter of fact, you can see on the next picture that several informations appear right after creating a repository.

Click to enlarge

When a new repo is created, are always written the basic terminal commands (for which we will talk later in this tutorial) as well as links for more complete list of commands and all kind of helps.

Added to that are some of the most important informations/links such as the repository's address, needed to clone your repositories in order to work on them, but also the sidebar menu that will allow you to configure it but also to give access to users and/or groups and set their permission levels.

So first, let's create a new (first) file in this repository with the New file button.

Click to enlarge

Right after the click come a quite lightweight interface.
No tools, just some writing zones to create/modify the file's name and its' content but also a commit which is a bit like a comment related to what you did to one/several files.

Usualy it is of good practice to create a README.md file.
That file is showed by default when someone come to the repository's main page and it uses a gitlab flavored markdown.
See more about it here : https://about.gitlab.com/handbook/product/technical-writing/markdown-guide/

An interesting feature, like showed on the next picture, is the ability to select and interact with several places of the file at the same time by maintaining CTRL key while clicking to the wanted places.
From there all the keyboard interactions (being writing, deleting, moving with the arrows, etc.) will be applied at each of your selections.

Click to enlarge

Finaly, our first commit is in place.
The README.md content is, as said before, showed and its' markdown interpreted.

Click to enlarge

Address of a repository

Click to enlarge

That spot might be one of the most important ones.
Like told before, GIGA has choosen to put emphazis on security.

Because of that, when working on your repositories you will have to be aware of it.
In fact, when inside GIGA (or through the VPN), you'll just fetch from the SSH address which is the safest way but also the stronger and powerful one.
Thank to this, you'll just need one login-like and that's it : feel free to push, pull, remove datas without any more prompts.

Though once out of our computing infrastructure, if you need some more work without any credentials others that the website's login, you'll need to select the HTTP one.
The only thing that it implies is that, at each command you'll execute (mostly pushes and pulls), it will ask you your website's username and passwords.

Sidebar (setup) of a repository

Now, regarding the setups of a repository, it can be a bit overwhelming. Many options are in there but do not worry, most of them won't be of any use to you so you just have to pay attention at a few.

Let's take a look at that left column (which can be collapsed/expanded at ones' wish) and is related to the repository you are looking at.

Repository

This first menu is all about repositories' informations. In a visual way you can see it's content as :

The actual files in it
A commits log, which is (if correctly named/commented when they where done) a way to keep and/or find modifications through time
A branches log, which contains all forks related to your repository and tells if they where merged or not
A tags list, sort of bookmarks for your releases. Eg. TAG v1.0
A chart that allows you to see each members' work on the projects
"Graph", a visual approach of your whole commits regarding your branches and merges
A tool to compare two repositories. Eg. Master ~ Fork_01
Even more statistics/graphs/charts tools (most of the time unused though)

Click to enlarge
Click to enlarge
Click to enlarge
Click to enlarge

Issues

As shown on the pictures right below this text, an other interesting section is the "Issues" system.
It is repository-centric, thus you need to navigate into one for having access to the creation of new issues.

The GitLab Issue Tracker is an advanced and complete tool for tracking the evolution of a new idea or the process of solving a problem
The Issue Board builds on GitLab's existing issue tracking functionality and leverages the power of labels by utilizing them as lists of the scrum board
Labels allow you to categorize issues or merge requests using descriptive titles like bug, feature request, or docs. Each label also has a customizable color. They allow you to quickly and dynamically filter and manage issues or merge requests you care about, and are visible throughout GitLab in most places where issues and merge requests are located.
Milestones in GitLab are a way to track issues and merge requests created to achieve a broader goal in a certain period of time. Milestones allow you to organize issues and merge requests into a cohesive group, with an optional start date and an optional due date

Click to enlarge
Click to enlarge
Click to enlarge
Click to enlarge
Click to enlarge

Merge requests

Merge requests allow you to exchange changes you made to source code and collaborate with other people on the same project.
A Merge Request (MR) is the basis of GitLab as a code collaboration and version control platform. Is it simple as the name implies: a request to merge one branch into another.

With GitLab merge requests, you can:

Compare the changes between two branches
Review and discuss the proposed modifications inline
Live preview the changes when Review Apps is configured for your project
Build, test, and deploy your code in a per-branch basis with built-in GitLab CI/CD
Prevent the merge request from being merged before it's ready with WIP MRs
View the deployment process through Pipeline Graphs
Automatically close the issue(s) that originated the implementation proposed in the merge request
Assign it to any registered user, and change the assignee how many times you need
Assign a milestone and track the development of a broader implementation
Organize your issues and merge requests consistently throughout the project with labels
Add a time estimation and the time spent with that merge request with Time Tracking
Resolve merge conflicts from the UI
Enable fast-forward merge requests
Enable semi-linear history merge requests as another security layer to guarantee the pipeline is passing in the target branch
Create new merge requests by email
Allow collaboration so members of the target project can push directly to the fork
Squash and merge for a cleaner commit history

Click to enlarge
Click to enlarge
Click to enlarge
Click to enlarge

Wiki

A separate system for documentation called Wiki, is built right into each GitLab project. It is enabled by default on all new projects and you can find it under Wiki in your project.
Wikis are very convenient if you don't want to keep your documentation in your repository, but you do want to keep it in the same project where your code resides.
You can create Wiki pages in the web interface or locally using Git since every Wiki is a separate Git repository.

Create a new page by clicking the New page button that can be found in all wiki pages. You will be asked to fill in the page name from which GitLab will create the path to the page. You can specify a full path for the new file and any missing directories will be created automatically.

Once you enter the page name, it's time to fill in its content. GitLab wikis support Markdown, RDoc and AsciiDoc. For Markdown based pages, all the Markdown features are supported and for links there is some wiki specific behavior.

More informations :
https://docs.gitlab.com/ce/user/markdown.html

Click to enlarge
Click to enlarge
Click to enlarge
Click to enlarge

Snippets

With GitLab Snippets you can store and share bits of code and text with other users.

There are 2 types of snippets, personal snippets and project snippets.

Personal snippets are not related to any project and can be created completely independently. There are 3 visibility levels that can be set, public, internal and private
Project snippets are always related to a specific project

There are 2 main ways of how you can discover snippets in GitLab.

For exploring all snippets that are visible to you, you can go to the Snippets dashboard of your GitLab instance via the top navigation. For GitLab.com you can find it here. This navigates you to an overview that shows snippets you created and allows you to explore all snippets.
If you want to discover snippets that belong to a specific project, you can navigate to the Snippets page via the left side navigation on the project page.

Click to enlarge
Click to enlarge

Settings

Click to enlarge

Click to enlarge
Click to enlarge
Click to enlarge
Click to enlarge

Click to enlarge
Click to enlarge
Click to enlarge
Click to enlarge

Terminal interface

Click to enlarge

Advanced use

Handling big files

One of the newest functionnalities is LFS (as in Large File Storage).
Recently Git was used exclusively for sharing code (hence, small files). But nowaday even code is sometimes used with big filesets, or are provided archives, CD/DVD images, etc.

Because of that have been implemented the ability to do so, by defining (on a project-by-project basis) the file extentions to see as "big files".

Installation

MacOS (Using Homebrew)

brew update
brew install git-lfs

Ubuntu

curl -s https://packagecloud.io/install/repositories/github/git-lfs/script.deb.sh | sudo bash
sudo apt install git-lfs

Windows Use the Windows installer here:
https://github.com/git-lfs/git-lfs/releases

Use

Lets take a look at the workflow when you need to check large files into your Git repository with Git LFS. For example, if you want to upload a very large file and check it into your Git repository:

git clone git@app.giga.ulg.ac.be:dummy/my-awesome-project.git
cd my-awesome-project
git lfs install                       # initialize the Git LFS project
git lfs track "*.tgz"                 # select the file extensions that you want to treat as large files

Once a certain file extension is marked for tracking as a LFS object you can use Git as usual without having to redo the command to track a file with the same extension:

cp ~/tmp/mybigdataset.tgz .           # copy a large file into the current directory
git add .                             # add the large file to the project
git commit -am "Added a large file"   # commit the file meta data
git push origin master                # sync the git repo and large file to the GitLab server

And, of course, when wanting to fetch the latest big files from a repository:

git lfs fetch master

More informations :
https://app.giga.ulg.ac.be/git/help/workflow/lfs/manage_large_binaries_with_git_lfs.md

@@ Line 1: / Line 1: @@
 =Introduction=
-[[GitLab|'''GitLab''']] is a web interface that make the sharing of programing code easier through [[git|'''git''']], a versioning control system.<br>
+[[GitLab|'''GitLab''']] is a web interface that make the sharing of programing code easier through [[git|'''git''']], a versioning control system.<br />
-It works mostly like GitHub, which is its' "hosted by private company" equivalent (hence no one really have complete control over their code location and who can or cannot access it).<br>
+It works mostly like GitHub, which is its' "hosted by private company" equivalent (hence no one really have complete control over their code location and who can or cannot access it).
 We, at GIGA, provide our members with a self hosted, secure and rock solid instance of this tool.
@@ Line 9: / Line 9: @@
 Once done, visit http://app.giga.ulg.ac.be/git/ and use your ULiège credentials to log in, which will send you to that screen.
 [[File:gitlab_00.png|thumb|center|320px|Click to enlarge]]
@@ Line 16: / Line 17: @@
 [[File:gitlab_02.png|thumb|center|320px|Click to enlarge]]
-There are not much to go with as a new member.<br>
+There are not much to go with as a new member.<br />
 Most of the projects being set as "privates", you must request from your PI or any designated IT manager access to your group's repositories.
@@ Line 22: / Line 23: @@
 [[File:gitlab_03.png|thumb|center|320px|Click to enlarge]]
-The address is always created the same way.<br>
+The address is always created the same way.<br />
 From http://app.giga.ulg.ac.be/git/ is added, first, the user's (or group's) name and then repository's name.
@@ Line 28: / Line 29: @@
 Those being :
-* '''''Private'''''  - Project access must be granted explicitly to each user.
+* '''''Private''''' - Project access must be granted explicitly to each user.
 * '''''Internal''''' - The project can be accessed by any logged in user.
-* '''''Public'''''   - The project can be accessed without any authentication.
+* '''''Public''''' - The project can be accessed without any authentication.
-For security reasons -again- we ask the users to set most of their work to private, and create (or change their configuration) public ones only when needed.<br>
+For security reasons -again- we ask the users to set most of their work to private, and create (or change their configuration) public ones only when needed.<br />
 For, as an example, when they need to share their code at the end of their PhD or post-doc.
 ==Explore a repository==
-From there, things can be as much simple as they can become more complex.<br>
+From there, things can be as much simple as they can become more complex.<br />
 As a matter of fact, you can see on the next picture that several informations appear right after creating a repository.
 [[File:gitlab_04.png|thumb|center|320px|Click to enlarge]]
@@ Line 48: / Line 51: @@
 [[File:gitlab_05.png|thumb|center|320px|Click to enlarge]]
-Right after the click come a quite lightweight interface.<br>
+Right after the click come a quite lightweight interface.<br />
 No tools, just some writing zones to create/modify the file's name and its' content but also a '''commit''' which is a bit like a comment related to what you did to one/several files.
-Usualy it is of good practice to create a README.md file.<br>
+Usualy it is of good practice to create a README.md file.<br />
-That file is showed by default when someone come to the repository's main page and it uses a gitlab flavored markdown.<br>
+That file is showed by default when someone come to the repository's main page and it uses a gitlab flavored markdown.<br />
 ''See more about it here : https://about.gitlab.com/handbook/product/technical-writing/markdown-guide/''
-An interesting feature, like showed on the next picture, is the ability to select and interact with several places of the file at the same time by maintaining CTRL key while clicking to the wanted places.<br>
+An interesting feature, like showed on the next picture, is the ability to select and interact with several places of the file at the same time by maintaining CTRL key while clicking to the wanted places.<br />
 From there all the keyboard interactions (being writing, deleting, moving with the arrows, etc.) will be applied at each of your selections.
 [[File:gitlab_06.png|thumb|center|320px|Click to enlarge]]
-Finaly, our first commit is in place.<br>
+Finaly, our first commit is in place.<br />
 The README.md content is, as said before, showed and its' markdown interpreted.
 [[File:gitlab_07.png|thumb|center|320px|Click to enlarge]]
@@ Line 69: / Line 73: @@
 [[File:gitlab_08.png|thumb|center|320px|Click to enlarge]]
-That spot might be one of the most important ones.<br>
+That spot might be one of the most important ones.<br />
 Like told before, GIGA has choosen to put emphazis on security.
-Because of that, when working on your repositories you will have to be aware of it.<br>
+Because of that, when working on your repositories you will have to be aware of it.<br />
-In fact, when inside GIGA (or through the VPN), you'll just fetch from the SSH address which is the safest way but also the stronger and powerful one.<br>
+In fact, when inside GIGA (or through the VPN), you'll just fetch from the SSH address which is the safest way but also the stronger and powerful one.<br />
 Thank to this, you'll just need one login-like and that's it : feel free to push, pull, remove datas without any more prompts.
-Though once out of our computing infrastructure, if you need some more work without any credentials others that the website's login, you'll need to select the HTTP one.<br>
+Though once out of our computing infrastructure, if you need some more work without any credentials others that the website's login, you'll need to select the HTTP one.<br />
 The only thing that it implies is that, at each command you'll execute (mostly pushes and pulls), it will ask you your website's username and passwords.
@@ Line 87: / Line 92: @@
 ===Repository===
 This first menu is all about repositories' informations. In a visual way you can see it's content as :
 # The actual files in it
 # A commits log, which is (if correctly named/commented when they where done) a way to keep and/or find modifications through time
@@ Line 102: / Line 108: @@
 File:setup_1_03.png|Click to enlarge
 </gallery>
 ===Issues===
-As shown on the pictures right below this text, an other interesting section is the "Issues" system.<br>
+As shown on the pictures right below this text, an other interesting section is the "Issues" system.<br />
 It is repository-centric, thus you need to navigate into one for having access to the creation of new issues.
@@ Line 120: / Line 127: @@
 File:Issues_05.png|Click to enlarge
 </gallery>
 ===Merge requests===
-Merge requests allow you to exchange changes you made to source code and collaborate with other people on the same project.<br>
+Merge requests allow you to exchange changes you made to source code and collaborate with other people on the same project.<br />
 A Merge Request (MR) is the basis of GitLab as a code collaboration and version control platform. Is it simple as the name implies: a request to merge one branch into another.
 With GitLab merge requests, you can:
 * Compare the changes between two branches
 * Review and discuss the proposed modifications inline
@@ Line 151: / Line 160: @@
 File:Merge_04.png|Click to enlarge
 </gallery>
 ===Wiki===
-A separate system for documentation called Wiki, is built right into each GitLab project. It is enabled by default on all new projects and you can find it under Wiki in your project.<br>
+A separate system for documentation called Wiki, is built right into each GitLab project. It is enabled by default on all new projects and you can find it under Wiki in your project.<br />
-Wikis are very convenient if you don't want to keep your documentation in your repository, but you do want to keep it in the same project where your code resides.<br>
+Wikis are very convenient if you don't want to keep your documentation in your repository, but you do want to keep it in the same project where your code resides.<br />
 You can create Wiki pages in the web interface or locally using Git since every Wiki is a separate Git repository.
@@ Line 162: / Line 172: @@
 Once you enter the page name, it's time to fill in its content. GitLab wikis support Markdown, RDoc and AsciiDoc. For Markdown based pages, all the Markdown features are supported and for links there is some wiki specific behavior.
-More informations :<br>
+More informations :<br />
 https://docs.gitlab.com/ce/user/markdown.html
@@ Line 171: / Line 181: @@
 File:Wiki_04.png|Click to enlarge
 </gallery>
@@ Line 177: / Line 188: @@
 There are 2 types of snippets, personal snippets and project snippets.
 * Personal snippets are not related to any project and can be created completely independently. There are 3 visibility levels that can be set, public, internal and private
 * Project snippets are always related to a specific project
 There are 2 main ways of how you can discover snippets in GitLab.
 * For exploring all snippets that are visible to you, you can go to the Snippets dashboard of your GitLab instance via the top navigation. For GitLab.com you can find it here. This navigates you to an overview that shows snippets you created and allows you to explore all snippets.
 * If you want to discover snippets that belong to a specific project, you can navigate to the Snippets page via the left side navigation on the project page.
@@ Line 188: / Line 201: @@
 File:Snip_02.png|Click to enlarge
 </gallery>
@@ Line 206: / Line 220: @@
 File:Sett_Mem_04.png|Click to enlarge
 </gallery>
@@ Line 259: / Line 274: @@
 =Advanced use=
 ==Handling big files==
-One of the newest functionnalities is LFS (as in '''Large File Storage''').<br>
+One of the newest functionnalities is LFS (as in '''Large File Storage''').<br />
 Recently Git was used exclusively for sharing code (hence, small files). But nowaday even code is sometimes used with big filesets, or are provided archives, CD/DVD images, etc.
 Because of that have been implemented the ability to do so, by defining (on a project-by-project basis) the file extentions to see as "big files".
@@ Line 279: / Line 295: @@
 '''Windows'''
-Use the Windows installer here: <br>
+Use the Windows installer here: <br />
 https://github.com/git-lfs/git-lfs/releases
 ===Use===
-Lets take a look at the workflow when you need to check large files into your Git repository with Git LFS. For example, if you want to upload a very large file and check it into your Git repository:<br>
+Lets take a look at the workflow when you need to check large files into your Git repository with Git LFS. For example, if you want to upload a very large file and check it into your Git repository:<br />
 <console>
 ##i##git clone git@app.giga.ulg.ac.be:dummy/my-awesome-project.git
@@ Line 292: / Line 309: @@
 </console>
-Once a certain file extension is marked for tracking as a LFS object you can use Git as usual without having to redo the command to track a file with the same extension:<br>
+Once a certain file extension is marked for tracking as a LFS object you can use Git as usual without having to redo the command to track a file with the same extension:<br />
 <console>
 ##i##cp ~/tmp/mybigdataset.tgz .##!i##           # copy a large file into the current directory
@@ Line 300: / Line 317: @@
 </console>
-And, of course, when wanting to fetch the latest big files from a repository:<br>
+And, of course, when wanting to fetch the latest big files from a repository:<br />
 <console>
 ##i##git lfs fetch master
 </console>
-More informations :<br>
+More informations :<br />
 https://app.giga.ulg.ac.be/git/help/workflow/lfs/manage_large_binaries_with_git_lfs.md

@@ Line 1: / Line 1: @@
 =Introduction=
-[[GitLab|'''GitLab''']] is a web interface that make the sharing of programing code easier through [[git|'''git''']], a versioning control system.<br>
+[[GitLab|'''GitLab''']] is a web interface that make the sharing of programing code easier through [[git|'''git''']], a versioning control system.<br />
-It works mostly like GitHub, which is its' "hosted by private company" equivalent (hence no one really have complete control over their code location and who can or cannot access it).<br>
+It works mostly like GitHub, which is its' "hosted by private company" equivalent (hence no one really have complete control over their code location and who can or cannot access it).
 We, at GIGA, provide our members with a self hosted, secure and rock solid instance of this tool.
@@ Line 9: / Line 9: @@
 Once done, visit http://app.giga.ulg.ac.be/git/ and use your ULiège credentials to log in, which will send you to that screen.
 [[File:gitlab_00.png|thumb|center|320px|Click to enlarge]]
@@ Line 16: / Line 17: @@
 [[File:gitlab_02.png|thumb|center|320px|Click to enlarge]]
-There are not much to go with as a new member.<br>
+There are not much to go with as a new member.<br />
 Most of the projects being set as "privates", you must request from your PI or any designated IT manager access to your group's repositories.
@@ Line 22: / Line 23: @@
 [[File:gitlab_03.png|thumb|center|320px|Click to enlarge]]
-The address is always created the same way.<br>
+The address is always created the same way.<br />
 From http://app.giga.ulg.ac.be/git/ is added, first, the user's (or group's) name and then repository's name.
@@ Line 28: / Line 29: @@
 Those being :
-* '''''Private'''''  - Project access must be granted explicitly to each user.
+* '''''Private''''' - Project access must be granted explicitly to each user.
 * '''''Internal''''' - The project can be accessed by any logged in user.
-* '''''Public'''''   - The project can be accessed without any authentication.
+* '''''Public''''' - The project can be accessed without any authentication.
-For security reasons -again- we ask the users to set most of their work to private, and create (or change their configuration) public ones only when needed.<br>
+For security reasons -again- we ask the users to set most of their work to private, and create (or change their configuration) public ones only when needed.<br />
 For, as an example, when they need to share their code at the end of their PhD or post-doc.
 ==Explore a repository==
-From there, things can be as much simple as they can become more complex.<br>
+From there, things can be as much simple as they can become more complex.<br />
 As a matter of fact, you can see on the next picture that several informations appear right after creating a repository.
 [[File:gitlab_04.png|thumb|center|320px|Click to enlarge]]
@@ Line 48: / Line 51: @@
 [[File:gitlab_05.png|thumb|center|320px|Click to enlarge]]
-Right after the click come a quite lightweight interface.<br>
+Right after the click come a quite lightweight interface.<br />
 No tools, just some writing zones to create/modify the file's name and its' content but also a '''commit''' which is a bit like a comment related to what you did to one/several files.
-Usualy it is of good practice to create a README.md file.<br>
+Usualy it is of good practice to create a README.md file.<br />
-That file is showed by default when someone come to the repository's main page and it uses a gitlab flavored markdown.<br>
+That file is showed by default when someone come to the repository's main page and it uses a gitlab flavored markdown.<br />
 ''See more about it here : https://about.gitlab.com/handbook/product/technical-writing/markdown-guide/''
-An interesting feature, like showed on the next picture, is the ability to select and interact with several places of the file at the same time by maintaining CTRL key while clicking to the wanted places.<br>
+An interesting feature, like showed on the next picture, is the ability to select and interact with several places of the file at the same time by maintaining CTRL key while clicking to the wanted places.<br />
 From there all the keyboard interactions (being writing, deleting, moving with the arrows, etc.) will be applied at each of your selections.
 [[File:gitlab_06.png|thumb|center|320px|Click to enlarge]]
-Finaly, our first commit is in place.<br>
+Finaly, our first commit is in place.<br />
 The README.md content is, as said before, showed and its' markdown interpreted.
 [[File:gitlab_07.png|thumb|center|320px|Click to enlarge]]
@@ Line 69: / Line 73: @@
 [[File:gitlab_08.png|thumb|center|320px|Click to enlarge]]
-That spot might be one of the most important ones.<br>
+That spot might be one of the most important ones.<br />
 Like told before, GIGA has choosen to put emphazis on security.
-Because of that, when working on your repositories you will have to be aware of it.<br>
+Because of that, when working on your repositories you will have to be aware of it.<br />
-In fact, when inside GIGA (or through the VPN), you'll just fetch from the SSH address which is the safest way but also the stronger and powerful one.<br>
+In fact, when inside GIGA (or through the VPN), you'll just fetch from the SSH address which is the safest way but also the stronger and powerful one.<br />
 Thank to this, you'll just need one login-like and that's it : feel free to push, pull, remove datas without any more prompts.
-Though once out of our computing infrastructure, if you need some more work without any credentials others that the website's login, you'll need to select the HTTP one.<br>
+Though once out of our computing infrastructure, if you need some more work without any credentials others that the website's login, you'll need to select the HTTP one.<br />
 The only thing that it implies is that, at each command you'll execute (mostly pushes and pulls), it will ask you your website's username and passwords.
@@ Line 87: / Line 92: @@
 ===Repository===
 This first menu is all about repositories' informations. In a visual way you can see it's content as :
 # The actual files in it
 # A commits log, which is (if correctly named/commented when they where done) a way to keep and/or find modifications through time
@@ Line 102: / Line 108: @@
 File:setup_1_03.png|Click to enlarge
 </gallery>
 ===Issues===
-As shown on the pictures right below this text, an other interesting section is the "Issues" system.<br>
+As shown on the pictures right below this text, an other interesting section is the "Issues" system.<br />
 It is repository-centric, thus you need to navigate into one for having access to the creation of new issues.
@@ Line 120: / Line 127: @@
 File:Issues_05.png|Click to enlarge
 </gallery>
 ===Merge requests===
-Merge requests allow you to exchange changes you made to source code and collaborate with other people on the same project.<br>
+Merge requests allow you to exchange changes you made to source code and collaborate with other people on the same project.<br />
 A Merge Request (MR) is the basis of GitLab as a code collaboration and version control platform. Is it simple as the name implies: a request to merge one branch into another.
 With GitLab merge requests, you can:
 * Compare the changes between two branches
 * Review and discuss the proposed modifications inline
@@ Line 151: / Line 160: @@
 File:Merge_04.png|Click to enlarge
 </gallery>
 ===Wiki===
-A separate system for documentation called Wiki, is built right into each GitLab project. It is enabled by default on all new projects and you can find it under Wiki in your project.<br>
+A separate system for documentation called Wiki, is built right into each GitLab project. It is enabled by default on all new projects and you can find it under Wiki in your project.<br />
-Wikis are very convenient if you don't want to keep your documentation in your repository, but you do want to keep it in the same project where your code resides.<br>
+Wikis are very convenient if you don't want to keep your documentation in your repository, but you do want to keep it in the same project where your code resides.<br />
 You can create Wiki pages in the web interface or locally using Git since every Wiki is a separate Git repository.
@@ Line 162: / Line 172: @@
 Once you enter the page name, it's time to fill in its content. GitLab wikis support Markdown, RDoc and AsciiDoc. For Markdown based pages, all the Markdown features are supported and for links there is some wiki specific behavior.
-More informations :<br>
+More informations :<br />
 https://docs.gitlab.com/ce/user/markdown.html
@@ Line 171: / Line 181: @@
 File:Wiki_04.png|Click to enlarge
 </gallery>
@@ Line 177: / Line 188: @@
 There are 2 types of snippets, personal snippets and project snippets.
 * Personal snippets are not related to any project and can be created completely independently. There are 3 visibility levels that can be set, public, internal and private
 * Project snippets are always related to a specific project
 There are 2 main ways of how you can discover snippets in GitLab.
 * For exploring all snippets that are visible to you, you can go to the Snippets dashboard of your GitLab instance via the top navigation. For GitLab.com you can find it here. This navigates you to an overview that shows snippets you created and allows you to explore all snippets.
 * If you want to discover snippets that belong to a specific project, you can navigate to the Snippets page via the left side navigation on the project page.
@@ Line 188: / Line 201: @@
 File:Snip_02.png|Click to enlarge
 </gallery>
@@ Line 206: / Line 220: @@
 File:Sett_Mem_04.png|Click to enlarge
 </gallery>
@@ Line 259: / Line 274: @@
 =Advanced use=
 ==Handling big files==
-One of the newest functionnalities is LFS (as in '''Large File Storage''').<br>
+One of the newest functionnalities is LFS (as in '''Large File Storage''').<br />
 Recently Git was used exclusively for sharing code (hence, small files). But nowaday even code is sometimes used with big filesets, or are provided archives, CD/DVD images, etc.
 Because of that have been implemented the ability to do so, by defining (on a project-by-project basis) the file extentions to see as "big files".
@@ Line 279: / Line 295: @@
 '''Windows'''
-Use the Windows installer here: <br>
+Use the Windows installer here: <br />
 https://github.com/git-lfs/git-lfs/releases
 ===Use===
-Lets take a look at the workflow when you need to check large files into your Git repository with Git LFS. For example, if you want to upload a very large file and check it into your Git repository:<br>
+Lets take a look at the workflow when you need to check large files into your Git repository with Git LFS. For example, if you want to upload a very large file and check it into your Git repository:<br />
 <console>
 ##i##git clone git@app.giga.ulg.ac.be:dummy/my-awesome-project.git
@@ Line 292: / Line 309: @@
 </console>
-Once a certain file extension is marked for tracking as a LFS object you can use Git as usual without having to redo the command to track a file with the same extension:<br>
+Once a certain file extension is marked for tracking as a LFS object you can use Git as usual without having to redo the command to track a file with the same extension:<br />
 <console>
 ##i##cp ~/tmp/mybigdataset.tgz .##!i##           # copy a large file into the current directory
@@ Line 300: / Line 317: @@
 </console>
-And, of course, when wanting to fetch the latest big files from a repository:<br>
+And, of course, when wanting to fetch the latest big files from a repository:<br />
 <console>
 ##i##git lfs fetch master
 </console>
-More informations :<br>
+More informations :<br />
 https://app.giga.ulg.ac.be/git/help/workflow/lfs/manage_large_binaries_with_git_lfs.md

Difference between revisions of "GitLab:Use"

Revision as of 12:13, 11 July 2018

Contents

Introduction

Web interface

Create a repository

Explore a repository

Address of a repository

Sidebar (setup) of a repository

Repository

Issues

Merge requests

Wiki

Snippets

Settings

Terminal interface

Advanced use

Handling big files

Installation

Use

Difference between revisions of "GitLab:Use"

Revision as of 12:13, 11 July 2018

Contents

Introduction

Web interface

Create a repository

Explore a repository

Address of a repository

Sidebar (setup) of a repository

Repository

Issues

Merge requests

Wiki

Snippets

Settings

Terminal interface

Advanced use

Handling big files

Installation

Use