Note to self & others: The folks at CodeNewbie suggested blogging for beginners and while I’m not a complete beginner, I’m not sure that my blogging is meaningful at this stage. There’s a lot I don’t know and I’m not able to fully explain. As a writer it’s difficult to share these “half-thoughts” and under-developed musings about subjects. I’m accustomed to writing well-thoughtout pieces, so this is definitely difficult for me. Wonder if any other code newbies have have this issue… Anyway –
The first CodeAcademy course I completed was on Git. I’d come across GitHub quite a few times working with WordPress & downloading plugins but didn’t quite understand what it was for, so I thought it might be beneficial to start my developer coursework with this essential skillset. I started the course and it quickly became evident to me that Git is not the same thing as GitHub. A quick google search of “git vs github” yielded a few helpful insights, including this great explanation around the concept of version control.
Version control allows you to keep track of changes you’ve made while working on a project. It creates snapshots (something I’ve familiar with thanks to Adobe Photoshop) which you, the creator, activates and those snapshots will allow you to refer back to them in the event that you need to correct or change something in your code. Git software was created for that sole purpose. You install the program on your computer, create a repository, add files that you want to work on, and as you make edits to those files, you create a snapshot, called a commit which includes comments about the changes you’ve made. This entire process reminds me of college and all of the horror stories of computers crashing while you were writing a 20 page paper. Once portions of your hard drive are recovered, you learn that you only saved changes up to page 2. From that point on everyone started suggesting that you save often and that goes for commits. Along those lines, they say “commit often” as it will help with troubleshooting down the line, so you’re not wading through shitloads of code revisions to find one mistake.
I’ve had my own system of version control for years! While working on a project, I would save various versions of files I’m working on along the way, ending each filename with either v[number of version] or x, xx, xx, and so forth. It’s not the best system and it’s difficult to keep track of what changes each file includes unless I provide some type of description in the title (which I rarely did unless it says “original”), so learning that there was better way to go about this that doesn’t involve a folder including 10 different versions of single.php piqued my interest.
While the internet is full of amazing resources for learning Git and GitHub I figured it would probably be more beneficial to learn within a classroom environment. So I signed up for an Intro to Git/GitHub course. In preparation, I installed GitHub for Desktop based on the information provided by the course organizers. At the meetup, I learned that the instructor would actually be using the command line so I also installed Git for Windows. I do know there is a shell/command line installed with GitHub for Desktop but I’m not clear on the differences yet so now I have both on my computer and I haven’t done much with it.
The class didn’t delve deep into many git commands and I plan on revisiting the coursework which you can access here. A few things that were covered in the short time we were there included: the difference between centralized & distributed version control (which I’m still trying to get clarity on: a few resources here & here), creating ssh keys & configuring a basic settings, creating a local repository, creating a file, adding a file to git for tracking, and commit-ing changes to a file in the repository. We tried out a few scenarios where version control would be helpful: 1) if you need to revert to a previous version prior to commit-ing current changes, 2) if you need to revert to changes after you’ve already commit-ed. We also discussed merging and resolving merge conflicts. I can’t go into great detail on a lot of this yet because I don’t feel like I have a complete grasp of it, just a top-line understanding.
The final portion of class was a very brief overview of GitHub, which we established earlier is completely different from Git. We talked about the benefits of the GitHub GUI interface and cloning other people’s repositories. The instructor showed us various ways to view additions/deletions which was helpful to me, as I’ve used the _s WordPress starter theme to create themes and since it’s always in development & shared via GitHub, I like to be able to see what changes were made, side-by-side. We also learned how to use the command line to transfer our local repository to GitHub, using the email & other configuration settings we established earlier in the course. You can also host files on GitHub, so it can be configured to appear as your homepage.
I’ll need to revisit this course & my level of understanding later. Hopefully by then I can break it down in a way that others can learn from it as well. I’m still struggling to figure out what I should use: Git for Windows or GitHub for Desktop and how the online site plays into all of that.
Another important thing to note is that there are alternatives to GitHub which I’ve researched. I haven’t settled on anything but since GitHub is often suggested that’s what I’m using at the moment. It could all change based on preferences & needs.
Until then, here are some additional resources on the differences in Git vs GitHub, command line vs. GUI, etc:
- http://stackoverflow.com/questions/13321556/difference-between-git-and-github
- http://programmers.stackexchange.com/questions/173297/why-learn-git-when-there-are-gui-apps-for-github
- http://stackoverflow.com/questions/33428099/what-is-the-difference-between-git-for-windows-and-github-desktop
- http://betterexplained.com/articles/aha-moments-when-learning-git/