Whether you a new to software development of a relic of the early Dilbert era of developers version control has been around in some form or another since the early days of programming in the 1970’s. Granted programming existed prior to 1970 but what happened on punch cards is really not relevant to this discussion. What really matters is the pervasiveness of today’s open source projects and the need of programming teams to collaborate between iterations.
Without version control the task of deploying code releases becomes difficult and is multiplied exponentially by the complexity of the project. While there are hold outs who do not believe in version control feeling that it adds to many layers between them and the final result. The big whiny argument I almost always hear from these types is if there’s a bug I can just remote in or ftp the patches and it’s fixed faster than if I have to checkout the code from the repository fix it and then recommit it for a release (commonly called a push by the way). To those naysayers out there I say;
If you work for me you use version control.
With that out of the way let’s get down to business. It seems that in the 1990’s and early 2000’s everyone and their brother was on the subversion bandwagon but today it’s all about Git. For the rest of this article I shall continue with the assumption that you are at least familiar with these two. If you have not done so already install git using the ports /usr/port/devel/git
.
After installing git create a git user complete with a secure password. Remember that we really do not care what the password actually is because when we are done the user will not be allowed shell access so this is a temporary safety measure so that something unexpected does not happen while we get things going. For the time being make keep it simple.
# pw user add git -m -s /usr/local/bin/bash
# passwd git
At this point you will have a new basic user with a home directory created from the default skeleton which lacks the necessary .ssh resource directory. The following commands will setup the directory with the appropriate permissions necessary to support key based authentication.
# mkdir -p /home/git/.ssh
# cat ~/.ssh/id_rsa.pub >/home/git/.ssh/authorized_keys
# chown -R git:git /home/git/.ssh
# chmod 0700 /home/git/.ssh
# chmod 0600 /home/git/.ssh/authorized_keys
If you need to add more than one key to the authorized_keys files remember to change the pipe to >> so that you do not clobber the existing ones stored inside. Trust me these sorts of silly faux pas happen and without the original in version control or a local backup you’d be stuck recreating these the hard way.
We are almost ready to start the server. The first step is to enable the server in the rc.conf. Observe the proper >> pipe once again if you fail to use the correct pipe you would likely blast your rc.conf which with out a back would make for a RGE1.
# sudo echo 'git_daemon_enable="YES"' >> /etc/rc.conf
# /usr/local/etc/rc.d/git_daemon start
Now the repository fun can begin. In order to start pushing projects into the server we need to setup a directory inside our home tree to hold them. Remember that password I said we didn’t really need well this is when you need it.
# su git
# cd /home/git/
# mkdir Projects
# cd Projects
# git init --bare --shared
Honestly that is all there is to it. You can call you repo tree anything you like as you can see I prefer Projects. You may see other examples in different tutorials with a .git suffix personally I find this convention rather superfluous as we are inside the git user’s home directory which seems fairly specific already. To each their own.
For the next part of the tutorial return to your local machine and create a new project. In this project we will put the latest WordPress core for future development projects.
# mkdir -p dev
# curl -L -O http://wordpress.org/latest.tar.gz
# cd dev
# git init
# git remote add origin git@SERVER_NAME:/home/git/Projects
# tar xzf ../latest.tar.gz
# git add .
Note that if you forget to commit or fail to place any content in the newly initialized project folder then you will receive the following error when you attempt your first push:
error: src refspec master does not match any.
error: failed to push some refs to 'git@SERVER_NAME
:/home/git/Projects'
If all went according to plan then when you make the first commit as follows you will see a notice similar to this one followed by a stream of all the files in the WordPres core bundle being added to your new project;
# git commit -m 'original base commit'
[master (root-commit) 05a751d] origin commit
1053 files changed, 296919 insertions(+), 0 deletions(-)
Finally we are able to execute the push to the server.
# git push origin master
Counting objects: 1153, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (1123/1123), done.
Writing objects: 100% (1153/1153), 4.01 MiB | 183 KiB/s, done.
Total 1153 (delta 63), reused 0 (delta 0)
To git@SERVER_NAME:/home/git/Projects
* [new branch] master -> master
Honestly, that is all there is to it. If you got lost or encountered errors double check for typos and missing quotes around those parameters.
note 1: RGE stands for Resume Generating Event this sort of exception occurs when you carelessly cause service outages.
Leave a Reply