Share your knowledge at the LQ Wiki.
Go Back > Forums > Linux Forums > Linux - Software
User Name
Linux - Software This forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.


  Search this Thread
Old 08-06-2014, 09:05 PM   #1
Registered: Oct 2003
Location: Canada
Posts: 924

Rep: Reputation: 61
Cool Get Git to manage a website?

Hey LQ,

I'm curious about using git to manage updates of a website.

First, let me explain my situation. I'll be as "quick to the point" as possible.

I am the main coder of a website, I work with one web designer once in a while. Our website is currently divided up into 4 subdomains, each with their own mysql databases.

1. www. is the live public access site
2. dev. is where I write new code and features
3. design. is where the designer writes new css or images
4. live-test. is where we test out our updates

I have written a small collection of web based tools in PHP that allow me to compare the differences between the subdomains. This helps me see what files are new or updated in comparison to the other subdomains. These tools also allow me to quickly put new files, or new versions of files on the other domains, or completely mirror one subdomain to the other. These updates tools also allow me to quickly mirror one database from one subdomain to the other.

My tools no longer work because they make extensive use of the exec() function in PHP. The exec() function allows an executing PHP script to run a native linux program and then receive the output from the command. We have just switch server hosts, and our new host will not permit us to use exec() due to security concerns.

So that's why we are now considering git to manage the update process. Can git provide me the same functionality as my web based tools and how would I even begin to set this up?.

Here is what I'm thinking I'd have to do to set this up. Please correct me if I'm wrong.

1. Install git on my machine
2. Install mysql and apache + php on my machine
3. Download our website and database onto my computer.
4. Turn the webroot and sqlroot into git repositories
5. Install git on the webserver
6. Get webserver to checkout the website and database from my machine.
7. Get designer to install git on his Mac and get him to checkout the site

Now for updating the website, it would go something like this.

1. The designer would commit his changes to my machine.
2. I checkout the new latest version with his changes.
3. I make my changes to the website, and commit them.
3. Get webserver to check out new version of the website.

To me this all seems a bit cumbersome for just managing a website so I'm confident I must understand the process incorrectly. I'm also curious how git would manage different databases and how it could compare the differences. Also curious what happens if I and the designer each work on the same file and both have valid changes that need to be committed. I'm assuming we can only alter one file at a time.

I know this thread is getting long! So I'll wrap it up here and say thank you kindly for reading through and hopefully responding.
Old 08-06-2014, 09:28 PM   #2
LQ Guru
Registered: Feb 2004
Location: SE Tennessee, USA
Distribution: Gentoo, LFS
Posts: 10,755
Blog Entries: 4

Rep: Reputation: 3966Reputation: 3966Reputation: 3966Reputation: 3966Reputation: 3966Reputation: 3966Reputation: 3966Reputation: 3966Reputation: 3966Reputation: 3966Reputation: 3966
Basically, I suggest that you "park" this slew of questions for a time and do some study ... such as reading the online Git Book as well as other more basic texts about the general subject of change-control and release-management. You need to step back from the forest, fly over it, and simply "get the big picture."

And as for your essential question: I would never manage a web-site, nor anything else, without using change-control and release management! Be it "git" (my hands-dwon favorite) or something else.

The basic workflow that you (and your designer) would use, with "git," for all sites, goes something like this:

(1) You set up a git-repository and maybe an issue-tracking system in a secure but accessible place. (I use "" repeatedly, but there are many.) Every git repository stands alone, but this accessible copy will always be available to everyone on the project.

(2) You maintain a series of "branches," including "release" (say with branches for each server), "development," "experimental," "new features," "bug fixes," and so on. (Each one tied to a ticket.)

(3) Each time you, he, or anyone else, starts to make a change, you first "check out the proper branch," then "make a new branch" (not yet and maybe-never "pushed" to anyone else) to contain your new set of changes. You make the change, review it, commit it. ("Commit" is cheap and free, and it simply represents a place that you can now unerringly "revert" to.) If the change passes QA, it eventually gets "merged" into, say, the "development" branch. Perhaps you drop a "tag" to mark this place.

Well, maybe you get the idea – and if not, once you read the books and so-on, you will. These branches are "states of the source-code." One of them corresponds to the set of code that "server-X" should be running right now. (And, marching along behind, you will find every other version that this same server has ever run.) To update the server, you simply "pull the repository, then check-out the proper branch." And, to recover from , you simply check-out an earlier (tagged ...) version from the same branch.

" someone hacked your server!" No problem. The repository on that server can always be replaced (since ... "every repository stands alone!") and a new version can be checked-out, and 'git' will automagically deal with the rest.

Last edited by sundialsvcs; 08-06-2014 at 09:30 PM.
Old 08-06-2014, 11:15 PM   #3
Registered: Oct 2003
Location: Canada
Posts: 924

Original Poster
Rep: Reputation: 61
Thanks for clarifying that.

From what you've said, and what I've read of the Git book online, Git is feature and complexity overkill for our current development process. We don't have or require experimental branches of code, we use our subdomains and automatic backups rather. The designer I work with, and all of the designers I've worked with in the past do not even come close to possessing the required proficiency to make sufficient use of Git, is that common place where you live and work?

It seems pretty rare for small websites to use Git as well, however I'm continuing my research of it still. I have an email to a guy at the datacenter to ask if we can have Git installed on the server. I'm guessing if he doesn't allow me to access exec() like functions of PHP he won't allow me to install software of my choice either.
Old 08-07-2014, 08:51 AM   #4
LQ Guru
Registered: Feb 2004
Location: SE Tennessee, USA
Distribution: Gentoo, LFS
Posts: 10,755
Blog Entries: 4

Rep: Reputation: 3966Reputation: 3966Reputation: 3966Reputation: 3966Reputation: 3966Reputation: 3966Reputation: 3966Reputation: 3966Reputation: 3966Reputation: 3966Reputation: 3966
I politely say to you, wh33t, that your assessment on this point is "quite incorrect."

Yes, git is "something to learn," but you don't have to learn much about it ... not at all ... to start reaping its critical benefits.
  • Set up a repository (directory ...) on your machine, run git init, point git at it.
  • Go to your development directory. Create a branch devel, and commit all your files as-is to it.
  • Just proceed as you normally do. Then, a day or so from now, try git status. Whether you realized it or not, that list contains every file that you've changed! Wanna see what those changes are, guaranteed? It's right there.
  • If you reach "a stopping point," try another git commit. Presto: now, both stopping-points are captured, forever.
Even if it is "only you," it becomes something that you wonder how you ever lived without.

Meanwhile, go over to development, check-out (switch to) a new branch, and commit those files too. Then, switch right back to development.

Okay, one more thing. Something seems bonkers about a file that shouldn't have been changed. You're sure it shouldn't be the way it is! But, who's to git blame? Oh... there it is... I see that it got changed at "09:23:18PM on X/Y/Z,"
and here is exactly what the source-code looked like, before and after. Well, I want to undo that change, to revert the file. (Click, click, click.) <<A few days pass.>> "Oh, sh*t, I was such a dolt!" Now I remember why that change was made, and it was correct! How do I "un-do undoing it?" (Answer: click, click, click. The un-do is now undone. Perfectly. Immediately. Guaranteed.)

Meanwhile, your colleagues look somewhat bemusedly at the change-logs for that file. They see the original commit, and the new commit that reversed it, and the other new commit that reapplied the changes that got reversed. They see the exact details of every change because every commit is always going forward.

Yeah, there's a lot of voodoo in git, which is only needed for the largest of projects. But, even when I am doing work that has nothing to do with programming and soure-code, I am using change-control.

Pretty soon, you're checking out new branches almost every day, committing to them just before you take a break before going on to the next part, merging them in, and you treat this like making sure that the safety-net is always right there beneath you and always tightly secured, because you remember that you have fallen into the thing, and what a good feeling it is to be rewarded with "a springy bounce."

There have been many times where it was just a little too late at night, or my cat walked across the keyboard, and something happened that would be: " ." But it wasn't. It was " ."

Last edited by sundialsvcs; 08-07-2014 at 08:56 AM.
1 members found this post helpful.
Old 08-07-2014, 10:35 AM   #5
Senior Member
Registered: Dec 2003
Location: Trondheim, Norway
Distribution: Debian and Ubuntu
Posts: 1,454

Rep: Reputation: 448Reputation: 448Reputation: 448Reputation: 448Reputation: 448

I've also been using git for many projects and I recommend it. For small projects we use it a bit simpler, and we don't use git on the production servers. Basically it works like this:

We have one central repository (you need ssh access to use it)

Each developer/designer gets a copy of the entire site with git. It can run on a laptop or test server, it doesn't matter. The point is everybody gets a copy of everything.

The database and some directories are not in git - for the database, only the structure is in git, and we keep an update.sql to put changes in the database structure. For data, we have 2 directories, one inside htdocs (DocumentRoot) and one paralell to it. Those 2 directories have write permissions and in the Apache config we prevent running PHP scripts there as a security measure. The point is you sometimes want to write files with PHP, not everything belongs in the database. They are both in .gitignore.

We can all pretty much change whatever we want. When things are semi-stable we do git commit and git push.

Then we have a "beta" or staging instance. We upgrade this by doing git pull and "mysql -f < update.sql" so new columns and tables are added. And after upgrading the beta, we have other people test it. If bugs are found, we fix them on a development version, push and pull again. When things are good, we upgrade the live server with rsync from the beta. One neat thing about rsync is that you can use the .gitignore file to exclude files, so the data directories are not copied.

For a small project, we usually never do any branching. It still has many advantages. Usually it will merge fine. But sometimes we get conflicts when people change the same file. It's usually very easy to fix, and usually update.sql. If 2 people both add to the end of the file, we get a conflict. We solve it by having some comments marking a start end finish section for each developer. Then the merging works fine.

Also it's good to put everything in git, not just code. All kinds of things a website needs belong in git - like CSS, images, .htaccess files and so on. The only thing that should not be in git is "data".

One more thing that's important. We have a seperate test server holding the git repository and the beta. Everybody can change everything on it. But the live server is a different one. To upgrade the live server, we need a long password we have in a book. It's not because we don't trust the developers and designers. It's because we don't trust everybody to never lose their passwords. And even if a password is lost, they can't get to the live server.

Last edited by Guttorm; 08-07-2014 at 12:11 PM.


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off

Similar Threads
Thread Thread Starter Forum Replies Last Post
LXer: Debian Wheezy Local Git Server With Git Lite Workflow LXer Syndicated Linux News 0 01-20-2013 01:30 PM
[SOLVED] Can't install Git repo (I don't git git ) Nemus Linux - Software 3 05-20-2011 02:09 PM
LXer: Weekend Project: Using git to Manage Config Files LXer Syndicated Linux News 0 04-17-2011 02:50 PM
inconsistency issue of git-clone ***/git/mesa/drm with the existing kernel source centguy Linux - Desktop 2 10-08-2008 10:36 PM
LXer: Manage Source Code and Linux Kernal Revision Using Git LXer Syndicated Linux News 0 07-01-2006 08:54 AM > Forums > Linux Forums > Linux - Software

All times are GMT -5. The time now is 09:27 PM.

Main Menu
Write for LQ is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration