GIT ‘er done!
A guide to understanding GitHub (intended to be narrated by Daniel Lawrence Whitney)
What is GitHub?
“GitHub is a code hosting platform for version control and collaboration. It lets you and others work together on projects from anywhere.”
But what is version control?
Version control is the process of storing multiple versions of a single project, allowing each version to be recalled at a later date.
This essentially means that every time you would save a new file you are creating a timestamp of the original file. On GitHub all of these timestamped files are placed in to a single folder for you to reference later. This allows you to easily rollback to a previous version of your file, which can save a lot of extra work ,stress, and time.
Local vs Remote Version Control
The way that many users interact with GitHub revolves around the idea and differences between local and remote version control with the majority of confusion coming from a misunderstanding of what you are updating/working on and where that file is being saved. A local version control system stores all of the information on your computer, locally. This system works great while you work on a project by yourself. However, it becomes cumbersome when you attempt to collaborate.
Some organizations use a centralized repository on a company server. A repository can be thought of as nothing more than a big folder that stores all of the files of a particular project. Users pull only the files they need to work on from the server. The advantage is that multiple people can work on the same project at the same time. The disadvantage to this is that a user must be connected to the network in order to work on the project.
Which brings us to the third system, a distributed version control system. In a distributed system, all users have a complete copy of the entire repository. This means that you can work on the project locally without any network connection. Upon reconnecting, you can push your changes to the server and merge with the server’s repository.
So what version is GitHub?
GitHub is the distributed version control system
The basic steps of how to use GitHub are:
- Forking a repository GitHub.
git cloneto clone a repository to your local computer.
git statusto see the status of your locally cloned git repository.
git add .to add your local changes to be committed.
git commit -am "Commit Message"to commit changes that have been added with a message.
git pushto upload your local changes to GitHub.
- Opening a Pull Request on GitHub.
But sometimes just memorizing these five commands don’t really stick and a deeper understanding of what is going on is required.
How to interact with GitHub
The first thing to do, as is a best practice when working on any projects, is to copy a lab and so as to prevent any unwanted changes being permanently saved on the original copy. On GitHub this is known as forking a lab and is done by selecting the Fork option in the top right of the screen. You would then select your profile to copy it to.
Once you have forked a lab, it still only exists as a lab remotely. You want to download that copy to your local computer to work on. To do this you want to clone the lab by copying the http or ssh link.
With that link copied you want to download it to your local computer using GIT CLONE followed by the copied link.
Congratulations, you have now successfully created a copy of this file on to your local computer!
Now that we have created a local copy to work with we probably want to interact with it in some way. To do this, change the directory so that you are in the folder that you just copied from GitHub. GIT REMOTE -V will show all the currently configured remote repositories. GIT STATUS will return all changes that you have made to a lab at any point and will summarize differences between your local copy and the last time you pushed changes to the git repository. Once you have a git repository locally, git will keep track of every change you make to the code in that folder.
When there is a difference in the lab on your local repository that you want to save, GIT ADD + new file will add to your local repository and keep track of it. After adding you can git status which will show the new file now being tracked in your repository. As a best practice you should perform the GIT ADD function whenever you want to save a change to a file.
The GIT COMMIT -AM “message of commit” creates a moment in time for git to keep track of the save you have just made. Your repository is back in to a clean state with no changes it needs to keep track of. The message should be summary of what has changed.
Once you are ready to put the changes you have made to your file back on to GitHub you want to GIT PUSH the files. Firstly, GIT LOG shows commits you have locally on computer. GIT PUSH, pushes local commits and pushes them up to GIT HUB remote, generally called the origin master.
But wait…sometimes you still are not done and need further testing to be completed!!!
Sometimes in order fully complete labs you need further testing to be done by learn.co. A GIT PULL request is how you submit your lab to be evaluated or graded on learn.co.
After pushing code to git hub when you want learn.co to ‘grade’ it, you must create a pull request. Go to your forked lab on GitHub and click on the pull request button to create a new pull request and then submit the lab.
You will then need to create a title and then select a pull request again. Once this is completed, it has submitted the code back to learn.co for grading!
USEFUL GIT COMMANDS
BEST GIT PRACTICES
But really the best way to understand and become comfortable with GitHub is repetition. After reviewing everything above I went and did a simple lab that had some (by my standards) tricky to understand git commands and actions in order to practice.
After cloning a lab to my local repository I checked which branch of the repository I was in using GIT BRANCH:
GIT BRANCH ADD- will create a new branch and GIT CHECKOUT will switch to a newly created branch.
GIT BRANCH again shows that I have switched branches
GIT ADD and GIT COMMIT are used to save the changes to this new branch that I have made
GIT CHECKOUT and GIT MERGE are then used to switch branches and save changes to the master branch on the local files
We have made the changes locally but this is not reflected in the files on GitHub just yet. We still need to tell git hub about the update. First we need to push the update to the master branch on the remote repository using GIT PUSH ORIGIN MASTER and then a set of GIT COMMIT and GIT PUSH.
Now to check that the updates have made it to GitHub successfully which can be seen in the commits section of GitHub and should have time stamp of how recently this was made associated with your username
With a little bit of practice Larry ‘Gits’ it as do I and hopefully you do too!