Let's Git Acquainted

GREETINGS, EARTHLING!

Hello! Here's a quick introduction, since this is a new blog. My name is Krystal. I'm a 4th year Software Engineering student at Penn State (WE ARE!) and I'm trying to make an online portfolio for myself, so here is part one: the blog. I'll try to keep it regularly updated with projects, questions, struggles, and maybe even some tutorials (although those will have to wait until I finish this semester... boy, am I busy). So without further ado, our first topic:

GIT

I'm embarrassed to say that in my last year of school, I am still not comfortable with Git. For those of you who don't know what Git is, here's a nice tutorial. If you're too lazy to click on the link, you won't like Git very much... but I'll tell you what it is anyway. It's a version control system. Basically, when I'm writing a program, there will be many stages to the coding process. I'll write something, it'll work, I'll write something else, it'll break the code that previously worked... Version control systems basically ensure that you don't lose the progress you've made! If you've used commits properly--commits are the equivalent of save points in a game--then you know that at the very worst, you can always go back to a "save point" that worked. But back to my main point, I'm not comfortable with Git.

Yes, in theory it's pretty simple. You create a repository and commit stuff to it. However, once you add additional contributors, it gets complicated. What is the process? Do I push, pull? Am I going to lose my work or wipe out their's?

SO, I'm going to figure it out now, before I wreck my team's project, which is due in less than a month. 😁

MY ASSESSMENT

Process:

1. Commit the code on my branch
2. Pull (fetch and merge) from master
1. In the event that there's a merge conflict, you'll have to go through the code to see what was changed by you and what was changed by the other collaborator and determine which change will make the cut. This is why it's super important to make sure you are pushing and pulling often enough to keep up with the changes that are being made. Once your branch falls behind, there's a greater likelihood of merge conflicts. They're not impossible to fix, but it's tedious and we'd rather work smarter, not harder! 😄

So it turns out that I was making a fuss over nothing. The process is a lot less complicated than I thought it was. I will blame this irrational fear of ruining an entire project on my first experience with Git looooong ago, before I had even started my degree. I definitely mucked up some things by using different commands that I didn't understand. In any case, don't fear Git! It's an amazing tool. That's the lesson of the day. Ciao!

* I would love for this to be an interactive blog, so if you have recommendations or questions please do not hesitate to leave a comment!