• Published on | Feb 20, 2013 | by Chris Osborn

Hey Git, Designers Aren't Programmers!

We've been using SVN for a long time for managing web sites we develop. I built a custom web front-end to SVN called SiteMgr so that all the designers and programmers have an easy way to do updates and commits, push things to the live site, and work from multiple branches. It also includes an easy way to look at old revisions of specific files by just choosing from a pulldown list.

Because we develop our websites using MVC methodology, we keep the server side program separate from the HTML. On our team there's several people that will be working on the HTML, but only one that will be making changes to the server side logic and database.

With SVN this was fairly easy to deal with because I put an option in SiteMgr to allow the HTML people to checkout only the HTML folder. This works great because they don't have to see a bunch of files they're not interested in, they don't need to learn how to compile the program, and there's no danger of them accidentally modifying or deleting a file they shouldn't mess with.

All of the people who are working on the HTML only use the "live" version of the branch's program, model, and configuration. If they find a bug in the program the programmer can test it on his own copy then push it up to live and all the designers will immediately see the fix. Once or twice we've tried letting the designers checkout everything, and it's just made things harder and more confusing. When the programmer fixes bugs the designers then had to do an update and a compile, which they often would forget and they would get out of sync.

I'd like to switch over to git, the biggest reason being it would allow everyone to do a commit at the end of the day without having to worry that they are committing things that are broken. Right now with SVN often our designer will be working on his own for several days without doing a commit because he has so many broken things and he doesn't want to have them end up in everyone else's work. Often after going that long he'll decide he went down the wrong path and wants to look at something he did several days earlier and it's a real hassle to go dig it off a backup.

Another advantage I can see to git is it will make it easier for everyone to create a branch just to try something out. Hopefully merging will be easier than it is with SVN.

Unfortunately git doesn't seem to support a way of checking out subfolders only. We have a good workflow with the way things are now and I hate to have to retrain everyone and add a lot of extra steps that to them will really have no benefit. I'm still trying to think of a good workaround.

Join The Discussion

+1  Posted by John • Feb.24.2013 at 23.00 • Reply

Have you looked into submodules with git?

+1  Posted by Chris Osborn • Feb.25.2013 at 11.27 • Reply

From everything I read it seems like submodules create more problems than they solve.

+1  Posted by John • Feb.24.2013 at 23.14 • Reply

Hey Chris,

This is John's son, Aaron. I'm a Senior Engineer at a company down in San Diego, and my i thought I'd try and help point you in the right direction with git.

At our office, we have about 20 programmers/designers, all of which have access to both the backend and frontend of each of our projects.  The way we deal with "toe stepping", and accidental modifications and deletions is actually relatively easy, and is the way most big git projects work. From the start, you should have one master and develop branch that only one or two people have access to pushing changes to, and then everyone else on the project, should have their own fork of the repository. When everyone has his or her fork set up, all they need to do it check out new "feature" branches off of the origin's develop branch.  With this, it solves the problem you posed in the 4th paragraph. If a developer wants to go and work on something different, they just need to checkout back to develop from the feature branch, and then cut a new feature branch. And when their code is super far behind, all they need to do, is pull from the remote upstream to get recent changes. This can  even be done on a crontab script that runs hourly (or whenever). 

Back to the main repository's master and develop branches...  Whenever you want to get code from one of the people's forks, they submit a pull request to the upstream's develop branch. From here, one of the people who has access to the main develop branch would have to review the pull request and make sure there are no edits to core files that shouldn't be edited. This can also be pretty easily tied into a build server like Jenkins CI to make sure that when the pull is done, the site still functions the right way. After that is done, and the owner of the develop branch merges the pull request, everyone can pull changes again to get that developers code. 

All in all, having used SVN before, i would BEG you to get off of SVN as fast as possible, because it will save you a ton of headaches. The merge process is a lot easier, it provides more insite into  code that has been committed in the past, and code that is ready to go live. 

If you've got any more questions about git, feel free to send me an email: aaron at sdphp dot org

+1  Posted by Chris Osborn • Feb.25.2013 at 11.30 • Reply

Wow that just sounds like a really complicated setup. Maybe if you have that many people you might want to do a lot of review but here that would just slow everything down. With everything checked into a version control system if there's a really big error it can always be backed out.

+1  Posted by matt • Mar.05.2013 at 13.38 • Reply

Just submodule your HTML / public folder and only give designers commit access to that.

+1  Posted by dave • Mar.07.2013 at 09.41 • Reply

what about sparse checkouts? I believe what this post describes is what you are looking for: http://blog.quilitz.de/2010/03/checkout-sub-directories-in-git-sparse-checkouts/

+1  Posted by Lewis Cowles • Aug.16.2014 at 12.34 • Reply

fake the functionality!, if it wont work out of the box, allow for a database with project id, role_id and path, simply git to a folder (step1), then copy from the paths specified + subdirs etc into another folder. voila. The other thing you can do with Git is actually maintain two separate branches and just merge back to main after the designers commit, also a voila!