<spandir="">Authors: Boudewijn van den Berg, Frodo Muijzer</span>, Frank Wouda
<span dir="">For questions and information, send an e-mail to: </span><span dir="">f.muijzer@utwente.nl</span>
<spandir="">Version 4, </span>2024-03-19
## Introduction
Welcome to the GitLab space of the Biomedical Signals and Systems group of the UT. Here we host source code of many of our projects, both to keep track of changes during development and to keep them archived when the project is finished.
GitLab is a website that allows you to browse trough GIT repositories. GIT is a version control system which keeps track of changes made to source code. Every time you want your changes to be added to the repository, you make a "commit" and "push" to the GitLab server. If someone else wants your changes, he/she has to "fetch" them from the GitLab server.
## User manuals
*[**Working with GitLab (_normal_)**](https://gitlab.utwente.nl/groups/bss_development/-/wikis/home/Working-with-GitLab-(without-Forks))
*[**Working with GitLab (with _forks, see below_)**](https://gitlab.utwente.nl/groups/bss_development/-/wikis/home/Working-with-GitLab-with-Forks)
*[**Public sharing of your projects (4TU)**](https://gitlab.utwente.nl/groups/bss_development/-/wikis/home/4TU-Public-sharing-of-your-projects)
*[**[OLD] Public sharing of your projects (Zenodo)**](https://gitlab.utwente.nl/groups/bss_development/-/wikis/home/Public-sharing-of-your-projects-code)
## Working with multiple people on one project
If you work with multiple people on a project, it is important everyone is up to date. If two users _fetch_ the source code on day 1, user A makes changes and _commit / pushes_ these on day 2, and user B makes changes on day 3 without _fetching_ the changes of user A first, user B will have _merging conflict_ issues _pushing_ the changes of day 3. The _merge conflict_ means the server now has two different set of changes it has to apply to the source code state of day 1. If the changes occur in different files, it can merge them, but if the changes relate to the same thing, you have to manually indicate how to merge the changes. To avoid these issues you can take two routes:
* agree who works when on the code
* work in separate branches and merge these later on
* work in separate forks and merge these later on
By default a repository is on the "main" _origin_. At any moment, you can create a _branch_ of the code. At start, the _branch_ contains exactly the same code as the _origin_, but the changes you apply to the branch are not applied to the origin (it's like a copy). This can be handy if you want to try out a certain feature/change, but you can also use _branches_ to keep the changes of multiple users separate.
A user that is allowed to make changes to a _branch_, can always also make changes on the main _origin._ For larger projects, it might be useful to limit the amount of people that have the rights to change the main project, for example when this project is referred to in scientific publications. In this case, other users can work in a _fork_ of the project, and merge there changes later on. The _fork_ is also a copy of the project, but at a different location. For example for the main repository
<spandir="">\*Repository/Repo = A Git repository is a virtual storage of your project. It allows you to save versions of your code, which you can access when needed.</span>
<spandir="">\*\*Fork = A fork is a copy of a repository (repo) that sits in your account rather than the account from which you forked the data from. Once you have forked a repo, you own your forked copy. This means that you can edit the contents of your forked repository without impacting the parent repo.</span>
<spandir="">Authors: Boudewijn van den Berg, Frodo Muijzer</span>, Frank Wouda
<span dir="">For questions and information, send an e-mail to: </span><span dir="">f.muijzer@utwente.nl</span>
<spandir="">Version 4, </span>2024-03-19
## Introduction
Welcome to the GitLab space of the Biomedical Signals and Systems group of the UT. Here we host source code of many of our projects, both to keep track of changes during development and to keep them archived when the project is finished.
GitLab is a website that allows you to browse trough GIT repositories. GIT is a version control system which keeps track of changes made to source code. Every time you want your changes to be added to the repository, you make a "commit" and "push" to the GitLab server. If someone else wants your changes, he/she has to "fetch" them from the GitLab server.
## User manuals
*[**Working with GitLab (_normal_)**](https://gitlab.utwente.nl/groups/bss_development/-/wikis/home/Working-with-GitLab-(without-Forks))
*[**Working with GitLab (with _forks, see below_)**](https://gitlab.utwente.nl/groups/bss_development/-/wikis/home/Working-with-GitLab-with-Forks)
*[**Public sharing of your projects (4TU)**](https://gitlab.utwente.nl/groups/bss_development/-/wikis/home/4TU-Public-sharing-of-your-projects)
*[**Remove large files in your commit history**](https://gitlab.utwente.nl/groups/bss_development/-/wikis/home/Remove-large-files-from-your-project)
*[**[OLD] Public sharing of your projects (Zenodo)**](https://gitlab.utwente.nl/groups/bss_development/-/wikis/home/Public-sharing-of-your-projects-code)
## Working with multiple people on one project
If you work with multiple people on a project, it is important everyone is up to date. If two users _fetch_ the source code on day 1, user A makes changes and _commit / pushes_ these on day 2, and user B makes changes on day 3 without _fetching_ the changes of user A first, user B will have _merging conflict_ issues _pushing_ the changes of day 3. The _merge conflict_ means the server now has two different set of changes it has to apply to the source code state of day 1. If the changes occur in different files, it can merge them, but if the changes relate to the same thing, you have to manually indicate how to merge the changes. To avoid these issues you can take two routes:
* agree who works when on the code
* work in separate branches and merge these later on
* work in separate forks and merge these later on
By default a repository is on the "main" _origin_. At any moment, you can create a _branch_ of the code. At start, the _branch_ contains exactly the same code as the _origin_, but the changes you apply to the branch are not applied to the origin (it's like a copy). This can be handy if you want to try out a certain feature/change, but you can also use _branches_ to keep the changes of multiple users separate.
A user that is allowed to make changes to a _branch_, can always also make changes on the main _origin._ For larger projects, it might be useful to limit the amount of people that have the rights to change the main project, for example when this project is referred to in scientific publications. In this case, other users can work in a _fork_ of the project, and merge there changes later on. The _fork_ is also a copy of the project, but at a different location. For example for the main repository
<spandir="">\*Repository/Repo = A Git repository is a virtual storage of your project. It allows you to save versions of your code, which you can access when needed.</span>
<spandir="">\*\*Fork = A fork is a copy of a repository (repo) that sits in your account rather than the account from which you forked the data from. Once you have forked a repo, you own your forked copy. This means that you can edit the contents of your forked repository without impacting the parent repo.</span>
<spandir="">\*\*\*Clone = Clone is primarily used to point to an existing repo and make a clone or copy of that repo at in a new directory, at another location. The original repository can be located on the local filesystem or on remote machine accessible supported protocols. The git clone command copies an existing Git repository.</span>
