What is Git?

Git is a version control system used to track changes in computer files. Git's primary purpose is to manage any changes made in one or more projects over a given period of time. It helps coordinate work among members of a project team and tracks progress over time.

What is Gitlab?

GitLab is a web-based DevOps lifecycle tool that provides a Git-repository manager providing wiki, issue-tracking and continuous integration and deployment pipeline features, using an open-source license, developed by GitLab Inc.

How to work with GitLab?

In GitLab, you use groups to manage one or more related projects at the same time.

You can use groups to manage permissions for your projects. If someone has access to the group, they get access to all the projects in the group. You can also view all of the issues and merge requests for the projects in the group, and view analytics that show the group’s activity.

For larger organizations, you can also create subgroups.

More about groups, subgroups and members at https://docs.gitlab.com/ee/topics/set_up_organization.html and https://docs.gitlab.com/ee/user/project/code_owners.html .

To view groups:

1. On the top bar, select Menu > Groups.

2. Select Your Groups. All groups you are a member of are displayed.

Also the same actions to see your projects.

When you open the page of your group, you can see projects (repositories) of this group or subgroup.

More about projects at https://docs.gitlab.com/ee/user/project/working_with_projects.html and at https://docs.gitlab.com/ee/user/project/repository/ .

For example, here is a repository «project» in subgroup «group0».

It is your repository to publish project tasks.

There is a branch switching control in the upper-left area of the project’s webpage. Each branch can be treated as an isolated state of the project sources intended for a particular development goal.

A branch is a version of a project’s working tree. You create a branch for each set of related changes you make. This keeps each set of changes separate from each other, allowing changes to be made in parallel, without affecting each other.

For example, “master” branch typically contains production-ready state of the sources corresponding the accomplished version of the product. “develop” branch typically contains shared work-in-progress state of the sources. Other branches can be created to isolate parts of work on the project while being in process before they’ll be ready to merge into “develop” branch to be shared with other participants of the project.

Merge operations and pull-requests are used to manage and transfer modifications between branches.

More about branches at https://docs.gitlab.com/ee/user/project/repository/branches/ .

There are 2 branches here.

To see actual state of some branch your repository you should switch branch as shown in a next picture.

To submit a file to the repository, you should press «+» button near the branches switcher and press «Upload file».

Then such a pop-up window will appear. You should choose the file you want to upload and change «Commit message».

A commit is information about modified files.

After that you can press «Upload file» button and uploaded file in the repository will be opened. To return to the repository view you can press at the project’s name near the branches switcher («project» here) or in a left menu press «Repository» -> «Files» button.

Returning to the repository view you will see that new file was added. Also information about last commit with a commit message and author is available in this view.

To see all commits you can press «Repository» -> «Commits» button in a left menu. After that you will see a list of commits.

If you press on some commit in this list, you will see changes, which that commit made.

To see the repository state after that commit, press «Browse files» button. You can download whole repository in archive if you press Download button and choose suitable format.

In a branch switcher here you see commit identifier. When you upload all necessary files and want the teacher to check your work, press «Create merge request» button.

Merge requests are the way you check source code changes into a branch. More about merge requests at https://docs.gitlab.com/ee/user/project/merge_requests/ .

Usually according to course’s policy you need to assign your merge request to a teacher, so he could see your merge request and be able to merge it in a master branch. Choose in «Assignee» teacher in a list.

Now you see your merge request. Here could be some comments about your work from teacher. It could be a comment or a Thread as in the next picture. A Thread is a comment that should be answered by you. You will see comments and threads and be able to write your comments here to communicate with teacher.
About merge requests reviewing https://docs.gitlab.com/ee/user/project/merge_requests/reviews/

If some changes to your work needed, you should make a new commit. So, return to the «Repository» -> «Files» and choose the file where you need to make changes. Don’t forget to switch branch if it's necessary! Press «Replace» button to Upload updated file. If you want to delete file, you can press «Delete» button. In both cases new commit will be automatically created.

And Upload updated file in a form.

Returning to the repository view we see our commit with replacing a file.

Let’s see how our merge request changed. To see your merge requests press «Merge requests» button in a left menu.

Choose the merge request. Now you see that new commit was added to opened merge request. You can write a comment to a thread that you made some changes and make brief explanation or answer if it's necessary.

If your work was accepted, merge request will be merged or closed according to course’s policy.

You can edit one file together, but remember, that there could be a conflicts when you tried to commit you changes. For example, here is a conflict in merge request.

There could be a situation when GitLab couldn’t propose you to choose a solution of conflict. Here is only option to merge locally.

More about how to resolve conflicts at https://docs.gitlab.com/ee/topics/git/merge_conflicts.html and https://docs.gitlab.com/ee/user/project/merge_requests/resolve_conflicts.html .

Similar to reverting a merge request, you can opt to revert the changes directly into the target branch or create a new merge request to revert the changes.
See more at https://docs.gitlab.com/ee/user/project/merge_requests/revert_changes.html .

To do it, press on commits and choose a commit.

Press «Revert» button. You will see the dialog box like presented in the next picture.

Press «Revert». After a commit is reverted, the «Revert» button is no longer available.

Usually you can merge pull request automatically. There is a «Resolve conflicts» button appeared.

Press «Resolve conflicts» button. You will see some editor with changes and two proposed options: use theirs and use mine. Press one of this buttons that is suitable for your situation.

If you want to combine two variants of the file, choose «Edit inline» and made some changes.

Finally, press «Commit to source branch» button. So, commit to develop branch with this changes will be created. If all conflicts resolved, it will be possible to merge.

You are working in a team so you can work together in a one time but on different parts of project. Then you need different branches for work. To create new branch press «Repository» -> «Branches» button.

Press «New branch», write name of the branch in a form, choose another branch which should be the start state for the new one and press «Create branch» button.

Another one new branch will be created.

Be carefully with working in different branches on the same files. Divide your subtasks between the team members to work in different branches on different files to avoid conflicts.

More about working with git and git commands: https://git-scm.com/book/en/v2 , https://docs.gitlab.com/ee/topics/git/ .