Advice From A Gitfather: Lessons on Version Control

Hello, World!

This is my first blogpost as a future programmer! Woo!

I'm a baby-dev. A hatchling. A student.

An init() function of a programmer (sorry, I'm new and I'm still loving the ability to make try-too-hard Programming Jokes).

I'm a student enrolled in the Flatiron's Full-Time Software Engineering Program (Cohort 051622 represent!).

I'll be using DEV to document my learnings, share my bad dad jokes, and hopefully reflect on the lessons and friends I learned along the way.

And for my ubiquitous first post, I won't be waxing about an event listener I coded in JavaScript or how I centered a Div in CSS or anything related to actual code. There are a million angry StackOverflow replies out there for people to read, mess up, and copy-pasta.

No, for this post, I want to discuss this amazing new power I learned: version control!

You see, I was in a group project, and I volunteered as tribute to handle version control and Github.

Little did I know, it would push me down a path toward becoming...

I won't lie- I was scared.

I had never used Github before, and I had only heard about it in tellings as the bane of Programmers, Scrum Masters, and Product Owners alike.

What if I screwed up?
What if I ruined someone else code?
What if I broke the Internet?

And then I read Matt Eva's wonderful guide to Github. and it all became much easier.

While I won't copy Matt's wonderful work, who goes into incredible detail for the exact commands needed, I will share my learnings in my first foray as Gitfather of our project.

While Github is an amazing tool for version control, ultimately, I was responsible for using Github to, well, control the versions.

function versionCtrl(){
   controlVersion()
}

I like to think of version control in terms of a restaurant (I'm a huge foodie, so I always try to relate everything to food).

The way food gets created is incredibly analogous to how code gets deployed.

Let's think about how a restaurant cooks food:

1. The kitchen receives an order (also called a ticket).
2. The kitchen divides work amongst different stations.
3. The dish is worked and passed on at each station.
4. All stations finish and food is taken out to the customer.

In between each of these steps is a vital team member to a kitchen: The Expo.

In any (good) restaurant, the Expo is arguably the most crucial staff member to success. The Expo monitors each of the above steps and makes sure that each step of the dish gets completed so that no other stations get held (aka "in the weeds").

Much like food, code undergoes the same process:

1. An update request (sometimes also called a ticket) with deliverables gets created.
2. Programmers break down the deliverables and code.
3. Code gets merged so the next code session has updated code.
4. Once finished, the code is all packaged up and deployed as one complete package.

And, like an Expo, between each of these steps was me- the Gitfather.

I was responsible for making sure that each successful code update got merged to main and that our team was "handing off their dish" correctly.

Like an Expo, I was responsible for reminding team members to cook our food (code) using good version control practices:

1. Pull from main (git pull or git pull origin main)
2. Create New Branches (git branch <new branch name>)
3. Track and Commit Their Work (git add <file> or git add . andgit commit -m "comments")
4. Push Work (git push)

And like any good kitchen (or any good team), I had to make sure our team was communicating.

If you've ever watched a (good) kitchen at work, the Expo knows everything going on in the kitchen and is barking orders:

• Let's get those steaks working (start cooking the steak)!
• I got a steak dying over here (my steak is sitting too long)!
• Where's my salad?!1? (Where's the damn salad?!)

(Spoiler: I've never actually work in a pro kitchen/restaurant, so take everything I say with a huge grain of Maldon Sea Salt- I just watch a lot of cooking shows!)

As the Gitfather, I had to do the same (although less barking more gentle reminders):

• Remember to create a new branch!
• Constantly track, commit, and push!
• Make sure you pull from main before you work!
• Main is merged!
• Where's my salad??!1?

Basically, any good Gitfather needs to be on top of what everyone is working on.

For instance, I knew one team member was working on JS updates and another was working on HTML updates. I had to make sure the HTML updates wouldn't conflict with the JS updates. Or, I needed to make sure all JS and HTML was done before we could start hunkering down on CSS. And, in all of this, making sure comments were clear and organized so we all know what we did and where in the code.

Ultimately, while Github is amazing for version control, the best version control is you.

Like a good expo, you need to know what is going on at all times in your kitchen.

• Who's working on what?
• What is being worked on?
• Who is crying in the walk-in?
• Who asked for ranch with their steak frites?

And while intimidating as that seems, it ultimately empowers you to be at the center of it all. And you get to see and learn so much.

You get to see the your team create literally something out of nothing. You get to see how people approach problems. You get to see the brilliance of your team members and their programming skills.

And most importantly, you get to take credit for all their work because you merged all their updates to main.

Good luck future Gitfathers, Gitmothers, and Gitzaddy!