One of the benefits of Git is how it can be adapted to any workflow.
If you try and introduce a new tool
and a new workflow, it's two things to learn, and if you picked a workflow that doesn't work well for you, it'll just be frustrating, and make it harder to learn Git.
So better to mostly stick with your current system for the time being, which is effectively a single branch with rsync replaced by git push/pull. You might also want to consider using Git just between your dev/test environments, and sticking to what you currently know and do with the live environment until you're more comfortable.
To get the current code into Git repos, there's no way around reading docs to figure out what commands/options do, but some pointers...
Convert one of the directories to a git repo, using "
git init" one of the directories, adjust the ".git/config" and ".git/info/excludes" files as necessary, then "
git commit --all -m 'Initial commit'" to store the initial files.
To setup a second repo, the standard method is to clone - but you already have the files there and can't clone into a non-empty directory, so instead you can manually copy the ".git" directory to the second location (using rsync or scp), and then you'll then be able to use
git status to see if there are any differences, which you can commit or revert accordingly.
(If the .git directory would reside inside a public webroot, you'll probably want to first configure any live servers to block such paths, if they don't do it by default.)
Once you have both/all directories as repos, connect them with "
git remote add NAME PATH" (on each repo) and use "
git fetch" to sync changes, and "git status" will say you're up to date, and "
gitk --all &" will tag the first commit with the remotes.
Whilst learning Git, I would occasionally zip entire directories before doing push/pull/merge operations so if I screwed up I could easily copy everything back - e.g. "
tar -cvzf ~/backups/reponame_timestamp.tgz /path/to/repo" - though I don't recall if I ever needed those backups, since most situations can be recovered, but it can be reassuring to have an escape plan.
After you've worked with Git for a while, then you can decide if it makes sense to try out a more structured workflow, such as using feature branches or whatever.