Gittin Down To Business

Greetings! I’ve recently picked up a lovely collaborator with my Donna’s Cookbook project. One thing that occurs once you’ve onboarded a fellow coder to a project you’ve been working on is the need to handle merging different work flows. If I’m building a menu bar, and someone else is building a recipe page, let’s say, those two bodies of work will need to be merge somehow. That is unless the coders in question would prefer to labor side by side over the same terminal. Enter the titanic power of git! Git is a version control language that many coders use to keep track of the different stages of their projects as well as to collaborate and share work with others. In this blog I’ll be going over a few of the basic yet difficult to fully grasp git commands.

The first part of any git expedition is to execute your git init. This command, when executed from the command line, will create a copy of whichever file you happen to be in, and all the nested files. Next you’ll want to set up your remote repository. What is happening essentially is you are creating a space on the internet that will mirror what you’re working on, on your local terminal. In order to link your local git repository to a remote one, you have to first create that remote git repository. Head over to github.com, which is where all these git repositories are hosted, set up an account, and then hit the “new repository” button on the top left. Once you’ve named the repo, and set up a few other details, you will be provided with an SSH key. This, once pasted into your local terminal, is what will be used to set up the remote repository. The syntax required to set up the remote repo is:

git remote add origin <ssh-key-here>

Once that’s done you are completely ready to start working on your first commits.

One of the main use case for git is to keep track of the different phases of your work. Basically creating a save point for your work. If something ever goes disastrously wrong, git will be there providing you with working versions of your project going all the way back to the first commit. Provided you have been diligent about executing your commits while working. Let’s talk about exactly how to do that. It’s a three step process. The first thing to do is stage your changes. That looks like this:

git add .

The period after the add is identifying your current file as the file whose changes you want to save. A period, in CLI speak, references the current file. So now you’ve got your changes staged. Once that’s done you’ll want to officially commit them. To do that you use this command.

git commit -m "This is a message for my commit."

The -m flag is designating that you are going to write a message. The string placed after the flag is the message. While it may seem frivolous to put a message onto every single commit, it’s actually incredibly helpful when you need to go back and find what went wrong. Having a list of annotated changes is much easier to parse than a stack of anonymous commits. Once that’s done, your commit will officially be logged in your repository. The only thing left to do is mirror those changes to the remote repository. That’s done using a very simple command know as git push.

git push

If your remote repo has been set up correctly as described above, your terminal should take care of the rest.

That’s the version control side of git, but let’s now talk about how it can be used as a collaborative tool. Git has a feature known as branches. These branches are a way to experiment with your project without having to effect your master branch. Any changes or inevitable bugs and crashes that crop up in the test branch will stay there until they are ready to be merged with your main branch. Additionally, multiple collaborators can work on different features in their prospective branches without creating bugs in the main branch. To make a branch you use the command:

git branch <branch-name>

Once it’s made you use the command

git checkout <branch-name>

to enter that branch. Using the command

git branch

will tell you what branch you are currently on and what branches are available. When you are ready to merge your working branch with branch you just use the command

git merge <whatever-your-main-branch-is-called>

Git will then show you all the differences between the merging branch and the main branch, and once they are rectified you will have successfully executed a git merge. Hopefully this has been helpful.

Good gittin!