Git/GitLab - Revision history

Pcs47: /* Issue + MR Templates */ Add note about BOSS license policy.

2026-06-11T22:50:58Z

Issue + MR Templates: Add note about BOSS license policy.

← Older revision		Revision as of 22:50, 11 June 2026
Line 200:		Line 200:

	<!-- Summary of the testing done to validate the MR --></pre></li></ul>		<!-- Summary of the testing done to validate the MR --></pre></li></ul>

			For projects specific to [[BOSS]], they must also include a checkbox for [https://developercertificate.org/ DCO] acknowledgement according to the [https://boss.bathcs.com/policies/licenses/ BOSS license policy].

	=== CI Pipelines ===		=== CI Pipelines ===

Hw2210: Resize images

2026-06-08T19:17:04Z

Resize images

Hw2210: /* See also */ Don't show redirects

2026-06-05T13:55:45Z

Hw2210: Hw2210 moved page Git/Gitlab to Git/GitLab: Misspelled title

2026-06-03T20:45:30Z

Hw2210 moved page Git/Gitlab to Git/GitLab: Misspelled title

← Older revision	Revision as of 20:45, 3 June 2026
(No difference)

Hw2210: Add see also section

2026-06-03T20:36:03Z

Add see also section

← Older revision		Revision as of 20:36, 3 June 2026
Line 208:		Line 208:

	The configuration can be found in the <code>.gitlab-ci.yml</code> file.		The configuration can be found in the <code>.gitlab-ci.yml</code> file.

			== See also ==

			{{Special:PrefixIndex\|prefix=Git\|namespace=0}}
			[[Category:Tutorial]]

Hw2210: Translate from boss.bathcs.com

2026-06-03T18:52:50Z

Translate from boss.bathcs.com

New page

We require that the websites hosted on bathcs.com should be stored in [https://gitlab.bath.ac.uk/cs the cs organisation on Bath’s GitLab instance]. Any project used by student-led initiatives can also be stored on here.

GitLab was chosen because it has a lot more (useful) features than GitHub. However this does mean that it is aimed at people who has a basic knowledge of how to properly manage git projects.

Therefore you will need to be able to use GitLab.

{{Note|type=warn|text=
You cannot push or pull to the GitLab outside of the VPN, even though you can access the page.
}}

== Setup ==

You might have set this up when handing over, if you haven’t, here are the instructions. Note you will have to ask an organisation manager to add you to the organisation if you are going to be editing any current projects.

* Go to https://gitlab.bath.ac.uk
* Login with your University credentials
* Setup TOTP as your 2FA (one time codes). See [[2FA#TOTP|our 2FA section]] for more information about what this is and how to add one (you can skip to the section where it says “Once you see a QR code”)

Once you have logged in, your account will be created and so can be added to organisations or tagged (using @username).

=== SSH Keys ===

If you want to commit or clone repos, you will also need to setup an SSH key:

# Create an SSH key: see [[SSH keys|our documentation]] for information on how to set one up.
# Go to your preferences (click profile icon then click preferences).
# Click “SSH Keys”.
# Copy and paste the public key into the “Key” section.
# Give it a title.
# Change usage type to “Authentication only”.
# Click “Add key”.

By default this will expire in a year, after which you will have to add another key in the same way.

=== Extra Emails ===

You may have already set up git with your personal email address or you have a git signing key with a specific email. You probably don’t want to edit the configuration on a per project basis.

To solve this, GitLab and GitHub allow you to have multiple email addresses linked to your account, this can be found by going to preferences (click the profile icon then preferences) then clicking “Emails”.

You can then type in another email into the box and click “Add email address”. You will then have to verify the email by clicking the link it gives you.

== The CS Organisation ==

All Student Led Initiative projects are stored on the [https://gitlab.bath.ac.uk/cs Computer Science SLI organisation]. If you are a committee member you should have been given access to it. If not please contact the current owners, who can be found by going “Group information > Members”.

[[File:git-gitlab_members.gif|Members page on GitLab showing the current owners and maintainers found by going to Members in the navigation group “Group Information”]]

The organisation or group has subgroups for all societies or student-led initiatives. You should have developer rights on all initiatives which you are a part of, which allows you to create branches on the existing projects and push to them. If you ask nicely you may get maintainer rights, which will allow you to create new projects and merge MRs into main (however you still can’t push to the <code>main</code> branch).

There are some projects which live outside the subgroups (e.g. this wiki) as they don’t have a organisation apart of. You will have to specifically ask permission to access individual projects for security reasons.

== Issues ==

=== Creating ===

[[File:git-create_issue.gif|gif showing the steps of going to the issues menu under pinned and clicking new issue button]]

Creating an issue is easy, you can click on the “Issues” tab under “pinned” and click “New Issue” and start typing. The description is written in markdown. You can [https://docs.gitlab.com/ee/user/markdown.html learn markdown on the GitLab website].

If the project is configured with templates, there should be a dropdown for you to choose the one most relavent to your issue type.

[[File:git-mr_templates.gif|gif showing the dropdown to select the template to use above the description]]

You can then assign someone an issue from the menu if you know who will be working on it. Labels are also available, but these are mostly for the maintainers of the project to use.

Once the issue is created, it will assign the issue a number (you can see this in the URL), which you can use to cross-reference issues or MRs by putting a <code>#</code> before it. GitLab will pick this up and turn it into a link (you can also just put the link and it will be sortened). Note that issues on other projects can also be referenced.

=== Managing Issues ===

There is not much to say about managing issues. All conversations about the issue should be done on the issue itself.

Once someone is working on it, they should be assigned the issue and it should be referenced in the MR which fixes it.

If “Closes” is put before the link to the issue on an MR, once it is merged, the issue should automatically be closed (but please always do check all the related issues are closed).

== Forking + Branches ==

If you are a developer or maintainer on a project, you should be able to create a branch on the project (but just not push directly main). Branches should be under the format <code><username>/<fix_summary></code>.

If you are not a developer but would like to contribute to a project, you should be able to fork the repository into your own space to create make any edits you wish.

== Merge Requests ==

=== Creating ===

[[File:git-create_mr.gif|gif showing the steps of going to the merge requests menu under pinned and clicking new merge request button and choosing a branch to merge into main]]

Once you have created a fork or branch, you can create a merge request, either by clicking the link which is shown after pushing, or going onto the project and clicking “Merge requests” at the left and choosing “New merge request”. You can then choose the branch you want to merge from and the one you are merging to (most likely <code>main</code>).

The interface is very similar to issues, with the summary written in markdown and templates available.

If the Merge Request is not finished, and so still a work in progress, you can click the “Mark Draft” button or put “DRAFT:” at the start of the summary.

You can then assign the MR to yourself (as you will be managing it). You then also want to set the reviewer to a maintainer who can then merge the issue.

If the MR depends on another MR to be merged beforehand, please add the “blocked” label and mention what its blocked on in a comment or the issue directly.

=== Managing ===

Sadly as the university does not pay for premium GitLab, we have to do most security practices as manual steps. So please do not go against these procedures, we beg of you.

If you are the reviewer of a MR, you can go onto the “Changes” tab where you can see all the differences between this and the main branch. There is a settings button where you can change parts of the look. I recommend enabling “show whitespace changes” to help find where people have accidentally left trailing whitespace.

You can then add a comment on a line by hovering over the line and clicking the comment button on the left hand side. You can also do this on images if you wish.

When adding a comment you have the option to “start a review” which is recommended if you are going to be making multiple comments as it send them out all at once instead of having a separate email for each comment (which is a lot).

If you drag the comment, you can also select multiple lines which is useful for segments of code which need changing.

[[File:git-start_review.gif|gif showing going to commits tab and adding a comment to the review, selecting multiple lines]]

It is expected that the assignee will then resolve all of these issues so it is not up to the reviewer (but as we are students they may need chasing).

Once you are happy with the MR, you can then approve the merge request before merging it.

Please make sure that:

* You don’t approve your own MR
* Don’t merge something without approval (if it is going into <code>main</code>)
* Don’t approve without actually reading all the changes

== Creating a new Project ==

Over time we may want to add more projects to the organisation. This page focuses on creating projects from scratch. If you are just wanting to mirror, see the [[Git/Mirrors|page about mirrors]].

When creating a new repo or project, you need to decide which subgroup it should go under. This should be quite simple, however you may decide a new subgroup is required.

If you are not a maintainer in a repository, you will have to find the maintainers of the subgroup and ask one of them to set up the repo for you and then add you to the access list.

Other things to consider when creating a project:

* Name (please make this understandable about what it is for)
* Visibility level:
** '''Private''': only people with access can see it (preferably not), however is understandable if you are just testing out a project.
** '''Internal''': Only bath students can see it when logged in, this is useful for things which interact with University of Bath services which they may not want known to the public.
** '''Public''': This should be used for most projects to encourage the open source nature of the community.

Once a repository is created you can add it as a remote to your repo or clone it.

You should then:

* Go to “Settings > Repository > Protected branches” and change “Allowed to push and merge” to be “No one” and make sure “Merge MRs” is set to “Maintainers only”.
* Add a description or logo in the “Settings > General” tab
* Add a license as explained [[Git/Special files#license|here]].

[[File:git-setup_new_project.gif|gif showing the process of editing the protected branches to only allow maintainers to merge to main and no one to push to the main]]

=== Manage Access ===

You can choose who can access the repository in “Manage > Members” if you are a Maintainer or Owner.

To add new person you can click “Invite members” and type in their username (they will need to have signed into GitLab for their username to appear).

You then need to choose their role. It is recommended to put them as “Developer” unless you want them to be able to merge requests into <code>main</code>, then put them as “Maintainer”.

=== Labels ===

Under “Manage > Labels” you can add or create labels which can be used on merge requests or issues. You should inherit any labels from the parent group, and preferably labels should be group wide. But you can create a label and ask an Owner to upgrade the label to a group label by clicking the 3 dots.

=== Issue + MR Templates ===

In your project, you may want to have templates for people creating issues or MRs to save them time and to standardise them.

This is quite simple to do in GitLab as explained [https://docs.gitlab.com/ee/user/project/description_templates.html here].

In short, you need to add markdown files to <code>.gitlab/issue_templates/</code> or <code>.gitlab/merge_request_templates/</code>. The default should be named <code>default.md</code>.

Examples:

<ul>
<li><code>.gitlab/issue_templates/default.md</code>
<pre class="md">### Summary



### Steps to reproduce

</pre></li>
<li><code>.gitlab/merge_request_templates/default.md</code>
<pre class="md">### Related Issue



Closes #

### Summary



### Testing

</pre></li>
<li><code>.gitlab/merge_request_templates/bug_fix.md</code>
<pre class="md">### Summary



### Testing

</pre></li></ul>

=== CI Pipelines ===

GitLab pipelines are super powerful and I don’t think I could write better documentation than GitLab themselves (which can be found [https://docs.gitlab.com/ee/ci/pipelines/ here]).

This is just here to say they do exist and they should be used for automated testing or even deployment.

The configuration can be found in the <code>.gitlab-ci.yml</code> file.

← Older revision		Revision as of 19:17, 8 June 2026
Line 45:		Line 45:
	All Student Led Initiative projects are stored on the [https://gitlab.bath.ac.uk/cs Computer Science SLI organisation]. If you are a committee member you should have been given access to it. If not please contact the current owners, who can be found by going “Group information > Members”.		All Student Led Initiative projects are stored on the [https://gitlab.bath.ac.uk/cs Computer Science SLI organisation]. If you are a committee member you should have been given access to it. If not please contact the current owners, who can be found by going “Group information > Members”.

	[[File:git-gitlab_members.gif\|Members page on GitLab showing the current owners and maintainers found by going to Members in the navigation group “Group Information”]]		[[File:git-gitlab_members.gif\|Members page on GitLab showing the current owners and maintainers found by going to Members in the navigation group “Group Information”\|764x764px]]

	The organisation or group has subgroups for all societies or student-led initiatives. You should have developer rights on all initiatives which you are a part of, which allows you to create branches on the existing projects and push to them. If you ask nicely you may get maintainer rights, which will allow you to create new projects and merge MRs into main (however you still can’t push to the <code>main</code> branch).		The organisation or group has subgroups for all societies or student-led initiatives. You should have developer rights on all initiatives which you are a part of, which allows you to create branches on the existing projects and push to them. If you ask nicely you may get maintainer rights, which will allow you to create new projects and merge MRs into main (however you still can’t push to the <code>main</code> branch).
Line 55:		Line 55:
	=== Creating ===		=== Creating ===

	[[File:git-create_issue.gif\|gif showing the steps of going to the issues menu under pinned and clicking new issue button]]		[[File:git-create_issue.gif\|gif showing the steps of going to the issues menu under pinned and clicking new issue button\|728x728px]]

	Creating an issue is easy, you can click on the “Issues” tab under “pinned” and click “New Issue” and start typing. The description is written in markdown. You can [https://docs.gitlab.com/ee/user/markdown.html learn markdown on the GitLab website].		Creating an issue is easy, you can click on the “Issues” tab under “pinned” and click “New Issue” and start typing. The description is written in markdown. You can [https://docs.gitlab.com/ee/user/markdown.html learn markdown on the GitLab website].
Line 61:		Line 61:
	If the project is configured with templates, there should be a dropdown for you to choose the one most relavent to your issue type.		If the project is configured with templates, there should be a dropdown for you to choose the one most relavent to your issue type.

	[[File:git-mr_templates.gif\|gif showing the dropdown to select the template to use above the description]]		[[File:git-mr_templates.gif\|gif showing the dropdown to select the template to use above the description\|491x491px]]

	You can then assign someone an issue from the menu if you know who will be working on it. Labels are also available, but these are mostly for the maintainers of the project to use.		You can then assign someone an issue from the menu if you know who will be working on it. Labels are also available, but these are mostly for the maintainers of the project to use.
Line 85:		Line 85:
	=== Creating ===		=== Creating ===

	[[File:git-create_mr.gif\|gif showing the steps of going to the merge requests menu under pinned and clicking new merge request button and choosing a branch to merge into main]]		[[File:git-create_mr.gif\|gif showing the steps of going to the merge requests menu under pinned and clicking new merge request button and choosing a branch to merge into main\|820x820px]]

	Once you have created a fork or branch, you can create a merge request, either by clicking the link which is shown after pushing, or going onto the project and clicking “Merge requests” at the left and choosing “New merge request”. You can then choose the branch you want to merge from and the one you are merging to (most likely <code>main</code>).		Once you have created a fork or branch, you can create a merge request, either by clicking the link which is shown after pushing, or going onto the project and clicking “Merge requests” at the left and choosing “New merge request”. You can then choose the branch you want to merge from and the one you are merging to (most likely <code>main</code>).
Line 109:		Line 109:
	If you drag the comment, you can also select multiple lines which is useful for segments of code which need changing.		If you drag the comment, you can also select multiple lines which is useful for segments of code which need changing.

	[[File:git-start_review.gif\|gif showing going to commits tab and adding a comment to the review, selecting multiple lines]]		[[File:git-start_review.gif\|gif showing going to commits tab and adding a comment to the review, selecting multiple lines\|524x524px]]

	It is expected that the assignee will then resolve all of these issues so it is not up to the reviewer (but as we are students they may need chasing).		It is expected that the assignee will then resolve all of these issues so it is not up to the reviewer (but as we are students they may need chasing).
Line 145:		Line 145:
	* Add a license as explained [[Git/Special files#license\|here]].		* Add a license as explained [[Git/Special files#license\|here]].

	[[File:git-setup_new_project.gif\|gif showing the process of editing the protected branches to only allow maintainers to merge to main and no one to push to the main]]		[[File:git-setup_new_project.gif\|gif showing the process of editing the protected branches to only allow maintainers to merge to main and no one to push to the main\|627x627px]]

	=== Manage Access ===		=== Manage Access ===

← Older revision		Revision as of 13:55, 5 June 2026
Line 211:		Line 211:
	== See also ==		== See also ==

	{{Special:PrefixIndex\|prefix=Git\|namespace=0}}		{{Special:PrefixIndex\|prefix=Git\|namespace=0\|hideredirects=1}}
	[[Category:Tutorial]]		[[Category:Tutorial]]