git for pushing local subdir to website

git for pushing local subdir to website

[Matt Di Pasquale]

I made a post here about this here:
http://stackoverflow.com/questions/600079/is-there-any-way-to-clone-a-git-repositorys-sub-directory-only/1223407#1223407

Basically, I'm working alone on a website (well, it's a facebook
app.). What's the best way to sync my local copy with my production?
but i want the production to only be linked with the production subdir
of my local project.

so, I have a local copy i'm working on that I've organized like so.
call the project example. here are the dirs on my local comp. macbook.

example -extra [this holds files i don't want to go to the webserver
mainly for security reasons. files like .psd files or .sql files. or
readme files. etc.] -example.com [this dir holds all the files i want
on my server for production at http://example.com]

i have local git repo here: example/.git

now... how do i just push example.com and not extra and example.com?

do i need to make another git repo in example.com and make example.com
a submodule?

i've also thought about using branches... a local branch and a
production branch. but i only want one copy of the production files.
because i want to be able to check out all the files and zip the dir
and send it to someone to see.

that doesn't really make sense conceptually because example is one big
project. extra is like extra files and example.com is like what i
really want to go on web server...

thanks!

-matt

Re: git for pushing local subdir to website

[Wesley J. Landaker]

[-- Attachment #1: Type: text/plain, Size: 518 bytes --]

On Monday 03 August 2009 11:11:13 Matt Di Pasquale wrote:
> now... how do i just push example.com and not extra and example.com?
[...]
> that doesn't really make sense conceptually because example is one big
> project. extra is like extra files and example.com is like what i
> really want to go on web server...

There are several ways to do this with git, but since you are not going to 
make commits on the server itself, have you considered simply pushing the 
production files you want with e.g. rsync?

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: git for pushing local subdir to website

[Matt Di Pasquale]

yes... i've thought of that. that's a good idea. i just love git and
i've never really used rsync. how do i do that?
i'll go google it..
i guess it would also be nice to use git though incase i decide i want
a collaborator, right?
how would u set it up?
-matt

On Mon, Aug 3, 2009 at 2:01 PM, Wesley J. Landaker<wjl@icecavern.net> wrote:
> On Monday 03 August 2009 11:11:13 Matt Di Pasquale wrote:
>> now... how do i just push example.com and not extra and example.com?
> [...]
>> that doesn't really make sense conceptually because example is one big
>> project. extra is like extra files and example.com is like what i
>> really want to go on web server...
>
> There are several ways to do this with git, but since you are not going to
> make commits on the server itself, have you considered simply pushing the
> production files you want with e.g. rsync?
>

Re: git for pushing local subdir to website

[Wesley J. Landaker]

[-- Attachment #1: Type: text/plain, Size: 2945 bytes --]

On Monday 03 August 2009 12:09:26 Matt Di Pasquale wrote:
> yes... i've thought of that. that's a good idea. i just love git and
> i've never really used rsync. how do i do that?
> i'll go google it..

Rsync can do a lot of things, but the usual easy way to do it is to do 
something like this to send files via rsync over an ssh connection:

rsync -av /some_dir/ user@host:/some_dir/

This is essentially the same as using scp, but rsync saves a lot of network 
bandwidth by only sending the changes between the source and destination.

> i guess it would also be nice to use git though incase i decide i want
> a collaborator, right?

Setting things up to have a collaboration is kind of orthogonal to 
installing a production version of your app, but you could use the same 
server (and possibly the same git repository) for both things if you wanted 
to.

Here an example of one way to do it:

On the server you could have a normal git repository in, say, 
/home/me/myapp, and it always has the "production" branch checked out. So 
now the following directories are interesting:

/home/me/myapp              -- repository branch w/ "production" checked out
/home/me/myapp/.git         -- the actual bare git repository
/home/me/myapp/example.com/ -- the files that the web server should see

Now, you can use symlinks (or web-server configuration) to point the 
webserver to the right locations, for example:

http://example.com/myapp/     -- link to /home/me/myapp/example.com/
http://example.com/myapp.git/ -- link to /home/me/myapp/.git/

Now, collaborators can pull from the http://example.com/myapp.git and get 
the whole project, but access to http://example.com/myapp/ sees the 
example.com subdir as it's root, and everything works normally (assuming 
webserver configuration & permissions are correct).

Now you work on whatever branches you want, and push to the server whenever 
you want for collaboration using whatever branches you want. As far as the 
webserver is concerned, nothing changes when you do a push.

Then, when you are ready to change the website, you put your production 
changes on the "production" branch, push them, and make sure they are 
checked out on the server (git push doesn't automatically check out the 
files), e.g.:

client$ # just made changes in production branch and want them "live"
client$ git push

server$ cd /home/me/myapp
server$ git reset --hard

> how would u set it up?

Personally, I might set something like this if I had a good reason, but 
otherwise, I'd host my git repository for collaboration separately, and just 
use rsync to install production files on the server. For one thing, that 
needs less prerequisites and setup on the server, so it's good if you don't 
fully control the server.

Either way, a "production" branch is a good idea so you know logically 
exactly what and when you released things live.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: git for pushing local subdir to website

[Matt Di Pasquale]

wow. thanks. that gave me some good ideas.
i think u were right about rsync. it was pretty easy to set up.
assuming the name of my app is myapp, i just put the following alias
in my ~/.bash_profile on my local machine.

alias mapush='rsync -e ssh -av --exclude=".DS_Store"
~/Projects/myapp/myapp.com/
matt@mattdipasquale.com:projects/myapp.com/'

btw, is there a way to make aliases that are local to certain
directories? like typing mapush works from any directory. what if i
just wanted the alias to be push and only work from within
~/Projects/myapp? is that possible?

those aren't the actual paths i used. but u get the point.
then i just type mapush and it does it.

and i just use a local git repository in ~/Projects/myapp/.git to
track local changes since none are made on the server... so i don't
need a git repo there like u said...

it's pretty fast. but will rsync be okay if i decide to move files
around a bit? i know git is pretty good about that. and what if i
delete certain files? will rsync delete them... like git does? guess
i'll figure those questions out in time.

thanks!

-matt


On Mon, Aug 3, 2009 at 2:58 PM, Wesley J. Landaker<wjl@icecavern.net> wrote:
> On Monday 03 August 2009 12:09:26 Matt Di Pasquale wrote:
>> yes... i've thought of that. that's a good idea. i just love git and
>> i've never really used rsync. how do i do that?
>> i'll go google it..
>
> Rsync can do a lot of things, but the usual easy way to do it is to do
> something like this to send files via rsync over an ssh connection:
>
> rsync -av /some_dir/ user@host:/some_dir/
>
> This is essentially the same as using scp, but rsync saves a lot of network
> bandwidth by only sending the changes between the source and destination.
>
>> i guess it would also be nice to use git though incase i decide i want
>> a collaborator, right?
>
> Setting things up to have a collaboration is kind of orthogonal to
> installing a production version of your app, but you could use the same
> server (and possibly the same git repository) for both things if you wanted
> to.
>
> Here an example of one way to do it:
>
> On the server you could have a normal git repository in, say,
> /home/me/myapp, and it always has the "production" branch checked out. So
> now the following directories are interesting:
>
> /home/me/myapp              -- repository branch w/ "production" checked out
> /home/me/myapp/.git         -- the actual bare git repository
> /home/me/myapp/example.com/ -- the files that the web server should see
>
> Now, you can use symlinks (or web-server configuration) to point the
> webserver to the right locations, for example:
>
> http://example.com/myapp/     -- link to /home/me/myapp/example.com/
> http://example.com/myapp.git/ -- link to /home/me/myapp/.git/
>
> Now, collaborators can pull from the http://example.com/myapp.git and get
> the whole project, but access to http://example.com/myapp/ sees the
> example.com subdir as it's root, and everything works normally (assuming
> webserver configuration & permissions are correct).
>
> Now you work on whatever branches you want, and push to the server whenever
> you want for collaboration using whatever branches you want. As far as the
> webserver is concerned, nothing changes when you do a push.
>
> Then, when you are ready to change the website, you put your production
> changes on the "production" branch, push them, and make sure they are
> checked out on the server (git push doesn't automatically check out the
> files), e.g.:
>
> client$ # just made changes in production branch and want them "live"
> client$ git push
>
> server$ cd /home/me/myapp
> server$ git reset --hard
>
>> how would u set it up?
>
> Personally, I might set something like this if I had a good reason, but
> otherwise, I'd host my git repository for collaboration separately, and just
> use rsync to install production files on the server. For one thing, that
> needs less prerequisites and setup on the server, so it's good if you don't
> fully control the server.
>
> Either way, a "production" branch is a good idea so you know logically
> exactly what and when you released things live.
>

Re: git for pushing local subdir to website

[Wesley J. Landaker]

[-- Attachment #1: Type: text/plain, Size: 2270 bytes --]

On Monday 03 August 2009 13:13:43 Matt Di Pasquale wrote:
> wow. thanks. that gave me some good ideas.
> i think u were right about rsync. it was pretty easy to set up.
> assuming the name of my app is myapp, i just put the following alias
> in my ~/.bash_profile on my local machine.
>
> alias mapush='rsync -e ssh -av --exclude=".DS_Store"
> ~/Projects/myapp/myapp.com/
> matt@mattdipasquale.com:projects/myapp.com/'

Okay, looks like you've got rsync figured out!

> btw, is there a way to make aliases that are local to certain
> directories? like typing mapush works from any directory. what if i
> just wanted the alias to be push and only work from within
> ~/Projects/myapp? is that possible?

The typical way to do this is to make a "bin" or "scripts" subdirectory of 
your project, then make a shell script and call it via ./bin/push or 
./scripts/push or whatever. You can also do pretty much anything by using 
shell functions instead of aliases. They work just like shell aliases but 
are defined differently (man bash, then search for FUNCTIONS).

Since the topic is git, I should also mention that you can also set up 
repository hooks that make things happen when triggered, e.g. automatically 
rsync to the server when you commit to "production" for example. Do a man 
githooks for more info on that.

> it's pretty fast. but will rsync be okay if i decide to move files
> around a bit? i know git is pretty good about that. and what if i
> delete certain files? will rsync delete them... like git does? guess
> i'll figure those questions out in time.

Rsync will not delete anything unless you add "--delete". If you use that, 
you probably also want "--delete-after" for a website, which makes sure that 
deletes are only done after everything else is copied over. The default is 
the same as "--delete-before", which does deletes before copying things 
(e.g. to save disk space).

As far as raw network transfer performance, git and rsync are probably 
pretty comparible, as they both are passing just changes instead of complete 
files around. Obviously they work very differently internally so e.g. I 
imagine that git will perform much better in some cases because it tracks 
content instead of files.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]