(it's actually not that much!)
Please note - this remains a first draft stage document; and will forever be so. It's main goal is to give you some of the core phrases you will need to search out answers on your own! Searching around for answers to git will almost, if not actually always, lead to a solution. Comments, improvements, and especially links to more and more different types of introductory git guides (videos! interactive sites! gifs!) are welcomed.
Git in a simple view is like a really fine-tuned track-changes process. To painfully extend the word processor analogy, you know when you're trying to just move an image in a document a teensy bit, but you can't touch it without it going crazy, moving to the next page, or overlapping text, and you really wish (if you're a bit of a nerd) that you could just edit manually the setting, like an HTML/CSS stylesheet or similar? Git is like that, but for changes.
Of course, it is built for and around software development - and has a ton of extra features to help automate and manage that. But today, we're talking about using it for text content management (code is speech!)
This is largely a guide to help you figure out where to go search for more specific help in setting up and using git.
I use git from the command line in Linux. If you're not really familiar with the command line, there are some GUIs that can help get you started, and git-focused editors like Atom that some folks swear by. I can't really help with those. Similarly, I lean heavily on github. You can also use gitlab (which is open source, and you can run your own).
This involves: creating a github account, creating a test, private repository, and setting git up on your local system. If you don't use Linux, you'll also need to set up your command-line environment in OSX or maybe MS's Linux extension work. Worst case, you can set up a lightweight virtual machine.
I really recommend setting up git to use a key instead of a password; https://help.github.com/articles/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent/ is a good start (I add passphrases: https://help.github.com/articles/working-with-ssh-key-passphrases/) , and I also like to edit my ~/.ssh/config file; which these guides gives some hints towards: https://gist.github.com/jexchan/2351996 ; https://confluence.atlassian.com/bitbucket/set-up-ssh-for-git-728138079.html . Learn more about ssh config files here: http://nerderati.com/2011/03/17/simplify-your-life-with-an-ssh-config-file/
With that, you should be able to "clone" the private repo you made onto your local system. Here, the github guides are pretty useful; in essence you'll be in the folder where git will create a subfolder for the project, and you type git clone [project info from github] . Git will copy everything from the remote version hosted on github to your local copy.
http://blog.scottlowe.org/2015/01/14/non-programmer-git-intro/ and http://blog.scottlowe.org/2015/01/26/using-git-with-github/ are amazing startup guides. Really, you should just read his entire series.
-
"clone" is the first command you'll play with - it's a full copy of any remote repository onto your local system. From there, you can build whatever tool it was, edit content, and so on. What you cannot necessarily do is contribute your changes back, unless the remote version recognizes your account as one that can write to that repository.
-
"fork" is a way to make a copy of a remote repository in your own account, so you can have a copy to really go wild with. Once you fork, you can save your changes not only just locally, but to your remove, forked version as well. This makes merging these changes back in to the original a lot easier
-
"branch" is often covered at the same time as discussing forks (see http://blog.scottlowe.org/2015/01/27/using-fork-branch-git-workflow/ for a detailed walkthrough of both). Branching is kind of like a bookmark for a specific chunk of changes you're making. This is a great practice, but less often done in the git-for-content world it seems (maybe that's just me and I'm being horrible). Branching really (really) helps if a lot of people are coordinating on the same codebase or content at the same time, so it is easier to track who is making what changes where. You can "checkout" multiple branches running in parallel; and also use the checkout command to nuke changes to a file back to the last version on the branch (https://stackoverflow.com/questions/215718/reset-or-revert-a-specific-file-to-a-specific-revision-using-git)
-
"status" is a git command that gives you the low down on what is going on on your local computer right now. Run early, run often.
-
"pull" is a way to make sure what you have locally is the same as what you have remotely. By itself, pull only checks one step up. I try to always check my status and pull if needed before starting hacking on any local repo.
-
"commit" So you've made a change. Commit, well, commits its - but it's a very soft commitment for now. Commit basically is a way to tag a chunk of work as one cohesive change (this might be editing 3 documents and changing an index file, and also adding your name to the credits file, for example). Git will force you to provide a short description, please make this clear and specific to the change (e.g. "changed 4 files" -- not good, "Added foobar content and updated index, credits" -- useful!)
-
"add" and "remove" Before you "commit", you have to add files to the commit. Again, each commit might be one or more files, and some might even delete "remove" files. You can un-add files from a commit, and even un-commit a commit.
-
"push" - this pushes your local commits to your remote repository. If you've made tons of changes and not done a push, and you lose your computer, those changes are gone. Push merges your changes up, which also allows others to see them, pull them, and so on.
-
"pull request" is what you do to merge your changes in to the repository you forked off of originally. There are other ways to do this (if you have access to push directly into that repo, you can push to your repo, but you could also push to the upstream repo). Pull requests though are generally the preferred way, so that others you're collaborating on can more clearly see the changes you made.
Oh Shit Git has you covered for all your "how do I undo/fix..." problems.
This barely even scratches the surface. You can automate things, tweak your configuration to ignore certain types of files, recover from all kinds of crazy errors, and even "cherry-pick" very specific changes you like from a set of changes you didn't. You can "stash" local changes while updating from upstream, and do all sorts of super useful comparisons and diffs across your work and the work of others.
It's really hard to truly mess up in git - there's (almost) always a way to undo things (and git tends to warn you if not). The downside of that is your changes (once pushed) are visible.