What do you need?
This depends on the operating system you are using. My computer runs Linux, so for me it was quite easy to get started with Latex. Ultimately, all you need is a Latex distribution (TexLive on Linux, MikTeX on Windows and MacTeX on OSX), a text editor you feel comfortable with and a command line terminal to get started. If you need some instructions for this, the aforementioned Wikibook gives a lot of details. To use my scripts, you will need a Unix shell (my scripts are written for ZSH, but should work with Bash as well). If you are using Linux or OSX, you are fine, if you are using Windows, you will have to find a way to translate this into a batch file or, more easily, you will need to look into the Cygwin Project that allows you to use a Unix shell on the crufty operating system from Redmond.
As to the question, which text editor to use, there are many, many possible answers, and for the standard geek, the question is about as important as questions of faith are to a religious person. I for one don't care too much, because I know that VIM is the answer to all questions life might throw at you, but I am aware that others have different (ie wrong) views as well. If you are already using a text editor regularly (and no, "Notepad" does not count), try that one first. Almost all decent editors support syntax highlighting for Latex, and that is basically all you need. If you are not using one yet, have a look through the ones featured on the Wikibook and use something you are happy with.
To get everything out of this, you will need to make sure that you have the excellent Oscola package by Paul Stanley, a barrister (and QC) at Essex Court Chambers, installed. It should already be included in most Latex distributions, so probably you won't have to do anything, but if not, you can find instructions on how to install the package in the very extensive and helpful documentation.
Use version control
Something I recommend doing is to use a version control system to organise your thesis. This requires you to learn another set of relatively cryptic commands, but you will be very grateful that you did. The idea of this is that your computer organises the different versions of your thesis. This means that, when you had a very long night in which you thought it was a great idea to completely rewrite chapter 1 and to delete chapter 2, you will be able to revert the changes once you regret it. You also don't have the usual mess that all of us had at some point in their academic history - 15 files in a folder that have names like "chapter1", "chapter1-latest", "chapter1-really latest", "chapter1-very latest" and "chapter1-final". Instead all of this mess is organised by the version control system, easy to access and well hidden from you.
I recommend using git, a version control system developed by Linus Torvalds. It can be enormously complex, as it is designed to allow developing the Linux kernel - a project bigger than hundreds of PhD theses that is worked on by thousands of people at the same time, but the skills you will need to master are quite basic and easy to remember.
There is a very good tutorial to learn git on Github, the biggest provider of git-related hosting. It is well worth setting up a Github account anyway - they will give you a free private account if you explain the education angle, and you can use it both as a backup and as a way to access your thesis on other computers.
What you need to do now is to create the folder you want to host your thesis in - I chose the unimaginative name "thesis", and to change into that folder. With git installed, you need to start your project by changing into that folder and typing
which will initialise your git repository.
How to structure your thesis
The structure of the documents is quite important - after all, you will want to be able to not only have a nice looking thesis at the end of the time, but also to send individual chapters to your friends, supervisor, publishers, conference organisers and so on.
My approach is to have one main folder called "thesis" that includes almost everything - downloaded articles, notes, images to use in the thesis etc. To keep this from being too messy, I have the main text within a subfolder called "text" and the chapters inside their own folders. The finished PDF files are moved to the "output" folder.
This is how my thesis folder looks like:
Obviously, you can have extra folders in this structure to include things like publication manuscripts from your chapters, conference papers you wrote and everything else thesis related.
Once you set this up, you can start using your version control system. The idea of it is that you commit changes into the history. Every time you made major changes, you should go through this step, so that you can later revert these changes should you have to. It is a useful idea to set up a .gitignore file that specifies which changes git should ignore. There is no need, for example, to include the thousands of PDFs in your literature folder or the output folder that you can easily recreate anyway. And it is a good idea to exclude all the temporary files that Latex likes to create. Simply copy the text below and save it into a file in your main folder called ".gitignore".
*.aux *.glo *.idx *.log *.toc *.ist *.acn *.acr *.alg *.bbl *.blg *.dvi *.glg *.gls *.ilg *.ind *.lof *.lot *.maf *.mtc *.mtc1 *.out literature/ output/
Then it is time for your first commit. You will need to do this in two steps: first telling git which files to look at for the commit, and then the commit itself. By saying "git add .", you're simply telling it to look at everything in the current folder, and the "-m" option allows you to describe the changes. Make sure you explain what you did in a way that you can figure out later what they meant - "Started chapter 5", "Added some background information to the introduction of chapter 2" or "Deleted interview details that were unnecessary" for example.
git add . git commit -m "Set up folder structure"
After a while, these two steps will be second nature for you, alongside the "git push origin master" if you use Github and want to save your changes to the remote instance as well (for that, please see the Github tutorial above).