Thinking through Git in my work

This is mostly me thinking through some issues.

I use git and GitHub a fair amount. Not enough, not deeply enough, but a fair amount.

I understand Use Case #1, Compiled App, like RLangSyntax:

• code in ~/dev/Project
• subdirs (test/, lib/, examples/, docs/, etc) and documentation, license and build scripts in to git
• git push origin master
• compile code to binary, deploy the binary elsewhere (like GitHub's releases tab)

When someone wants to use this code, git clone Project gets you all you need to build it, except for compilers and associated libraries, which should be in README.md. (I forgot to put how to build into the RLangSyntax docs, then forgot how to build RLangSyntax. Forgive me, Admin, for I have sinned.)

Let's jump to Use Case #2, Perl Library, like Spark.pm.

• code in ~/dev/Project
• no build instructions; it's built
• tests in ~/dev/Project/t/spark.t and the like (which this doesn't have, to my shame)
• git push origin master

This is where I get confused. Eventually, this code needs to be in /production/lib, but you don't want to deploy using git pull or git clone, because you don't want /production/lib/Project/. Or, maybe you do and I just don't get it. Still, this is a case that I can do an acceptably wrong thing as required.

Use Case #3 is Perl command-line tools. We'll take on my twitter tool.

• code in ~/dev/project
• git push origin master

This begs about the same question as Perl Library. It could work to have ~production/bin/twitter.pl/twitter.pl, but then you have to expand your path to include every little thing. It gets more involved if you have libraries with executables in the repo, or the reverse, but let's get to the real hairball.

Use Case #4, the Hairball, is our web stuff.

• ~web/ - document root
• ~web/data - holds data that we want to make web-accessable
• ~web/images - images for page headers and other universal things
• ~web/lib - all our JavaScript
• ~web/css - all our Cascading Style Sheets
• ~web/cgi-bin - our server-side code

So, we might have the server-side code in ~web/cgi-bin/service/Project/foo.cgi, the client-side code in ~web/lib/Project/foo.js but maybe in ~web/lib/foo.js, the style in ~web/css/project.css and ~/web/css/service.css, and of course the libraries in ~production/lib/.

Maybe the key is to think of the ~web/lib and ~web/css as variations of Use Case #2, but the problem is that a lot of my JS code isn't general like the Perl code. I mean, wherever you want a sparkline, you can use Spark.pm, but the client code for ~/cgi-bin/service/Project/foo.cgi is going to mostly be very specific to foo.cgi except for the jQuery, Mustache and a few other things that are in use across services and projects.

A possible solution, having things be in ~web/service, with the JSON APIs in ~web/cgi-bin/service/apis and the JavaScript in either ~web/service/lib or ~/web/lib depending on how universal it is, but we lose certain abilities. I certainly have written CGI code which mostly puts out as little HTML as it needs to get the JS, which works for the small audience those tools need.

I mostly code foo.js in relation to foo.cgi or foo.html, but making tests and breaking it into pieces may keep me from having KLOC-size libraries I hate to work on in the future.

And here, we have departed from git into project and web architecture, and into best practices. Still, any suggestions would be gladly accepted.