Git for websites

Linc

I had an outstandingly frustrating experience trying to figure out Git with Eli's (pragtastic) help this weekend. I'm a web developer, not a web server admin, and all the documentation / guides seem to assume that A) you are a linux nerd and B) you already understand version control and/or have used Subversion. I previously spent days trying to set up Subversion on my own and failed in that endeavour as well.

This morning though, Eli sent me a link that may turn the whole thing around: http://joemaller.com/2008/11/25/a-web-focused-git-workflow/

That one looks like it actually makes sense! So now I'll recount how I actually got Git installed on our servers and my Windows box in the hope that one day someone will be saved days of :banghead:


Installing on CentOS 5:
Create these files: http://danielinsley.com/entries/general/installing-git-on-centos-4-6

yum install subversion-perl

(pre-req: http://www.centos.org/modules/newbb/viewtopic.php?forum=18&topic_id=5651&viewmode=flat)

$ yum --enablerepo=dag --enablerepo=atrpms install git

Installing on Red Hat Enterprise 4:
use wget: https://rails.wincent.com/wiki/Installing_Git_1.5.2.3_on_Red_Hat_Enterprise_Linux

Installing client on Windows:
Get msysgit and use the bash: http://code.google.com/p/msysgit/downloads/list


Then, finally, use the Joe Maller guide to actually set up your repositories (and understand how the whole thing works).

I still haven't followed the guide myself, but I have high hopes seeing as how I actually understood that guide and wasn't left scratching my head and doing more Google searches when I was done.

Thrax

You should've called me. I could've got you up and running with SVN in about 2 hours.

Linc

Guh? It never would've occurred to me that you'd heard of version control much less knew how to set it up server-side Why do you know SVN?

Thrax

I do all sorts of inane and off-topic shit at my job.

TiberiusLazarus

Thrax wrote:

I do all sorts of inane and off-topic shit at my job.

i.e. Thrax is into experimentation.

Also, good guide. Nice to have stuff like that listed out in plain steps.

Khaos

Just a general point about version control:

Subversion is, on the whole, a lot simpler than Git.

Git is superior for extremely large projects with thousands of contributors; i.e. the Linux kernel. It diffs various branches and patches better, and each working copy is treated as a separate branch, to painfully simplify the way it works.

Subversion is typically easier to use for smaller projects as it follows a standardized repository model that is easier for most people to comprehend and use. It does just fine for us here at work with roughly ~100 developers working on our particular product in our particular repository.

pragtastic

We found out that Git's ideas about source control vary somewhat from the more traditional SVN. Hopefully that guide can flesh out some of the finer details of Git-based sourcing so you'll actually have a usable work flow with Git.

Khaos

pragtastic wrote:

We found out that Git's ideas about source control vary somewhat from the more traditional SVN. Hopefully that guide can flesh out some of the finer details of Git-based sourcing so you'll actually have a usable work flow with Git.

I would recommend rethinking the decision to use Git. It is really overly complicated for the requirements of KEEBLER and Icrontic.com. The fact that it follows a distributed repository model rather than a consolidated model makes it powerfully unique from almost all other source control tools, but also powerfully confusing -- even to most people who are familiar with source control.

pragtastic

If I would have known that Git followed a different model I would have made the same recommendation.

That being said, he has a decent start with Git currently. Even though SVN is the simpler implementation, it may not be a problem for Keebs since there is no conversion of thought between the systems, but simply learning a system for the first time.

I believe the ultimate decision will come down to the tools and ease of use for Keebs(as far as simply making commits and pushing changes from environment to environment). If Git can do source control w/o being a pain in the ass, go for it, if not think about giving SVN a shot.

Khaos

pragtastic wrote:

That being said, he has a decent start with Git currently. Even though SVN is the simpler implementation, it may not be a problem for Keebs since there is no conversion of thought between the systems, but simply learning a system for the first time.

This is an excellent point. It is even difficult to cross-train people on SVN who are used to VSS or TFS, but it is infinitely easier to train people on SVN when they are starting without any preconceptions about how it works or what it does and doesn't do.

The cross-use / misuse of terminology between the different platforms, especially terms like "Checkout", "Check In" and "Commit" really adds to the confusion. Checkout means two totally different, contradictory things in SVN and VSS/TFS! I absolute hate that when trying to teach somebody how to use SVN when they are used to Microsoft source control products.

With all this in mind, Keebs will probably know more about Git than I do by the end of today.

Good luck, Matt.

Linc

The corollary to my requirements is that I'm going to want to use the same solution at my office, where there is a significant possibility of increased collaboration as time goes on (and of course one day, hopefully, Icrontic won't be a one-man show either).

Also, the trend I'm watching is people migrating from SVN to Git as they are able to, even smaller shops. Seeing as how I'm not really equipped to test multiple solutions, I'm apt to go with the one winning converts among all the developers I follow.

Khaos

I think fad is more appropriate than trend, but I dig.

Linc

OK, I think what I'm going to do is set this up per the guide on the live version of Icrontic, and simply not use Git on the dev server. I'll clone the live to my workstation, and simply put the files to dev as I change them.

Khaos

That doesn't make any sense, Matt. You want your working copy to be source controlled, which would mean installing Git on your workstation. You want your repository source controlled, which means installing Git on the dev box.

The live server is the last place you want source control. The live server is where you push a given version of the site once it is certified for use.

Khaos

Alright, I'm going to make this recommendation one more time:

Instead of setting up Git or SVN on your own, put the source code on a Google Code account which is an HTTP-enabled SVN repository with a spiffy AJAX interface and compatibility with numerous standalone SVN clients and SVN IDE plug-ins.

Then checkout a working copy to your workstation to develop with. Commit all your changes to the Google Code SVN repository.

Push your working copy to the dev box to test, or checkout directly from the dev box using an SVN client (RECOMMENDED).

Push your working copy to the live box to release, or checkout directly from the live box using an SVN client (RECOMMENDED).

This could all be done in about 10 minutes and would completely relieve all the headaches of repository management.

mondi

@Khaos - Setting up subversion isn't difficult, why resort to releasing all IC's code to the public?

Khaos

I was not really suggesting that the Icrontic code be made public; only that Matt use a public repository / project tracking system to manage the site development, which could still be restricted.

But you raise an interesting point.

Why not open up the Icrontic code?

I think it would be a revolutionary step for Icrontic and for tech websites as a whole. The first Open Source tech site.

This would allow the user base to assist Matt in fixing the bugs that crop up, as well as provide a host of project management tools, such as issue tracking, that are quite valuable.

Matt has expressed the desire to open up the development to collaboration. I think putting the PHP (NOT THE ARTWORK) on a project management site like Google Code or SourceForge would be a brilliant step in that direction.

I could totally see myself getting bored one night and whipping together a patch to fix some issue or provide some functionality for Icrontic. Whether it's used or not is entirely at the discretion of the project lead; in this case, Matt.

But now we're into the realm of opinion and random ideas.

My basic premise is not to make Icrontic public. My basic premise is to not take on the burden of repository and project management when there are so many canned solutions available that do all that work for you, and do a better job of it.

Setting up subversion isn't difficult

Aside from the fact that this thread would seem to contradict this statement, I chose my words very carefully when I talked about repository mangement. Setup is one thing. Maintaining the repository with automatic dumps and backups, which should preferably be independent of the site backup, along with updating the SVN server, maintaining HTTP access, user accounts, issue tracking and fixing the repository when it becomes corrupted are all maintenance matters that add development overhead. These are all things that do not help to make the developers more productive, but rather less productive. Not to mention the fact that it is more difficult to get people to collaborate on development using a basic SVN server installation. Git is even more complicated to get people to understand. There is no reason to take all that on. That's what I'm saying.

I commend Matt for learning about setting up repositories. It's a good thing to know. That doesn't make it a good idea as a permanent solution.

---

TL; DR: Overhead is bad, productivity is good, open development is better and I LOVE CHEESE!

Linc

Am I misreading Maller's guide or something? The "prime" version is the working directory copy that you commit after you're sure it's going to work. I'd pull the latest copy from live to my workstation, make all the changes, put it all to dev to test it out, and if it works I push it to the hub on live, then pull it into prime to make it go live.

Linc

Khaos wrote:

Why not open up the Icrontic code?

Security by obscurity. It's entirely possible I've unwittingly left some gaping hole in the bridge, and I'd rather not circle it with a highlighter for anyone who wants to screw with Icrontic. The likelihood of a hole is greater than the likelihood of code getting contributed, IMO.

Another problem is vB's commercial license. I need it in the repository (core hacks ftw), but I can't release the code.

Lastly, our bridge is a competitive advantage that I don't want to cede. It's the glue that makes the community able to flow from the front page to the forum and back again. There aren't any other sites using Wordpress with vBulletin like we are.

While it's entirely possible I'll open source a version of the bridge one day, it shouldn't be the one that's currently in use.

Khaos

Lincoln wrote:

Am I misreading Maller's guide or something? The "prime" version is the working directory copy that you commit after you're sure it's going to work. I'd pull the latest copy from live to my workstation, make all the changes, put it all to dev to test it out, and if it works I push it to the hub on live, then pull it into prime to make it go live.

I don't know who Maller or his guide is, but that's not the typical or recommended model for setting up a repository.

A repository is not just a place for code that is guaranteed to work. You may have tens or even hundreds of revisions in between live revisions.

The repository belongs on the dev server (or an entirely separate location) because each revision is typically something that is testable, but not necessarily releasable. You may commit changes many times in one day. This is normal. Not every committed change belongs anywhere near the live site.

It is not intended that you only commit 100% finished, working code. You should commit on a feature-by-feature basis every time you are ready to test a feature or change. As long as it is reasonably functional, it should be committed. This ensures that work is not lost.

If you change the way you think about using source control, setting this up may make more sense to you.

Khaos

Lincoln wrote:

Security by obscurity.

This is a reasonable point, but the counterpoint is that open policies expose weaknesses that would otherwise remain hidden, and the chance is likely greater of someone with good intentions noticing a weakness faster than the hacker/troublemaker who gives two shits about bringing Icrontic to its knees and cares to sort through thousands of lines of PHP.

What is more secure: *NIX or Windows? One open, the other closed.

Lincoln wrote:

Another problem is vB's commercial license. I need it in the repository (core hacks ftw), but I can't release the code.

This is a big problem that I hadn't given any thought. Closed source for the lose. There are ways around this, though. The core vB code could be stored privately instead of released publicly, with only patch files released to the public (Which is quite common already).

Lincoln wrote:

Lastly, our bridge is a competitive advantage that I don't want to cede. It's the glue that makes the community able to flow from the front page to the forum and back again. There aren't any other sites using Wordpress with vBulletin like we are.

Don't take this the wrong way, but I think you're exaggerating the importance of the site code vs. the importance of the staff, contributors, resulting content and backing community. Instead of guarding the site code as your child, think about this in terms of publicity and reach.

Being a completely open source site would be publicity in its own right.

Providing a useful content management system, even more so.

Rather than being the developer and admin of a smallish tech community site, you'd be the developer and admin of a massively successful, open source project AND a burgeoning tech community that grows off that success.

I don't mean to be pushy, but this is my perspective. The best experience I've EVER had developing was when I maintained a branch / release of eMule that was used by millions of people back in 2003 - 2004. I felt like a king of my own little domain, and a lot of people contributed to my work and we really DID something. It was awesome!

Linc

Khaos wrote:

I don't know who Maller or his guide is

I linked it twice in the OP. It was kinda the basis for this discussion.

The "hub" repository isn't a working directory. It can't possibly screw up live. When I'm ready to take a version live, that's when you pluck a version from hub into the "prime" (live) working directory.

Sure I could stick hub on dev, but why? It just makes it impossible to continue work on the site if dev is down, and it does go down occasionally.

Linc

Khaos wrote:

What is more secure: *NIX or Windows? One open, the other closed.

This is an inapt comparison. They have security experts who care enough to peruse the code. I'm allowed to be a little skittish - Icrontic has been compromised three times, two of which irrevocably nuked the site. I'm not going from Lincoln-only to entire-world in one step. It just ain't happening.

Khaos wrote:

you'd be the developer and admin of a massively successful, open source project AND a burgeoning tech community that grows off that success.

I'd rather that our energy remains focused on generating written content. That, and I don't think I'm in a position to lead an open source project yet.

Khaos

Lincoln wrote:

It just makes it impossible to continue work on the site if dev is down, and it does go down occasionally.

Decoupling site deployment from the repository is one of the driving reasons to host the repository elsewhere. You never want your site backup and repository backup intimately linked, which they would be if the repository is on the live server. I wasn't aware that the dev server is unreliable when I made my recommendation.

My own personal inclination is that it still makes more sense to use a third party, remote host for the repository/project management for all the reasons I've talked about and more. Which one isn't important; I used Google Code as an example because I like the simplicity of their SVN-driven system and the accompanying issue trackers, etc.

@Maller, guide, thread, etc: My points are more general than specific to his guide, and I'm too busy pontificating to read about a subject I already have intimate knowledge of, hence my responding to the posts rather than the guide.

/me chuckles at self in deprecation.

KEEBZ wrote:

This is an inapt comparison. They have security experts who care enough to peruse the code. I'm allowed to be a little skittish - Icrontic has been compromised three times, two of which irrevocably nuked the site. I'm not going from Lincoln-only to entire-world in one step. It just ain't happening.

To the last point, that's fair. Like I said, I'm not trying to be pushy or bully you into anything; just sharing my perspective.

On the point of security, I think it is a *very* apt comparison. Icrontic's potential vulnerability scales down with the scope of the project. I picked an obvious example in *NIX and Windows, but to the underlying point, I would challenge you to find *one* open project where security vulnerabilities have run rampant. There are plenty of mission-critical applications that are developed openly. I can't think of one that has a reputation for being less secure than their closed counterparts; quite the contrary.

Again, risk scales with project size and project exposure. Icrontic is a small, under-exposed project. Risk is thus relatively low. The less publicity given to the repository, the less exposure there would be. The more publicity given, the more exposure there is. More exposure means more risk, but it also means more expert eyes that negate that risk. The open model is truly well tested and it scales nicely from the smallest projects to the most prolific!

On this same point of exposure, you indicated that you are uncomfortable running an open source project. The beauty of it is that there are millions of open source projects, and if you don't sound the horn about your own little project, it will remain lost in obscurity indefinitely. It can be as big or as small as you want.

I say it is never too early to get your feet wet in open development. For any developer, it stands to be an exciting and liberating experience to share your work with others and learn from their contributions and feedback. If you're serious about your work, I can't think of a better opportunity to jump in.