Overview

Welcome to the first tech article by Eminence IT Solutions. If you are reading this I’ll make the assumption that you have written code before or at least familiar with the idea of managing your code and a development process. You might find this particularly helpful if you are a student or just starting out your coding journey. I promise you it will not only help you find bugs easily but it will improve your code and really speed up your development process.

What is source control?

Source control is the process of managing your source code. This can look different depending on the project, people or place you are working at. It can be a team of developers all pushing their code to different branches (you might see where this is going). Or it could be a group of first year uni students sharing a zip folder on G Drive (it’s scary, but we have been there trust me). If you are an experienced developer you may be cringing at the thought of moving code around in zip folders but we all started somewhere. Let’s go over why this is a bad idea.

Zip folders are impossible to guarantee versioning on. Sure you might name your folder version one, one point one, so on and so forth. You have no way of really knowing what files were changed in the folder you are receiving. Furthermore, it is impossible to track the lines of code changed within the folder. But you need a way to share your code with your peers to review, enhance, fix, etc. Enter Git.

What is Git?

Git is a source control technology that allows you to track your code changes. Git deals with a few terms that might be new to you including; branches, remotes, repositories and commits. Your folder (or directory of code) is your repository; it holds all of your code. Now there are a few ways you can set up a repository; you can initialise one from an existing folder, or you can clone one from somewhere like GitHub or BitBucket. A remote is a location you are going to push your code to, this might be a repo hosted on your GitHub account, or on your company’s GitHub. A branch is a copy of your repo, you might create a new branch to build a new feature. You have an existing copy of your repo you know works and you then branch off of that to make a “feature branch”. Finally we have commits, these are small pieces of work or changes that you incrementally build on.

To put this all together with an example. Let’s say that I have a mobile app that I am building. At the moment it has a login screen, a register screen and once you’re logged in it lists out all of your favorite places to go walking. We want a feature where all the locations you like to walk at show as pins on a map. Our existing code is in the master (or main) branch. We can create a new branch off of this called “feature/mapping” and start our mapping feature there. 

Now let’s say that users start reporting a bug in the list. If we didn’t have Git, we would start to dig through our code and undo all of the changes that we have made for our mapping feature, because it isn’t finished yet. With Git, we create another branch off of master called “bug/list” and we fix it there. We then merge “bug/list” back into master and the crisis is averted. We don’t need to undo any changes in our feature branch. We don’t run the risk of losing the version we know works.

What does a tree have to do with this?

So we have talked about branches, which is a hint at where this is going but how does a tree help us? Let’s think of the trunk of the tree as the master branch of our repository. This can be treated as the core of the project, a rule we have at Eminence is we never push directly to master on a live project. This is from a quality assurance position. We don’t want to change the main structure of our tree without proper review. So we do feature branches that feed into release branches. When we want to do a release, we review the release into the master branch pull request after it has all been tested and then we merge.

We can think of our release branch like a branch off a tree trunk, and then a feature branch as a branch off the release branch. We can build on this time and time again and if we break one of the branches. It won’t bring the whole tree down.

I am doing a group project – what now?

Let’s roll back to our concept of remotes, this can be a hard one to grapple at first but say you have a group trying to all work on the same repository of code. You will all want to create a fork of your repo onto your own personal remote. Now let’s say you have an assignment to build an e-commerce store. One of you might build the checkout feature, one of you might build the payment feature and one of you might build the products page.

Now you can all push to your own remotes and merge from those remotes into the decided main repo. This keeps the repository clean and allows you to see who has made what code changes.

Final Word

There is a fair bit of information to digest here. So feel free to leave a comment with any questions you have and we will get back to you as soon as you can.