I roll my own with Google drive plus an external hard drive. Probably not the best option but works for my needs.

Tom, I use Acronis. Seems to work moderately well but I have to remember to plug in my external hard drive occasionally to allow it to be backed up too...

If someone is a complete beginner with GitHub, what are some essential things they should know? My new contract job uses GitHub as their content management system, and I want to go in with being aware of whatever the common mistakes are.

Are you familiar with git itself?

There's nothing especially unique to GitHub over other git hosts (Gitlib, Bitbucket, etc...)

Typical git workflow is that you clone the repository you need. (git clone ...) then you switch to the branch you need to work on (git checkout [branchname]) or create a new one (git checkout -b [branchname]).

Something to keep in mind here is that if you when you create a new branch it exists only locally on your computer.

You change/add/delete files.

To commit your changes is a two part process. First you stage your changes with the 'git add' command. You can specify individual files to stage or stage them all by going to the root of your project and executing it there. (git add .)

You can see the current status of version control with the command 'git status'. This will let you see what files are staged and which files are modified but not staged.

Once your files are staged, you can commit with 'git commit'. Usually this will include a comment. (git commit -m 'My commit comments')

When you commit your changes they are committed locally, they will not be in the Github repo. To do that you need to push the commit. This can be done with the command 'git push origin'. Here, 'origin' is the name of the remote repository. By convention 'origin' is the name of the central repository. If you are working on a new branch you can use the '-u' option to connect your branch to the remote branch on 'origin' (GitHub). (git push -u origin).

to be continued...

Now, let's say someone has modified the master branch while you've been working on your branch and you need to pull those changes in. What you do is switch to the master branch (git checkout master), pull down the latest changes, (git pull), switch back to your branch (git checkout my-awesome-branch), and then merge in master (git merge master). Git is pretty good at merging, but if there is a conflict then you have to resolve them manually. Once you've resolved the conflicts, use 'git add' to stage and 'git commit' to commit. Don't forget to also 'git push' so 'my-awesome-branch' on origin is updated as well.

A minor pitfall, is that git doesn't keep empty directories. So you may see people adding placeholder files in directories they want in git. ( '.keepit' is a popular name ).

A very useful thing is .gitignore files. Files, directories, and wildcard names can be added to a '.gitignore' file in any directory of the source tree and any matching files will be ignored by git. Great for generated files or configuration files that shouldn't be shared.

I haven't used Git before, but from Gud's info, it's pretty similar to SourceDepot. So as long as I keep a cheat-sheet of the commands, I should be fine.

There are also a ton of GUI clients for git. I like the ones that don't try to do too much so I know what git commands are getting issued. They are very useful for dealing with situations where you want to cherry-pick specific files for a commit or stuff like that. One client I really like is just the one built into Visual Studio Code: simple and straightforward. I also really like gitg but that might be a Linux only thing.