Before talking about Github you should first understand what Git is and why it is used. Github is not necessary for Git to be useful although it certainly complements Git especially in team environments.
Imagine you are building a game for example. You might keep all the files for your game (maybe some images, html, css, javascript files, etc) in a main project folder. To develop your game your would typically write small snippets of code and then test them on your local machine. With this being the case you have only one instance of your project at a time. This could lead to some problems:
-
Say you make some changes, save it, then run your code. Unfortunately, you are now getting a strange error or bug and when you look at your code you are not sure exactly what is causing the problem. Suddenly your whole project is broken. You would like to go back to the way things were, but can’t remember exactly what the code looked like before.
-
Say you want to try something new out or want to add some new feature to your game. Unfortunately in order to do this you need to start adding code to your currently working project. This is not ideal as if it doesn’t work you will need to backtrack to where it was before you tried to add this feature. Seriously annoying.
Yes, these problems could be solved by saving copies of your project as you work or leaving large blocks of commented code in your editor. This is generally slow, requires organization, and is seriously impractical. Git is a much better solution and solves these problems by allowing one project to flow in several ‘branches’.
Once Git is initialized (‘git init’ is the terminal command) it will essentially watch all the files in its directory - now called a ‘repository’. Upon initialization, git will automatically generate a ‘master’ branch. This is typically your ‘good copy’, the branch that you know works and don’t want to screw up. It is generally not considered best practice to work directly on this branch (although I break this rule often) because you don’t want scenario 1 or 2 (or any other bad scenario that I left out) to occur.
Instead, you would branch off your master. For example, you want to add a new weapon in your game or something. You might use the command ‘git branch new-weapon’. This would copy the state of your master branch to the ‘new-weapon’ branch without needing to physically copy any files. You could now run ‘git checkout new-weapon’ and now you are working in the new branch, not your master.
Now you write some code for your new weapon. Two things might occur:
-
You realize this new weapon isn’t going to work out, it was a bad idea. In order to go back to your working master copy, all you need to do is run the command ‘git checkout master’ and your folder (and text editor) will magically go back to the way it was when you created the ‘new-weapon’ branch. No need to backtrack.
-
You make the changes and the new-weapon idea is working and you want to make it your good copy. At this point you would ‘merge’ your ‘new-weapon’ branch into your master branch. Once you do this and everything is good you can go ahead and delete the ‘new-weapon’ branch and be left with just your good copy. The nice thing is that you never risked your master branch at all.
Another essential part of Git is commits. Committing your code is like making a copy of the project at that point, you can go back to it later if you want. Again, Git does not need to copy your whole project to do this.
Although you can commit your code whenever you want, best practice is to do if for every change to the project, not every change to your code. For example, it would be a good idea to commit your code after you repaired a specific bug, but you probably wouldn’t make a commit for every line of code that you wrote to fix that bug.
git also supports a long list of nice commands which give you info about your project.
‘git status’ will let you know what files have changed since your last commit.
‘git diff’ will show you the lines of code that have been changed since the last commit.
‘git branch’ will show you all the branches of your repository.
There is much more to Git than I have written, but these are some of the reasons why it is so useful. It is basically a tool that will save you time in the long run.