A distributed version control system did not feel natural to me when I started on it a couple of years back. I primarily grew up with mainframe, Siebel development and distributed version control does not play well everywhere.

When it finally grew on me, I was just using it for my side projects that had a grand total of 1 developer. I quite did not use it as true version control but rather as a backup system. It did not occur to me to apply it on Siebel - well, that does not seem ok even to this day (latest announcements in Siebel not considered).

When I increasingly saw salesforce.com application development with Git, my first impression was whether we are fixing things that are not broken. You have a development server dedicated to the team (at least how I saw it then), you have multiple people checking in their code on that server directly. So, would it not make sense to use a central VCS (version control system)?

After a couple of months of pondering over the question and also going through how others do it, I got it (or at least I thought I did).

Here’s a run down of why Git in Salesforce.com projects -

More power to developer
Git offers flexibility to branch out on your own. You can build stuff, break stuff and build some more without worrying that you will break the entire application.
You have your own environment to play around with and get your code to your original, or Continuous Integration (CI) server when you are ready.
Work in parallel
Don’t get worried about how code from your team mates will break your code.
(On after thought, do worry but don’t loose your sleep - Git has your back).
Do not worry excessively when you are working on multiple branches - your bug fix work that has to go live in a week can happily co-exist with your enhancements scheduled for the next quarter.
Flexibility
Go crazy with branches. Branch early and where required - it helps.
True backup for a true roll back
Roll back to your earlier version by not breaking into a sweat each time you do that.

Sadly, use of Git is not as trusted within Salesforce projects. I have seen projects that burn when we tried introduce Git. The version control tasks are often misunderstood and developers struggle to get it right.

In fact, I go as far as to suggest not to introduce Git if you are in a hurry and have 1-2 people development team.

If you think someone is going to die if the all wonderful Git system is not introduced, feel free to point to this article.

After such a long introduction, let us get quickly get down to business.

Get Git #

Git is a distributed version control system . One of the things that is important to note is that your local repository is a clone of your server.

You need two things to get started on Git -

Git client
Git is completely free and available for multiple operating systems - here .
You can use a command line interface, integrated interface that comes as plugins with your favorite editor (more on this later), or use an UI (SourceTree or GitHub’s desktop app).
Git server
Either you can use your existing server (hopefully with a different repository) for the experiments outlined here, or -
- you can set up the server on your own machine
- use GitHub (which is free for open source projects)
- use Bitbucket (which will allow you to have a couple of private repositories)

I will choose Butbucket hereon.

Learn Git #

There are several excellent resources to get started on Git. You would have to understand how Git works before you start pulling & pushing stuff to your salesforce org.

Learn Git branching Highly visual way to learn Git - highly recommended.
Download eBook or learn online
ProGit explains the basics and take you through the advanced topics.
Learn Git from Github
You can use any browser to type in commands and learn how stuff happens in Git.

Set up Salesforce for Local Development #

Git works with files. We consider the metadata files provided by Salesforce for version control.

You work with metadata files from your computer using Eclipse, Atom or some such editor that integrate with Salesforce.com or third party provided tools. Explore and find out what you like -

There is more than one way to get the salesforce.com org metadata to your version control system. You can either get the code setup directly on Git server, or download to your local and feed the Git server there on.

We will use Eclipse and Salesforce.com IDE in the subsequent tasks.

Once you have the tools, it should be as simple as connecting to your salesforce.com org, selecting the components, and getting the specified components from the server to your local.

What you have done so far is pretty standard for local development.

Next, we tell Git that the local SFDC repository has to be version controlled.

I will use a plugin called Egit to make my Git work within Eclipse easier, but you can do this in tens of different ways.

Find your repository folder. Copy the folder name
Create local Git repository (switch to Git perspective within Eclipse to see this option)
Switch back to SFDC perspective in Eclipse.
You will now see a “no head” against the root folder. This indicates that there are no files committed yet. Right click on root folder, choose Team > Add to Index.
You will see different icons against the files now.
Go ahead and commit.

Now, your local SFDC repository is successfully version controlled.

Set up Git Server #

We will use Bitbucket for our Git server.

Setup a Bitbucket account if you don’t have one. Hit Create a new repository under Repositories menu item.

Once the repository is created, expand the “I have the an existing project” option to copy the URL.

git repository server setup for sfdc.jpg

Go back to Eclipse, right click on root SFDC folder, select Team > Push.

push SFDC git repository from local to server.jpg

Paste the URL, put in the password and hit “Next”. Fill in some more details and initiate the “Push”.

Have a cup of coffee and come back. Now your server is all set.

What you have done so far -

Setup Git on local
Connect local SFDC repository/folder to Git
Setup Git on server and setup connection between local and server Gits

Bear in mind - the SFDC repository you are working with so far is your repository. Similar to you other developers would need to have their own sandboxes and plug themselves to Git.

That brings us to the next question - how the heck can we connect our server Git to the server SFDC. The server SFDC (which we will call CI Server henceforth), is where the code from entire team gets together to create magic.

Hold on to this thought while we sort out the less important matter of working with the local Git repository.

Working with SFDC and Git in Local Repository #

We will see a completely manual way of working with Git/SFDC to understand the flow better.

The objective is to add a new field called “Serial Number”.

Get the latest version of Contact object and Contact layout from server to your local repository.

This is important if your team mates have made any changes on the server.
If there have been any changes on the CI server, push those changes to your local SFDC (remember that you have your own instance?).
Create a new branch for the change. This will help us to revert to this milestone if anything goes wrong.
Make changes - either in Eclipse or on your SFDC app. We will assume that changes are made in SFDC application.
Now, bring the changes to your local Eclipse.
You will see that the changes are duly noted by Git.
Double click the files to view a comparison.
Now stage the changes, commit to your local Git and push changes to your Git server.
You can see the branch on the server.