Using Git and Github
Last updated
Last updated
So before we start writing any non-trivial code we should set up an environment where we can ensure that our changes are saved and versioned. This is so we can go back to previous versions that may have had features we removed or that were more stable. We need a really fancy save and undo.
Git is a tool that runs in your development environment. If you are using a cloud environment, it will most likely already have Git installed. If not, you will need to install it yourself. Git allows you to save different versions of your code. Since we will be changing our programs as they evolve it is really handy to have something that easily manages all of your various versions. Git is a lot more powerful than how we will use it in this class but it is one of the most important tools in a developers toolbelt.
We also want a place to store all of the code we write in a location that is accessible to others (somewhere that isn't on your computer or cloud environment). This will allow people to view our code and even contribute.
GitHub is the place where we will store our Git repositories. There are other web services that offer code storage and management like BitBucket or Gitlab but GitHub is by far the most popular and is the default place for open-source projects.
The next two videos are optional but highly recommended. They talk about what version control is and what Git is. The final video is required and describes how we will use Git and GitHub for this class.
In order to get the projects that I have placed in my account on GitHub into your own free account you will need to fork them. Forking a repository means that you are creating a copy of the repository in your own account that you can modify without affecting the repository in the other person/organizations account. Think of creating a fork in the road in which the two copies may diverge. You will find a 'fork' button in the repository (which we will call a repo). After clicking it you will be redirected to your personal GitHub account and be placed inside your recently forked repo.
The repo is still only on the GitHub server. You need to create a local copy (or clone) in your own environment. Go to the terminal and write the following command (replacing the URL with your repo URL):
After pressing enter you will see some output in the terminal. This is Git doing its work to download all of the code from GitHub into your environment.
After Git has finished cloning the repo change your current working directory in the terminal to your new local repo.
You should now be able to run git status and see that you are inside of a Git repository.
Now is where you do your coding. You will modify or create files for your programs. You can change the files however you wish and then consult Git when you are ready to save a version.
You can see where you stand with Git by typing in git status. Git will tell you what has changed. This is a useful command to make sure you know what will be committed to the repository.
When you are ready to create a new version you will first need to stage your changes. Staging your files prepares them to be committed. Staging has its purposes but as beginners we will simply use it as a step before committing.
The . here means that you want to stage everything in the current directory. It is a quick way to say 'stage everything'. You can specify certain files by typing their names explicitly (specifying the filenames' relative paths).
After you have staged your changes you are ready to commit them to the repo.
We use the -m option to specify a commit message. If you don't include a message, then Git will open an editor for you to add one so its really just easier if you provide one.
You don't always need to push the commits you make back to GitHub (or whatever remote service you are using) but it is a good idea if you want to keep the remote copy similar to your local copy. When you have made your commits you are ready to push your changes back to the remote server.
origin is the alias by which Git knows our remote server. You don't have to worry about this because we are just going to use the remote that we cloned it from. This will always be origin.
master is the branch we are on. Git allows you to create various branches to make any changes you make conflict less with each other. We won't be using this either so your will always be master in this class.
In the same way that you should save your documents often to avoid losing things, it is a good idea to make frequent commits to Git. Frequent commits make it easy to roll back to a very specific moment. If you are ever having to say and in your commit message it probably means you could have made your commits more granular.