On Day 4 at Lambda School, we covered git and GitHub, which are both technologies that are new to me. I was aware that GitHub was used for version control in some way, but I never knew the details about it. We were actually called on to use GitHub earlier in the course – I can’t remember if it was from Day 1, or if it was later, but our instructor, Britt, explained that they knew it was an issue in the program that we’re supposed to use it to submit work, but it isn’t fully-covered until Day 4 of the course.

git

Ok, so in a nutshell, git is version control software that was created by Linus Torvalds, the same person who invented Linux. Its main purpose is to allow code to be copied, modified, and then (after error-testing), combined back into the main code that it was copied from. These ideas are called forking (copying the master code), branching (making modifications to that code so it now differs from the original) and merging (combining the new code and original code into a new master code).

git (yeah, its all lowercase, so starting sentences new paragraphs with it looks wrong) has the ability to compare code and track its changes, so it knows specifically what lines in code were newly added and what lined of old code were removed, and what lines were altered in some way. This can be viewed by people who review code before its merged into the master code, so they know what changes were made.

git allows multiple developers to work together on the same project, simultaneously, without severely impacting each other. Its safest when they’re working on different things, like different functions or modules, or at the very least different sections of the same code. For example, if a team was making a game, maybe a platformer, like Mario Bros. or Sonic the Hedgehog, one team might be working on a certain level in the game, and another team could be working on a different level; or maybe one team is working on making the character run and another is working on jumping; or one team is adding water effects that will be applied to all areas with water, and another team is animating enemies or modifying their AI. All of these things could be happening at the same time, with multiple teams each tackling one of them. They would all have their own fork of the master code, and when their respective parts of the code were in a complete enough state to be made available for testing, they could create a pull request, which is basically a flag that alerts people who they specify when they create their branch, that lets reviewers know that the code is ready for review, and if it passes, can be merged into the master branch.

GitHub

GitHub, on the other hand, is firstly NOT git. Its a separate entity and it offers what’s essentially cloud storage and a GUI for using git. There are other services like GitHub – for example, GitLab and Bitbucket, but GitHub has been around longer and has a much larger userbase. Apparently, its very widely-used by developers to build programming portfolios that can be shown to prospective employers and is a large presence in the open-source community for sharing projects for collaboration.

Git Bash

Although there are GUIs available for using git, the most common way of using it is apparently through the command line. The command line terminal that we use at Lambda School is Git Bash. I used to be very comfortable with MS-DOS, back in the late 80s and throughout the 1990s and early 2000s, but its been a long time since I’ve really used it. Git Bash is similar to the DOS terminal, but I think its Linux-based. Its commands are different. For example, I’m used to typing [dir] to list the contents of a directory, but in Git Bash, the command is [ls] for list. [cd] changes directories, and when combined with back-slashes or dots, we can move across multiple directories – using Git Bash, those flags behave differently from what I’m used to.

Process

When we work on projects at Lambda, we generally fork them from existing repositories on GitHub. Repositories are saved codebases on GitHub. That copies the code from Lambda’s account into our personal GitHub account. Then we can branch it and modify it to do whatever the project’s instructions ask us to do. This way, we’re working on a branch of our copy of the master code, so if we need to revert back to the master for any reason, we can.

We have to add our team lead as a collaborator, so he or she can review our code. They get alerted that we’re ready for a code review when we create a pull request for this purpose. Once they review any code we’ve branched, if it meets MVP (minimum viable product) or whatever the project’s requirements were, they can then merge it into our forked copy of the master code, and we’re assigned a grade for completion of the project (1 = didn’t meet MVP, 2 = met MVP, 3 = exceeded MVP by completing at least one stretch goal).

There’s more to git and GitHub, and I know we’re using it at a basic level right now. I suspect we’ll revisit it later on in the course and that things will get more complicated, but acclimating to the general process above meets the current requirements for submitting projects to Lambda.

Here’s a link to my previous post about using git and GitHub. I’ll add another post when I have time that outlines the process for adding a collaborator, and for making sure that any projects being worked on are actually going to the right fork of the project – I accidentally tried to update the original Lambda master code several times!

• “Simplified” git instructions for Lambda School students