Symphony.

I am working locally using Mamp:

Is it easy to move the site live when done? what is the best practise? Any known issues? What are the steps?

Thanks.

It depends largely on your desired workflow. If you're not using Git, I think you should be able to simply copy the whole webroot directly, update the database details (config.php) and populate the production database with a dump from your development one.

ok.. thanks.

Should I be using Git?

@driftwood, depends on your use-case. Normally when starting out you don't use git at least till you get accustomed to it.

Eventually if you do a lot of work; you would use git as it would make it simpler to update and keep track of changes.

In both cases if you're using FTP upload you'd just copy the files & dump the database and you're ready to go. If you're using a 'release-script' with something like git the flow might be a bit different, but as long as your files & db are in place you'd be ready to go.

cool, thanks!!!

I work in a somewhat "old-school" environment. We use git, but we still deploy with FTP :/. When I move from local to production, it's usually just exporting, then importing the database accordingly, transferring the files, and editing the .htaccess file to make sure that RewriteBase is correct.

Or you could always export an "ensemble" of your local instance, then install it on the production server, exactly like you install Symphony initially. I've used both techniques in the past, though ideally, we'd be deploying with git. Hopefully that'll happen sooner than later, just takes some convincing.

yeah git is really confusing me :( sounds great but I have no idea.

http://try.github.com/ should help. Git is a massive time saver and a great way to keep track of changes, while making it easy to revert them.

Just google learn git and you will get tons of resources to help. Productivity will skyrocket once you get the hang of it.

nice. I got github on the comp. Do I or should I get an online account? Or is havingt things local good enough?

if you just want to update your own stuff; and don't want to edit things on symphony. Or else synchronise your websites to private repositories, you don't really need to create an account. Having stuff on your local is good enough in most cases.

I have it linked to my dropbox so it's backed up.

What do you mean by "edit things on symphony?"

Is the idea to work in git then push to the server?

@driftwood I meant contributions to code etc; which I doubt would be the case at the moment.

Not necessarily depends on your workflow. at work we have custom git-servers which take care of pushing to the server; but at the same time we have other sites which we have to take care of updating via FTP. Usually setting up a proper git workflow takes experience and most of all time to find what is best for yourself.

ok that makes sense.

Should I be using git or github?

Git is the version control system. Github is a website which lets you collaborate easily using Git. You can just use Git locally if you're just interested in versioning your code. However, if you want to share, collaborate on or distribute that code along with the revision data, Github will let you do that too.

No I don't really need to version per se. I do have man versions of psd files and code files at various points.

I found sourcetree that looks interesting.

Trying to figure out this whole commit, staged, unstaged etc..

Basically they're different states of the source files. Git uses snapshots of the files in a project, so modified (or not modified or unstaged), staged and committed refer to how Git sees your code, and it's status in the revision system.

An important concept to be aware of is that Git is basically a database of the history of a set of files. It keeps snapshots of these files each time you make a "commit" (or a reference to say that nothing has changed in a file). "Staging" is, in simple terms, a way of telling Git that a file has changed and is ready to be included in the next commit. This is especially useful because you get to choose which changes get included in a commit - you don't have to capture changes that haven't been reviewed, aren't finished or don't work yet.

There are much better explanations than this out there :D, here is one that google found for me

Edit: totally changed the explanation, previous one was hard to understand and mostly gibberish!

It's starting to make sense! Just a bit of paradigm shift.

thanks for the time, I appreciate it!