For the better part of three months, I mostly used GitHub as a way to log into several tutorial sites, though I figured I would eventually need it to showcase some of my projects. Fast forward to “eventually”, and now I am learning the ins-and-outs of the Command Line Interface (CLI), and GitHub, and this, and that, and working on a couple small web projects, and pretending I’m helping with an app, and working a full-time unrelated job.
Y’all. I need my GeoCities and my youth back.
I have broken down some Git/GitHub terms in ways that they have made sense to me.
This may or may not be the first post in a series. It depends on how much I learn and whether or not I get my life together.
Git(Hub) for Beginners: Fork, Branch, and Clone
What you will need: nothing. Maybe a beverage… your call.
Level: “I-haven’t-even-started-coding-yet” beginner
Who uses Git(Hub): web developers, programmers of all flavors, app developers, and potential employers
Do I need Git(Hub)?:Yes
First, it is worth mentioning that Git and GitHub are not the same thing. Git is a version control system; it is where one would manage the revisions and versions of your code. The data structure that Git stores your code in is called a repository (‘repo’ for short). GitHub is a hosting service for Git repositories (so, like DropBox for your code projects and their versions). The analogy is: Git is the tool, GitHub is a service. There are other repository hosting services out there, such as GitLab and Bitbucket, etc. GitHub is the most popular and it’s what I use.
Quick aside: you need to download Git to use the command line on your computer. If you don’t want to use command line or know how to yet, you can download the GitHub Desktop client. If you are not working on a project locally (on your computer), you can do most Git actions on GitHub in your browser.
Ok so forks, branches, and clones. Let’s start with clones.
A clone is a copy of a repository (it can be yours or another user’s) for you to keep and make changes to.
Imagine making a copy of your friend’s ‘Documents’ folder on your thumb drive. Now, you can make changes to the contents on the thumb drive without touching your friend’s original content.
That is pretty much a clone. It is in it’s own directory, and any changes that you make to the code (or your friend’s diary) will go to your cloned copy. This clone includes all the original repo’s branches and change history.
Speaking of branches… a branch is inside of the repo and where you will find things such as new features being developed, bug fixes, or maybe a new layout of the homepage being tweaked.
To follow the friend’s diary example: You have a copy of their diary on your thumb drive (clone). Now, you are going to add an entry about that one time at band camp (branch).
Any changes you make to the branch will stay in the branch until it is merged. Keep in mind, when you merge changes it will merge to your cloned repo.
Forks are usually specific to GitHub; they are a GitHub-to-Github clone. Specifically, if you clone a repo, it will be cloned somewhere on your computer for you to make changes to and upload (push) later. A fork is a clone made on your GitHub account.
Example: I am participating in #100DaysofCode. I needed to fork the original repo (which included the rules and blog layout) to my GitHub account, and then clone it to my computer to make changes. I update the ‘blog’ file on my computer, and then push the changes to my GitHub account for the world to see, but it doesn’t update the main #100DaysofCode repo. No branches are required in this example.
I hope this was useful to someone. Please let me know if it was!
Eventually, I’ll make an easy guide on commit, push, and pull.