Version Control – Intro to Git

In my previous article of this series, I discussed the importance of version control. I highly suggest reading that article before continuing if you have not already done so (unless you already have a good understanding of version control systems).

At this point, I hope we can all agree that version control is needed. It provides too much value to not utilize it. So, how do we go about actually using it?

Set Up Repository

A repository is essentially just a grouping of files, their version history, and commit messages all hosted on a server. This server can either be hosted internally (typically an Enterprise-level solution) or hosted on a service like GitHub or BitBucket (comparison of both). I don’t want to go into how to actually set up your own server. That is more advanced functionality you won’t need to know at this point. However, let’s take a look at setting up a repo (short for repository) up on GitHub.

Public – This repository is open to the world for anyone to see. It can still be locked down on who can actually edit it, but the code is available to be looked at. This is perfect for an open source solution.

Private – This repository is closed from anyone who doesn’t explicitly have access to it. This is required in most environments where the code is proprietary and you don’t want anyone to be able to just look at what you have done.

In the first step, you just want to enter some basic information.

In the second step, you will need to select the plan you want. I am going the free route (which means my repo will be public), but you may want to go a paid option to provide a private repo for your organization.

As soon as you sign up, you will be taken directly to the GitHub dashboard.

Assuming (since you are following along with this article) that you are new to Git, I would highly suggest going through the GitHub Bootcamp. Downloading and installing Git is something that is universally the same. Essentially, that tutorial will walk you through installing Git on your machine so that it will be able to run git commands through your terminal or command line. Once you have that set up, let’s go ahead and create a repo.

On this page, you can enter a repo name. Typically, you will want to keep it short. I suggest adding a description. You can then specify if you want a private repo (only available on the paid plans) or a free repo.

You will immediately be taken to a page that will detail out how to go about creating your repo. However, before we do that, we need to make sure our code structure is set up. Typically, you will want to do this through an IDE. In this demo, I am using MavensMate, but you could also be using the Force.com IDE. If you are absolutely opposed to an IDE, you could also use the Force.com Migration Tool. Essentially, you just need a mechanism for getting code down to your base machine. There are guides on how to do this using any of the available mechanisms, so I will skip to the part about actually getting your repo set up.

First thing you want to do is cd to the proper directory in which your files are stored.

Notice how all of these files have been added. It is important at this point to note the distinction between Git and most version control systems. When we commit here, we are only committing our code to our local repository. In Git, there is a concept of a local and remote repo. It provides you the ability to commit continually and as often as you possibly want without effecting anyone else developing on the repo. We now need to set up our connection to the remote repository. To do that, we will use the git remote command.

Note you will have to change the URL to the remote repo you set up. We can now go ahead and push directly to remote. Note, we are only pushing directly before a pull because this is the very first commit. Typically, we will want to pull first. I will address that in the next article of the series. We can use the git push command to push our initial commit to remote for anyone else to pull down.

Notice, this process is very similar to what GitHub actually suggests on the page directly after creating your repo.

At this point, you will be able to view your repo inside GitHub!

In the remainder of this series, I will discuss branching and adding more of your code to the repo. I will even discuss the proper way to add your other metadata (such as custom objects). Using those methods, you will be able to version every single aspect of your organization, providing structure and security.

Hi Jesse, Thanks for this useful post. I saw that you put all config files of MavensMate under version control. At least stuff like “.session” should be of transient nature. “.settings” includes absolute paths and connection information. Maybe even my encrypted credentials?Unfortunately I’m not 100% sure which files to include and which to put into .gitignore. Especially in a multi developer setting. Any thoughts on that?