When programming, for example for your Bachelor or Master thesis, you might want to only show certain versions of your project to others. Additionally you may want to only show one commit message for this version, instead of the whole history. The best way to use it, is setting up two repositories, one for your development and one for the publication. This tutorial will guide you through the process of correctly setting up Git in order to achieve this kind of version control.
First of all you want to setup the project and repository that you will work in. You can do this either via the console or by using the GitLab web interface.
readme.md file is only created if you specify it while creating the repository.
Your repository is now ready, you could start programming and developing as soon as you clone it to your machine, but we want to do something else first: create a second branch.
This again can be done using GitLab or console commands or any other software you choose to manage Git with.
The second branch will contain the releases of your project, this branch will also have only single commit messages for each version. It is important that you do your work and development on the initial
master branch and only use the new branch for release versions. The name of the new branch is irrelevant, I chose to name it
release, so will use this name from now on in this tutorial.
As you can see the commit messages are a bit messy and all concern the same topic: some feature has been added, but needed some fixes directly afterwards.
Let us pretend now, that with this feature (and the subsequent fixes) a new version of the project is ready. Which means I want to merge the changes to the
release branch, but only with one commit message saying something like “Added a new feature, no problems at all” (so that I don't have to admit that I messed everything up at first).
To do this we first have to change to the
git checkout release
Then we merge the changes from the
master branch, using the
git merge --squash master
Now we have to commit and push the changes:
git add . git commit git push
But be careful: the automatically generated commit message will include all commit messages that we want to squash. Just delete the messsage and write your own.
Only the message that we typed during the last commit is visible, but all changes are applied. The
release branch is now up to date.
Once our working repository is finished the next step is to create a repository to publish the version of the
release branch and set up the mirroring itself.
First, we need a new empty repository. This repository will only be used to make our release commits available to others. To avoid any conflicts DO NOT MODIFY this repository, all will be done by the mirroring from the working repository. Once the repository is set up, you can add the persons, who should receive your releases, in the “Members” tab on GitLab, I would recommend giving them read only access.
Now we have to switch back to the original repository. On GitLab we navigate to Settings > Repository > Protected Branches. The master branch will be protected by default, first we will unprotect it. This does not change anything, as you should be the only person with access to this repository anyway. Then we have to add protection to the
release branch. Afterwards it should something like this:
In the next section we will see why this change is important.
Next up we go to Settings > Repository > Mirroring repositories, on our working repository. First, we need the URL of our release repository, you can find it under the Clone option in the release repository. Once you have copied the URL, paste it into the first input field. Then go to the beginning of the URL and add
gitlab.informatik…. It should look something like this (of course the URL and username should be your repository and your username):
To finish the process press Mirror repository. A list including the release repository should be visible now, here you can remove the mirror or update it manually. If we update it manually now and look into our release repository, we will see that there is a branch called
release which includes the same commit as the
release branch on the working repository.
From now on, all pushes to the
release branch on the working repository will be pushed to the release repository as well.
If you create new branches in the working directory make sure, that they are not protected. All protected branches will be pushed to the release repository! (Which is why we unprotected the
master branch during the setup).