There are several tools that you can use to improve your workflow. You don't need to adopt them all at once, but they work very well in concert, so you should plan to eventually adopt most of them.
This got quite long, but I've tried to point you in various directions that will be valuable in the near-term.
The TL;DR: "Start using git, and get comfortable running a basic linux server. Once you've gotten those two down, you'll have solved your immediate problems and have a plenty of potential next steps to examine."
VCS (git)
You want to adopt some version control system. git is the default choice, since it's ubiquitous. Adopting a VCS like git is sort of a prerequisite for things like automated deployments, automated testing, and ultimately full-blown continuous integration (CI). It even helps with manual deploys, and a little discipline about tagging releases can make rolling back a bad change a lot easier and more predictable.
You'll want to maintain a remote repository as a central source of truth. You'll have your remote repo set as the origin remote in your local repositories. When you sit down to work, you'll git pull to make sure you have the most up-to-date version of your code. After making some commits locally, you'll want to git push to your remote so your changes will be available elsewhere.
You'll want to host that remote repository somewhere reliable. You could just stick it on some VPS and access it via ssh, but you'd be leaving some nice tools on the table.
The quick-and-easy solution is to create an account at bitbucket.org. It's free, including private repositories, and includes a nice web interface with an issue tracker, etc.
If you're concerned about putting your code in a third-party service[1], or you want an opportunity to start managing a VPS (which is a great thing to do if you have the time and mental bandwidth), you can grab a $10/month VPS and install GitLab Community Edition. It's a GitHub-like, but you run it on your own server. It's pretty great, and the omnibus installer makes it relatively straightforward to install and update.
As mentioned in Sorin P's answer, GUI clients are available for git. SourceTree and GitHub Desktop are both good. I prefer the former. That said, you should git using the CLI tools as your primary interface. The CLI works everywhere.
Git can be a bit intimidating, but you can start small and grow. That said, a basic understanding of how git works will serve you very well. Git From the Bottom Up is pretty fantastic. Understanding the terms on the first page is essential.
To start, you'll want to have at least a sense of how git operates, and be familiar with the basic sub-commands clone, checkout, add, rm, status, diff, commit, pull, and push.
Development
I can't recommend using a local virtual machine enough, especially if your local environment is Windows. Get familiar with VirtualBox and Vagrant ASAP. This allows you to develop against a local environment that closely resembles your deployment environments. It's also a great way to get your basic Linux-admin skills up-to-snuff.
You'll use VirtualBox's "shared folder" feature so that a directory on the client (virtual, linux) machine is mapped to a directory on the host (physical) machine. This means your virtual machine is running "headless", with no graphical interface, just a console. Your editor/IDE, git client, etc, all run on your everyday computer, but your web server, PHP interpreter, SQL database, etc, all run inside the virtual machine.
As far as Editor/IDE goes, you're really free to use whatever you like. I know people who code in Vim, I was an emacs holdout for a long, long time, others prefer fancier IDEs. That said, I highly doubt Dreamweaver is optimal.
My IDE of choice for PHP is PHPStorm. It ain't free, but it's not expensive, and if you develop in PHP for a living it's a no-brainer IMO. It understands git, has a nice database client built in, debugging with xdebug works very well, and the static analysis becomes something you can't live without.
If paying is out of the question, you can usually get their "EAP" builds for free. It's essentially the beta of their next release, but is typically very stable.
The other alternative is NetBeans, which is free, and good. But not as polished as PHPStorm last I checked.
If you prefer something lighter-weight, lots of people like Sublime Text, and new(er) comers like Atom, or somewhat surprisingly, Visual Studio Code.
Bottom line: spend some time checking out at least one or two alternative editors/IDEs. Most people I know who clung to Dreamweaver did so because of it's FTP integration. But you shouldn't be relying on that anyway (see below).
Deployment
Deployment is about getting a new version of your site or app up onto a server. The method you choose will depend on what your hosting infrastructure looks like.
VPSes
I host just about everything on commodity VPSes. There are a ton of providers. DigitalOcean and Linode are popular in this crowded field. Amazon's AWS provides VPSes as well (the "EC2" service), but I don't recommend novices start there. AWS really shines when you need automation and orchestration, but it's hard to estimate costs, and the complexity is intimidating.
The core of updating a reasonably modern framework-based PHP project to a VPS looks like this (if done completely manually):
localhost$ ssh me@myvps.com
myvps$ cd /path/to/project
myvps$ git pull
myvps$ composer install
That's not what one would call a best practice, but if you get to the point that your deploy process looks like that, you're already miles ahead of trying to sync stuff over FTP.
From there, you can start looking into deployment tools. Capitstrano is the grandaddy, but others exist. Because these tools automate things, they can be a bit smarter than people. For instance, capistrano will check out the correct version of your sources locally, bundle them up, send them over to the server, expand them into a timestamped directory, and then manipulate a symlink to point your webroot to the new version. This makes rolling back (often) as simple as swapping back the symlink to the previous version. It's definitely worth it to read up on these tools; they may or may not be overkill for your needs.
Another tool to be familiar with is rsync. Rsync's job is to sync trees of files efficiently, and it's very good about it. If you don't want to run git on the server, you can build your own deploy process around local git and rysnc where you checkout (or git archive) a local tree of your sources, do whatever build process is necessary (say, composer install), and then rsync the whole thing to the server.
Any of these tools can be used to build up an automated deployment, using simple shell scripting. I suggest you aim to have a script that pushes (or pulls) a new release, and does so in such a way that it's very easy to roll back if things go wrong (the capistrano-style symlink trick is a great place to start).
Non-VPS Environments
I can't really speak to these. There is old-timey shared hosting like you're used to, where you're pretty much limited to SSH with no shell access. There are also Heroku-alike platform-as-a-service offerings for PHP, but I've never liked that idea.
That said, if you're absolutely married to shared hosting, you may be able to approximate an rsync-style workflow using a decent CLI FTP client.
What About Databases?
Deploying code is great, but sometimes a new code release requires some kind of database change (say a new column on some table, or some update that fixes artifacts of some bug you've just fixed).
This gets more complicated (especially when thinking about roll-backs), but there are tools to help. I've used both PHPmig and Doctrine Migrations with great success, and there are others.
The basic idea here is that you write small migration classes and the migration tools track which ones need to be run, and then run them. Your little bash script gets a new line it it somewhere that says something like phpmig migrate so when you run your deploy, any pending DB migrations get run automatically.
[1] Most people shouldn't be concerned IMO, but I don't know your circumstances, politics, or level of paranoia.
Best Answer
Sphinx (http://sphinx.pocoo.org/) is one such system. It was written for the official Python documentation but, unlike many tools for providing API documentation it does not rely on markup embedded in program code. It just uses a simple markup syntax in plain text files and can process those marked-up files into HTML/PDF etc. The sphinx website itself is (mostly?) a sphinx project so you can see what sort of output you get there. However, sphinx is quite themable so you can customize the look (or simply put your company's logo on the header if that's all you need.)