I Don't Get Git: Why are you yelling at me about version control?

Project one is just around the corner for my students! It's an exciting time. I love seeing what they all come up with and helping them connect the dots. This one demonstrates their skills in HTML, CSS, JavaScript and APIs. All that is great and I have a ton to talk about there, but today I feel like it is very important for my students to understand version control.

For the first six weeks of this course I watch as some of my students make this same mistake. "Write all of my code in one go, commit, push, submit homework." I try to impress upon them the importance of version control and how to use it but it seems to fall on deaf ears to an alarming amount of students until the first merge conflict or a massive amount of debugging in project one. I will admit there is some amount of "I tried to tell you this" going on in the back of my mind when they come to me with them, but more I'm just sad that they didn't hear it in the first place.

Why don't they know these things? Don't you teach them? Yes, we teach Git. There's a healthy dose of it before day one of class and we cover a little piece of it every time we wrap up a topic but, honestly, no one cares about it(yet). "It's not part of my code. It's not part of my application. It's not important." And it really isn't apparent to them how important it is before they start having to work with other people. Ok that's maybe a little understandable. They're ripping through content at breakneck speeds and it's a struggle for quite a few students to just keep up with weekly homework, much less learn what seems to be "extra" stuff that never impacts them.

So here I am on LinkedIn trying to write simple explanations to questions I get in class and I've missed one of the most important and frustrating things. No one asks about Git or version control. So today I want to answer the questions they don't ask, but probably should:

• What is version control?
• How does it work?
• Branching???
• When should I use it?
• Why do I care?

What is version control?

So there are quite a few version control systems, but, since we teach Git, that's what I'm going to talk about. Git is open source version control software with an itsy bitsy footprint and and super fast performance. It's important to note that Git is not GitHub or GitLab, etc. GitHub and GitLab are cloud based hosting services that are designed to make it easier for you to manage your Git repositories. Ok? Git makes it, GitHub holds it. I think that makes sense...

At any rate, version control is sort of what it sounds like. It's making new versions of your repository at intervals of your choosing. You know that git add and git commit stuff? The commit is where the new version is created. All of your commits for a repository paint a picture of your progress. There's some techy mumbo jumbo about how Git stores your commits that I encourage you to look up if you are so inclined.

How does it work?

Imagine you're doing a puzzle that's white, has 1000 pieces, and each piece has a number printed on it. The pieces don't fit together in order and the numbers aren't all oriented top up. I would never buy that puzzle because I don't hate myself, but it's a decent analogy here.

Alright, you're half done with this thing and here comes Betsy feeling particularly passive aggressive. She decides to move around the last handful or so of pieces you placed. Now nothing else fits and it's quite obvious that you're going to have to pull apart most if not all of this puzzle and start over. Before you think of all the nasty things you want to say to Betsy, let's talk about how version control would help you here.

Same scenario but every 25 or so pieces, you take a picture. At any point, passive aggressive Betsy could come along, but you now have a way to keep most of your work intact so you won't need to actually start from square one. The only work you've lost is anything after the latest picture. Since we're taking pictures at intervals we can get pretty close.

This is what Git does for you. It holds on to all of those little snapshots of your project for you so that when, inevitably, something breaks beyond repair, you don't have to scrap your project and start over. Just revert back to the last working picture(commit).

Betsy still needs to learn how to communicate. Version control can't help that.

What's the big deal with branching?

Well, making and working in branches in your repository adds another layer to your version control and it's a very important concept to understand and put into practice.

Now, when I went through this course, while I kept up decent practice at committing early and often, I never bothered branching my repositories on my weekly homework. That's bad practice even if you're working alone. On top of aiding version control, branching can help you organize your work. There's something we call a "separation of concerns" in development that has to do with how we organize our code, but really, this concept can be applied to a lot of things anywhere in your life including keeping your work in small manageable chunks to maintain sanity. Additionally, even if no one cared if you utilized branching in your homework or practice, it's good habit building. Just do it.

Ok. Ok. It's important. Now what is it?

So branching is again something that is kinda exactly what it sounds like. In the image, we see at the top Main and then Develop and then a bunch of other boxes that don't need to make a whole lot of sense right now. The takeaway from this image is the use of a branching strategy. Let's break this one down in simple terms:

1. Main: Our main branch is where our production ready code is. In this case, this is the branch that we deployed with our application.
2. Develop: This is a staging branch. This is where all of the new changes go to test them. The develop branch will closely resemble the main branch.
3. All the other boxes: Are each their own branch. They are created off of the develop branch and this is where we work on our tasks.

Using this strategy, we keep a clean and working deployment separate from new code before it is thoroughly tested and released. So y'all know all that git checkout stuff? That's what's going on here. From "Main" we checkout a new branch "Develop". That is our default branch in our remote repository and everyone works down from there.

I like puzzles so we're gonna use a puzzle analogy again! We're putting together a puzzle taking snapshots(individual commits) along the way and then we're done. Everything looks good. All of the pieces are in the right place. What do we do with it now? Well now it's time to take this puzzle and put it together with a collection of other puzzles in an order that makes sense and creates a larger image(branch merging).

In hindsight I would absolutely change the naming convention of these branches which we did in our next project to utilize better prefixes(feature/bug/blah). Regardless of the naming conventions you employ, branch branch branch.

Ok I will say one thing about naming conventions. Some of you are going to want to name your branches after yourself. Don't. Your branch naming needs to be concise and you need to work on one thing per branch! (more on this below)

When should I use it?

In short, always. I know that's not really helpful. What I mean by always is that there is no reason for you to not commit often on every project.

More specifically? Ok. I invariably get asked, "How much code do I write before I commit?" or "How many commits do I have to have for x homework?" My response is always "That depends." Once we have a nice talk about what version control does for us, I explain that I typically will commit any time I make a change that greatly impacts my task or anytime I'm changing something that might break my app. What does that mean? Well I'm going to give you an example of a very simple task and how I might break down my commits.

I've been assigned work on the nav bar. I need to write my HTML, style the nav bar with CSS, and add some JavaScript for functionality. It's not actually this simple usually but that's a good starting off point for our first little baby project.

I'm going to make a branch and I'm going to name it feature/navbar which is where I will work. My commits will probably go something like this:

HTML

• After I create the navbar element and its children

CSS

• After I create the mobile styling
• After I create each subsequent Media Query
• Before and after any particularly fussy things I'm trying to do with my styling

JavaScript(some simple examples)

• After I add the script that hides the menu on mobile sizes
• After I add the script that shows the menu button on mobile sizes
• After I add the script that slides the menu in and out on click/tap at mobile sizes
• After I add the script that changes the height and opacity of the navbar and the size of the logo on scroll(When the user scrolls down the navbar gets shorter and a little see through and the logo either gets smaller, disappears, or is swapped out for a different version)
• After I add the script that highlights my active page link on my nav bar

When we get further along in technologies and skills, how and when we commit is going to evolve, naturally, but this is a good starting off point to get you in the habit of committing early and often.

Now my task is complete so I am going to push everything up to the remote repo where it will go through a pull request(code review) before being added to the Develop branch. If there is anything that doesn't get caught during code review, we have safely isolated our deployed(Main) branch away from the Develop branch. Now we can create a bug/navlinks branch off of the develop branch and work there to fix the issue. And so on, and so forth.

Why do I care?

Hopefully by now you can understand why this is so important but if not it's ok, we can get a quick recap here. Version control in the form of commits and branching with a common branching strategy keeps your project from being ruined because one person in the group didn't make sure their code wasn't going to break the entire application. Don't be that person. Work together with your group before starting any work in your repository to determine how you will leverage version control in your project.

You can do this. I believe in you! Good luck with your projects and happy coding!