Git-ing Used to Working with Others

This past week I completed my very first project for Flatiron School. The assignment? With your partner(s), create a Command Line Interface (CLI) application. The application must access a Sqlite3 Database using ActiveRecord, have a minimum of three models and should give the user full CRUD (Create, Read, Update, Destroy) ability for at least one of your resources.

My partners, James and Jenn, and myself, set out to create an app that would parse the ‘Qld wildlife data API,’ using RestClient and JSON, to allow users to ‘favorite’ particular animals, and receive information, such as that animal’s scientific name and it’s conservation status (i.e. critically endangered, endangered, vulnerable, etc…). From there we added two new tables, charities and donations. We parsed yet another database from the Queensland Government website, giving us a multitude of charities devoted to wildlife conservation. In the end, the users were able to sign up or login to the app, add animals to their ‘favorites list’ or even make a symbolic donation to a charity of their choice in honor of a particular animal. A user could view top donors in the app and also the top five favorited animals in the database.

All other groups for this project were comprised of a pair of programmers. I, however, was blessed to be part of a group of three. This initially posed a problem though… How do you pair-program with three people? The answer: Git branches!

Git is a Version Control System that allows multiple users to work on the same project simultaneously, without infringing on each other’s workflow. “But Ian,” you might say. “That sounds too good to be true!” Fear not, my friend. My words are both good and true!

With Git, you have the possibility to create branches. First, let’s confirm you are working with the master branch. This was created when you initialized the repository.

We now have two options to create a branch. Typing ‘git branch <NEW BRANCH NAME>’ will create a new branch for you with the given name. After, use ‘git checkout <NEW BRANCH NAME>’ to switch to that branch. Notice how I use ‘git branch’ after each move to make sure that I am where I want to be in the process.

Another option is to use ‘git checkout -b <NEW BRANCH NAME>’ in order to create a new branch and switch to that branch all in one move:

There you have it. You’ve now created a new branch, which is currently identical to the master branch. You can do as much work as you want on your new branch. This beautiful concept is what allowed my partners and I to work on our app simultaneously. After one of us was done with a task, be it our CLI, relationship methods, or the app’s CRUD abilities, we could merge our branch with the master branch to add our work to the fold.

So you’ve made your new branch. Your master branch might look something like this, on a very basic level:

But your new branch looks like this:

First, you’ll need to add and commit your changes, then switch back to the master branch. We want to be in the branch that we are merging into.

Now your code might look something like this:

Here, you will need to do some work in order to determine which changes you want to keep and which to discard. If you want to keep only your changes from the branch, choose ‘Accept Incoming Change’. To keep just what is from the master branch, ‘Accept Current Change.’ Lastly, to keep everything, simply choose to ‘Accept Both Changes.’

Congratulations! You have officially created a new branch, made all your wondrous changes, and merged them back into the master branch. And you did this all while allowing your teammates to work independently of you without any getting in anyone else’s way! Sometimes, working with other people is not easy. That is a part of life. Hopefully, though, you can now use Git as a way to git your worries out of the situation!

If you’ve read this far… Thanks! Feel free to check out the repository for our group project here:

Software Engineer with passions for education, wildlife conservation and travel.