I've been researching into a simple Git clone for live deployment, using the following method:
Could Sourcetree handle this, instead of SSH, and could it be set up automatically (bearing in mind I'm rubbish with command line Git)? It'd save me a ton of hassle, I know Git has a simple url hook but Bitbucket post functionality is over my head.
Hey Rob, sorry for the delay on this one. I'll put this in an answer instead as it's quite detailed.
Your URL looks OK, however, are you certain that you've been dropped into the right directory as you're using a relative URL there. It might be better to do email@example.com:~/domains/site/html/.git? Also, SourceTree can create remote reposities, but at the moment only for GitHub and Bitbucket. See the screenshot below (this is because it uses API's to do so, it doesn't have access to run commands on the servers!)
a) If it's the origin remote then yes, you'll do "git init --bare". A 'bare' repository is a little bit magic in that as you say, it doesn't contain your working tree. This is very important because otherwise when you push changes to that remote doing a "git status" will make it think that files have been deleted after they've been pushed as they don't exist in the remote's working tree. As one of the devs here just said "It's everything except a working copy". Check out http://gitolite.com/concepts/bare.html for a mode detailed explanation.
b) The article you've linked to shows a manual process whereby you clone the repository to a directory on your server and then pull the changes when you want to 'deploy' the site. It's a push-pull set of actions which seems the easiest way to do it. Now, what you can do is just SSH into your server and pull meaning you can do it all from the same terminal. But what's even better is that you can script this process. So, in response to your above comments:
- If you're pushing to a bare repository, then no it won't have a working copy so the files won't just 'be there' unfortunately. Check out my answer to your next point below.
- If it's a remote 'bare' repository then it's not quite the same as having all the files. It doesn't have a working copy remember, so it's a set of objects. Take a look at the following screenshot to see my remote directory which has loads of changesets:
Note I have "GitTest" and "GitTestRemote". The remote one is where I'm pushing my changes to, and that's the contents of the folder. So you won't have a bunch of files because there is no working copy as it's a bare remote.
In short, I think your best solution is to have a post-commit/push hook which connects via SSH to do a pull on the server provided you trust the master branch completely. From my experience, merging with a branch can cause more problems so it's usually better to merge-test-deploy. You could whip up a simple SSH-pull script that would be a one-stop-shop deployment solution, or use a post-push hook to do that.
Let me know your thoughts, happy to give further input :)
Hey Keiran, thanks for such a detailed response! I'm understanding your comments and get the following:
Think hooks would help. Read a few tutorials on Git hooks and Github's URL post but Bitbucket's post hook looks complicated. Also read a couple of versions of scripts from simple PHP file pulls and a straight up bash script. So from this a couple of questions:
Where/how to serve script?
For secure passwords etc, my folder structure is:
/domain/.git --- /domain/html/<files> --- /domain/cgi-bin
Presuming I've cloned repository on live (assume it automatically checks out master):
What is best Local > Staging > Live method?
The client will want to view changes before going live, there's a way to serve a site from localhost but involves being connected. Ideally I'd push changes to a staging server, and automation rather than FTP:
I rarely use terminal but can follow instructions!
The thing with your latter points is that it's not something we usually provide information for as it goes out of the bounds of SourceTree. This is a configuration issue specific to your server. There'll be many guides, and many tutorials all doing things in various different ways. They're all different because these kinds of setups are completely unique to your setup. We can't really write it or make suggestions for you. Basically, just do it in a way that works for you by testing each step at a time. Try out a very simple script that will simply pull the changes into that directory and iterate from there on out.
If you're pulling changes then git would stop to say you have local changes that need committing, so if there's environment-specific files then you'll want to ignore them.
No no, I didn't say it was a bad idea to work off branches. My point was regarding ensuring everything works after a merge. And I quote "From my experience, merging with a branch can cause more problems so it's usually better to merge-test-deploy" - basically, once you merge your changes if it merges two changesets for the same file then often in my case there'll be build errors.
There's always branches, so you'd always been pulling from some branch. Yes, use a staging branch perhaps and pull changes into your staging site from there, if OK then merge that branch into master, but you still need to test the merged changes are OK in some environment.
Regarding submodules, that depends on what you need from the repository ;)
SourceTree can push to any valid Git remote, so can definitely be used to deploy sites (Heroku is one of the sites that pioneered this approach originally). Really the main configuration you need to do is on the server, SourceTree can just push to whatever URL you give it so long as it's a valid git remote.
Hey Steve, yes I have looked into that way of working but it looks a wee bit technical for me ... what I was meaning was cloning without reqiring Git to be installed on the live server - I know this can be achieved via SSH but I'd prefer doing it in SourceTree if at all possible. Not quite sure how cloning affects previous clones, i.e whether it overwrites everything or just new files, and I think you can auto populate submodules when doing the clone ... I'd like to give it a shot anyway i.e:
I may have another crack at some tutorials setting up Git on a server but looks a bit of a pain on shared servers.
Actually, it seems Git is already on my MediaTemple (GS) account, so one or both of these tutorials may be enough - or of course, using SourceTree! Clone from Bitbucket, then pull latest master changes. Nice:
Save me a few bob with deployment. Would still be helpful to find out the info above however, how a clone to a non-git server would work. Imagine most clients hosts would be without.
Perhaps I'm just being dumb, but I'm still struggling with this. I kind of understand how to do this with terminal, but as for SourceTree I'm not quite sure. I understand a SSH git URL would look something like this: firstname.lastname@example.org:domains/site/html/.git and fairly certain SourceTree can't actually create a remote repository for me.
I'm confused about the steps to "push" however ...
a) It seems reading this article that in order to push to a repository, it has to be (or should be) "bare". It also seems this may be the only way that SourceTree will be able to push any changes to it, although this article explains "bare repositories" a bit better and looks like as it doesn't hold working tree files it'd be useless on the deployment server.
b) However, reading this article via SSH looks way easier and includes the latest working files.
So it seems that the main difference is (b) seems to work like a regular local repository, whereas (a) doesn't hold working tree files and is just for tracking changes. How then would I use (b) with SourceTree? I'm assuming the way is once I've created the repository on the live server, to add it as a remote and push from the local repository, but I'm unsure of the following ...
- So long as I'm checked out on the correct master branch do I just push as if I were pushing to the Bitbucket repository, changing the url for the one above in italics?
- And will it contain the latest version of the files without having to do further checkouts on the live server?
Thanks, hopefully you can save me from going mad!
Have you ever noticed that fixing specific problems might be a door opener for a bigger challenge, affecting a wider audience? This was exactly the case when we, as a service company working with mul...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs