The interface surely looks familiar to you GitHub users out there! It’s quite slick and modern-looking compared to the clunkier interface of Gitweb, Git’s default Web frontend, and it comes packed with user-friendly features. Some of these include:
Support for browsing multiple repositories Multiple branch and tag support RSS feeds Syntax highlighting Statistics on your repositories Ease of installation compared to other Web-based Git frontends
Requirements
As we mentioned earlier, you can install GitList on some shared Web hosting plans. You do need a couple of things on your remote server that not all shared hosting plans offer:
Git SSH access
Note that SSH access is not required to install GitList itself, but you will need it to create and manage your remote Git repositories from the command line. In addition to those two items, you’ll need:
Apache with mod_rewrite enabled or Nginx on your remote server PHP 5.3.3 on your remote server Git on your local machine
Installation
Grab a tarball of the GitList code from the main page on GitList.org. You can choose between the latest stable release, which at the time of this writing is 0.3, or the development build. I chose the development build, but you can follow the same installation instructions in either case. Extract the tarball into the directory on your site to which you want to install GitList – not to be confused with the directory your actual Git repositories are installed in, which we’ll get to in a little bit. From now on, the instructions in this article will assume that you are logged in to your site via SSH. Enter your GitList directory and set 777 permissions to the “cache” subdirectory (create it if it doesn’t already exist): Now move the file config.ini-example to config.ini: Open config.ini for editing in one of the text editors available on your remote server. For example: For this part, you must already have one or more Git repositories stored somewhere on your server. If you don’t, read the next section and then come back here. Fill out the repositories section in the code with the full path of your Git project directory. If you don’t know the full path, you can cd into that directory and enter pwd; the output is the full path. In this case, my Git projects directory was called “gitprojects,” and it lived under the “git” subdirectory of my main site, so I typed in my path accordingly (folder structure may vary across Web hosts, so be cautious):
Getting a Git Repository onto Your Server
Go ahead and skip this section if you have already set up your remote repositories. If not, here’s one way to do it. First prepare a Git repository on your local machine. You can make a repository from any directory. For example, let’s say you have a folder called “turtles” with a few files in it: Now SSH into your remote server to create and initialize a bare repository: Return to your local machine and add a remote branch. It is customary to call it “origin,” but you can use whatever name you wish (using other names comes in handy if you are sharing the same files with multiple remote repositories). Follow the format of this example but change your file paths appropriately: Now push your files to the remote server: Ta-da! You now have a remote copy of your Git repository that you can browse with GitList. Don’t forget to put the parent directory’s path into your config.ini first.
Securing Your Repository
If you’re concerned about keeping your repository away from prying eyes, I regret to tell you that GitList provides no built-in user authentication method. However, in most cases you can password-protect a directory straight from your website’s control panel. In cPanel, it’s right here in the “Security” section:
Alternatively, you can manually configure the Apache server to restrict access to particular users.
Conclusion
Hosting your own repositories can be both empowering and budget-saving. Whether you’ve been using Git for a while or you’re in the beginning stages of curiosity about how you can benefit from version control, I urge you to give self-hosting and GitList a try – unless, of course, you’re totally content leaving the control of your content up to third parties.
