In my first (and only, so far) ~/random post, I mused:
So, after the requisite several weeks’ procrastination, I signed up for a free account on GitHub. Soon, I should be able to do away with the My Code Archive page and just direct you to GitHub for a much snazzier experience when browsing all my code. Woot!
#3: Am I The Only One?
I hear over and over again how important it is to have a mentor, or at least a partner, when you code so there is always both pressure to do better and a check to make sure you’re considering all the open options. However, since I live in Hannibal, Missouri, the opportunities for doing so are… limited.
Okay, they’re as close to nonexistent as could be.
However, Breck Yunits’ post on how to get yourself a mentor mentioned a way I didn’t think of previously — Github. His other ideas, though good, are a bit impractical for me right now, but Github seems like it may be a promising avenue for me to pursue.
Signing up for GitHub was a completely painless process, to my pleasant surprise. Pick a username (which you can change later, but only once!), password, and e-mail account, and you’re ready to go! Creating a new repo on GitHub is a simple process as well; choose a project name, decide whether your repo will be public or private, and (optionally) add a short description and a project homepage. Most people won’t need a private repo, I’m guessing — they seem to be geared for small companies that want cloud-like dev tools but don’t want to maintain their own git server.
Now in order to actually use GitHub’s repositories, you need an SSH keypair to communicate securely to GitHub’s servers as well as authenticate your machine to them. There are numerous clear instructions available on how to generate and test a keypair, but the best and clearest tutorial was GitHub’s help page on generating SSH keys in Linux (they also have instructions for Mac OS X and Windows).
And now for the scary part — learning git.
Despite my worries to the contrary, git actually feels pretty sane to use, even for my tiny projects. A good beginner’s tutorial (for me, anyway) is the online gittutorial(7) Manual Page. For the projects that I’ve churned out so far for BG, I only need about a half-dozen commands to get started — which is a lot less intimidating than the whole library of 150+ git commands!
Basically, you navigate to your project directory and type
git init, which readies the directory with a .git subdirectory that will contain all the VCS voodoo. Then you need to tell git which files to keep track of, which is likely all of the files in that particular directory, so
git add . is probably what you want. You are also allowed to specify individual files and/or directories, which would look like
git add file1 file2 directory1 etc.. Then to make your first commit, type
git commit, make any comments about the commit that you want (you type your comments in a vi interface, so type
i to make your comments, then hit the Esc key to go back to normal mode, then
:wq to write changes and exit), and the first milestone of your project is now set in stone! Okay, sort of 😉 . After you make changes to your code, just repeat those last two steps —
git add . and
git commit — and your new changes are now the master copy, and the previous copy is relegated to the dustbin of history.
There are plenty of other commands to explore, but those are the ones that I’ve experimented with (successfully) — I’ll get to the others as I grow more proficient with git. I have also looked at some graphical frontends to git — namely qgit and gitk — but I want to become acquainted with how git itself works before I start using other tools.
I don’t have my BG projects hosted on GitHub just yet — I’m working on migrating my current hand-crafted “VCS” system to git, and I’m probably going to practice a good bit before I push everything to GitHub. However, when I do push everything to GitHub, it shall be announced with fanfare and page restructuring (yay!).
In the meantime, have a wonderful weekend, and happy hacking!