Git Used To It
GitHub is by far the most popular Web-Hosted Version Control Service (VCS) out there. It is almost entirely used for code, and is essential for most programmers day-to-day operations. Along with all of the functionality of Git, GitHub adds some of its own powerful features such as Access Control, Collaboration, Bug tracking, Feature Requests and Task Management with peers. With over 28 million users and 57 million repositories (as of June 2018) you do not have much choice in the matter — If you want to be a developer you better learn to love it. Maybe surprisingly, I have found that many of my newbie peers (as well as myself) found it a tad intimidating, and would shy away from using this powerhouse of a resource due to lack of understanding how it works. My intent is to make Github your friend.
Git To The Chopper
To understand Github, we must first understand Git. Git was first developed in 2005 by Linus Torvalds (same guy who invented the Linux Kernel). Git was not the first VCS to exist. In fact, Git only came into existence after Larry McVoy of BitKeeper, the previous go-to for proprietary source control management system, withdrew free use of his product. Torvalds found that no other free system met his needs, so he built Git with a goal in mind that patching should take no more than three seconds. Git can be used for any programming language, or even plain old text files. Really, its just storage, with one major caveat. Git is a Decentralized Version Control System. Friends, this is huge. The primary purpose of Git is to coordinate work between multiple developers, whether they be in the same office or across the world, and to see who made what changes and when. If we don’t like the changes another user has made, we can revert back at any time. A developer can work on a repository locally (on their machine) and push the changes they made to the remote repo to their hearts content.
Note: There are some good reasons to still have a Centralized VCS which this blog will not get into.
Git keeps track of code history, which is warmly regarded as a “snapshot” of your files. A developer can decide when they want to take a “snapshot” by staging their code and committing when ready. Later, that developer or any collaborator on the project can visit that “snapshot” and work from there. Often enough, a developer will bug up their code with so much excess junk that it will inevitably break something. Attempting to remember and rewrite (potentially) hundreds of lines of code is a huge pain in the proverbial butt. Consider that you might pass along a project to a peer who screws up your code. Fixing their mistakes is often more frustrating than never having that peer touch your code at all. With Git, your so-called-peer can fork his own copy of the repo from any point, and screw it up on his own while you continue to write clean DRY methods on your own “master” copy of the repo.
Git ‘Er Done.
Now that you have a basic understanding of Git, lets get to the meat and potatoes. Git Commands.
$ git init — Initializes a local git repository. Once this is created you can start running other commands.
$ git clone — Clones a repository from github into whichever directory you are in when you clone down.
$ git branch — After you clone your repo to your machine, you can use this command to see what BRANCH you are working on.
$ git checkout <branch_name> — As a rule of thumb, it is never a good idea to work on the MASTER branch. Instead, use this command to create a new branch. Use this command to switch between branches at anytime.
$ git statusy— Checks the status of a Working Tree. This will display all files that you have added, and the differences between the working file and staging area.
$ git add <file> — Adds files to a staging area. You can run this command as many times are you like. $ git add . will add ALL files in the directory to the staging area until you are ready for commit.
$ git commit — When you are ready, this takes everything in the staging area and puts it into the local repository.
$ git push — Pushes your local repository to the remote repository from whichever branch you are working in. Pushing from your local branch will not affect the MASTER branch.
$ git pull — Great! You pushed up your code. Your coworker (across the world) pulls the latest changes from the repo to their machine.
$ git merge — Switch to the MASTER branch and then run this command followed by the other <branch_name> This will update the work from your other branch into the Master branch, which you can then push up to the repo!
$ git revert — Will create a new commit that will RE-add anything removed from your previous commit, and anything new that you added will be removed. This is your “undo” command.
Git with it or Git out
