Git is a modern distributed revision control system, in a way pretty much like svn (or cvs, rcs), which is centralized. but git is much more powerful, especially when it comes to working with branches.
It’s a full blown devops-tool nowadays and besides keeping track of your code, you can configure build- and deploy-pipelines, connect it to kubernetes and whatnot.
<\/p>\n\n\n\n
In this post I’ll cover the basics on how to install a gitlab server “manually” with the omnibus installer (this is pretty straightforward as it brings it’s own chef installer) and getting started with basic commands and workflows.
If you despise “manual” installations entirely, you may take a look at the puppetlabs module (which also uses omnibus, which utilizes chef).
However, I for one strongly believe in doing things myself at least one time, for a better understanding of how they work.<\/p>\n\n\n\n
apt-get install -y curl openssh-server ca-certificates<\/code><\/pre>\n\n\n\nespecially ca-certificates are important<\/p>\n\n\n\n
echo postfix postfix\/main_mailer_type select \"Internet Site\" | debconf-set-selections\necho postfix postfix\/mailname select `hostname -f` | debconf-set-selections\necho unattended-upgrades unattended-upgrades\/enable_auto_updates boolean true | debconf-set-selections<\/code><\/pre>\n\n\n\nGitlab requires postfix and postfix (even in this very basic setup) requires some input.
Thats what debconf is used for here, for pre-defining the needed values for the unattended (not in our case) installation. <\/p>\n\n\n\n
apt-get -y install postfix unattended-upgrades<\/code><\/pre>\n\n\n\nInstall postfix.<\/p>\n\n\n\n
curl -sS https:\/\/packages.gitlab.com\/install\/repositories\/gitlab\/gitlab-ce\/script.deb.sh | bash<\/code><\/pre>\n\n\n\nThe above script detects your OS, adds the correct repository to your sources.list and imports the gpg key.
You may as well fetch the with wget and then import it with apt-key add.<\/p>\n\n\n\n
apt-get install -y gitlab-ce<\/code><\/pre>\n\n\n\nLet’s install gitlab. This will take some time while chef does it’s thing.<\/p>\n\n\n\n
vi \/etc\/hosts\n127.0.1.1 gitlab.your.domain gitlab\n192.168.122.123 gitlab.your.domain gitlab<\/code><\/pre>\n\n\n\nDouble check that your \/etc\/hosts entries fit, gitlab relies on it.<\/p>\n\n\n\n
cp \/home\/user\/gitlab.your.domain-key.pem \/etc\/gitlab\/ssl\/gitlab.your.domain.key\ncp \/home\/user\/gitlab.your.domain-pub.pem \/etc\/gitlab\/ssl\/gitlab.your.domain.crt\n\nSkip this step if your certs are not self signed:\n\nmv \/home\/user\/ca-root.pem \/usr\/local\/share\/ca-certificates\/ca-root.crt\nupdate-ca-certificates <\/code><\/pre>\n\n\n\nNow get yourself an ssl certificate<\/a> for your domain, either self signed or maybe through a service like letsencrypt and copy it to \/etc\/gitlab\/ssl.<\/p>\n\n\n\nvi \/etc\/gitlab\/gitlab.rb\n\nexternal_url 'https:\/\/gitlab.your.domain'\n\ngitlab-ctl reconfigure\ngitlab-ctl restart<\/code><\/pre>\n\n\n\nYou should now be able to access gitlab with a browser on https:\/\/gitlab.your.domain.
Create yourself a password for the root account and then create a user.
<\/p>\n\n\n\n
<\/p>\n\n\n\n
If something does not work<\/strong>, here are some troubleshooting tips:<\/p>\n\n\n\ngitlab-rake gitlab:check SANITIZE=true<\/code><\/pre>\n\n\n\ndoes a config check<\/p>\n\n\n\n
gitlab-ctl status<\/code><\/pre>\n\n\n\nshows the status of the various gitlab processes<\/p>\n\n\n\n
tail -f \/var\/log\/gitlab\/*<\/code><\/pre>\n\n\n\ngitlab is pretty verbose about it’s actions though it can be somewhat hard to figure out which component is failing because there are lots of them.<\/p>\n\n\n\n
\n\n\n\nworking with git – the basics<\/h3>\n\n\n\n
I recommend using git (from the commandline) with ssh, therefore you should:<\/p>\n\n\n\n
- Login as your user via the webinterface<\/li>
- click on the icon in the top right corner and then settings<\/li>
- on the sidebar to the left, click on SSH KEYS<\/li>
- upload an ssh key<\/li>
- test your connection by logging in via ssh (ssh git@gitlab.your.domain)<\/li><\/ul>\n\n\n\n
creating a new project<\/h4>\n\n\n\n
Commandline:<\/p>\n\n\n\n
mkdir myproject\nvi some_fancy_code.ending\ngit init \nInitialized empty Git repository in \/home\/user\/myproject\/.git\/\ngit add --all # No Output, tells git to track the file, in this case all of them\ngit commit -m \"initial commit\" # commits to the local repository\n[master (root-commit) ec268cc] initial commit\n 1 file changed, 1 insertion(+)\n create mode 100644 some_fancy_code.ending\ngit remote add origin git@gitlab.your.domain:user\/myproject.git # adds a remote repo on your currently created git server, no Output\ngit push origin master # pushes our changes to the master branch \nEnumerating objects: 3, done.\nCounting objects: 100% (3\/3), done.\nWriting objects: 100% (3\/3), 210 bytes | 210.00 KiB\/s, done.\nTotal 3 (delta 0), reused 0 (delta 0)\nremote: \nremote: The private project user\/myproject was successfully created.\nremote: \nremote: To configure the remote, run:\nremote: git remote add origin git@gitlab.your.domain:user\/myproject.git\nremote: \nremote: To view the project, visit:\nremote: https:\/\/gitlab.your.domain\/user\/myproject\nremote: \nTo gitlab.user.domain:user\/myproject.git\n * [new branch] master -> master<\/code><\/pre>\n\n\n\nYou may also just stay logged in with your browser and click on the “Plus” in the top right “corner” and then select project.
This way you will easily create a new project, but you will first have to check it out in order to work with it<\/p>\n\n\n\n
checking out the project<\/h4>\n\n\n\ngit clone git@gitlab.your.domain:user\/myproject.git<\/code><\/pre>\n\n\n\nIf you want to check out your project elsewhere or even another project, use git clone.
this works with https too (as do all commands described here), git clone https:\/\/gitlab.your.domain\/user\/myproject.gi<\/p>\n\n\n\n
updating an already cloned project from the remote server<\/h4>\n\n\n\ncd myproject\ngit pull<\/code><\/pre>\n\n\n\nthis pulls the changes from your remote server for the checked out branch (at the moment this should be master).
It’s best to do this every time you enter the local repository (your directory), if only to avoid merge conflicts as much as possible. <\/p>\n\n\n\n
using branches<\/h4>\n\n\n\n~\/myproject $ git checkout -b testbranch\nSwitched to a new branch 'testbranch'<\/code><\/pre>\n\n\n\nBranching is a great way to work on a copy of your project and change things, without breaking your “working” or “production” branch, ideally master (but branch as much as you like).
It is good practice (in teams even more then when working alone but it’s always useful) to create a branch of your working code, work on it and then commit it, test it on (e.g.) a testsystem, let it be reviewed by others or whatever and only merge it into your stable branch when you are sure it works (or at least doesn’t break anything).<\/p>\n\n\n\n
~\/myproject $ vi some_fancy_code.ending # add some more text\ngit add some_fancy_code.ending\ngit commit -m \"add more text\"\ngit push --set-upstream origin testbranch\n\nEnumerating objects: 5, done.\nCounting objects: 100% (5\/5), done.\nWriting objects: 100% (3\/3), 244 bytes | 22.00 KiB\/s, done.\nTotal 3 (delta 0), reused 0 (delta 0)\nremote: \nremote: To create a merge request for testbranch, visit:\nremote: https:\/\/gitlab.your.domain\/user\/myproject\/merge_requests\/new?merge_request%5Bsource_branch%5D=testbranch\nremote: \nTo gitlab.user.domain:user\/myproject.git\n * [new branch] testbranch -> testbranch\nBranch 'testbranch' set up to track remote branch 'testbranch' from 'origin'.<\/code><\/pre>\n\n\n\n In your new branch you did some changes to the file, re-added it, commited it with a message thats says clearly what you just did and then pushed it to a new branch (git will complain if you just use push, because there is no upstream branch).
It then created a merge request, which you can view in your browser and merge into your master branch, after you are sure that everything works as expected.
<\/p>\n\n\n\n
That’s basically it. You have a functional gitlab server and a first project to work on.<\/strong>
(automation pipelines and runner-configuration as well as kubernetes connection will be covered in separate posts). <\/p>\n\n\n\n
\n\n\n\nTips:<\/h4>\n\n\n\ngit status\nOn branch testbranch\nYour branch is up to date with 'origin\/testbranch'.\n\nnothing to commit, working tree clean<\/code><\/pre>\n\n\n\nuse this often to be confident about your environment, this command tells you most things you might forget about otherwise.<\/p>\n\n\n\n
source ~\/.git-completion.bash\nPS1='\\[\\033[0;32m\\]\\[\\033[0m\\033[0;32m\\]\\u\\[\\033[0;36m\\]@ \\w\\[\\033[0;32m\\] [$(git branch 2>\/dev\/null | grep \"^*\" | colrm 1 2)\\[\\033[0;32m\\]]\\[\\033[0m\\033[0;32m\\]\\$\\[\\033[0m\\033[0;32m\\]\\[\\033[0m\\]'<\/code><\/pre>\n\n\n\nYou may even install the bash completion for git (e.g. apt-get install bash-completion, then, if installed, enter something like the above in your .bashrc.
After installation you’ll have to manually copy the file from \/usr\/share\/bash-completion\/completions\/git to (e.g.) ~\/.git-completion.bas<\/p>\n\n\n\n
This gives you autocompletion for git commands and a nice command prompt, which always show the branch you are currently in.<\/p>\n\n\n\n
Set up a gitlab runner to build and test your code \/ configs<\/a><\/h4>\n","protected":false},"excerpt":{"rendered":"What is git? Git is a modern distributed revision control system, in a way pretty much like svn (or cvs, rcs), which is centralized. but git is much more powerful, especially when it comes to working with branches.It’s a full blown devops-tool nowadays and besides keeping track of your code, you can configure build- and … <\/p>\n