Part 2 Version Controlling In Salesforce

Raushan Kumar
5 min readJun 20, 2020

--

This is the Second part in the VCS series, We are going to start from where we left. If you haven’t read the first part of the series, Please go to the below link

https://medium.com/@raushansingh184/version-control-implementation-on-sfdc-7e4c94731b6d

If you remember in our Last Discussion we pushed the complete project to the Remote repository. Now let’s Imagine someone from the team wants to work on that project. He needs to pull the whole Project into its Local Machine and start working.

Before Starting our Discussion further, let’s Understand what is Branching, what is Checkout, Why to use Branching, What’s the best practice to push changes to the Remote Repository.

Branching is like a bookmark. Suppose you are reading a book and you got some work in the middle of it. You don’t go just like that, instead put a bookmark. So that you can come back and resume it from the point where you left. Similar way branching works when we first pull a Project from the remote repository. It creates a default Pointer named as ‘Master’ and we call this Master Pointer as Master Branch. It will keep on pointing to the latest copy of our local directory.

Lets go ahead and Pull the directory which is stored on GitHUB.

Once Logged into GITHUB, you can see your Repository, Click on Clone or Download Button and copy the Link. Save it on your notepad or somewhere as this link is the address from where data needs to be pulled.

Open your Visual Studio Code and click on Clone Repository and Paste your URL.

After Selecting the Repository Location, You will see your Git is running a clone Command and the complete directory is being copied into your Local machine.

If you look into the Image below you can see all the classes have been stored into local machine and a Master Branch has been created that points to the Current Directory. Look at the Highlighted part of the Image.

Now i am going to make a new Branch named as “working branch”. To create a new branch,

You can either click on the Master branch and select the option “Create New Branch” or Run a git Command on your Own. “git branch WorkingBranch” will create a new branch in the System. But the newly created Branch won’t be your Woking Branch, to make a branch as your Working Branch. You need to checkout that Branch. Run the Git Command in your Terminal. “Git Checkout WorkingBranch” going forward all the changes you will make will be pointed by WorkingBranch and Master will still be at the time it was initially.Refer to the image below.

If at any point in time, you Checkout to Master again then Your working directory will show the same changes at T=0; But that doesn’t mean the changes that you have made will be lost. You can checkout again to the WorkingBranch and you will see all your changes there.

To understand in more details about the Branching in GIT, Please Click Here

As you can see in the image below, I have switched my branch from “Master” to “WorkingBranch”

Lets Go ahead and Make some changes in the file.

I have added a new Method in my class and once you save it you can go to your Source Control Tab and see, the changes that you have made, marked as M(means modified).

Now we can follow the same process as we followed Earlier, Lets Stage this change by clicking on the + icon besides “M”

Now you can see it has come to the STAGED CHANGES box. Now let’s go and Click the tick Symbol with some messages, to Commit the Changes. Remember, Committing doesn’t mean your changes have been Pushed to the Remote Repository. But it means your Package is ready to be pushed to the Remote Repository.

Select “Push to” from the “More Action” option and you see below screen. Select the origin and Hit Enter.

Your Latest Branch along with the Changes Pushed to the Remote Repository, as shown below.

Now you need to merge the Changes to your Main Remote Repository, For that you can click on Compare and Pull request.

You can see the message that you gave while committing, Click on create Pull Request.

Once you get a No conflict message, you are good to merge your Changes to the Master of Remote Repository. Click Merge Pull Request.

As you can see our changes have been merged to the Master Remote Repository. It is always advisable to delete the Branches to avoid confusion in future. By clicking delete Branch we are deleting workingbranch and not the Master Branch. But, our WorkingBranch Still exists locally and we can keep working on that and keep pushing our Changes.

I hope this blog helped you in understanding Version Controlling in SF. In our Final Part we will see how we can deploy changes from one Environment to another.

Cheers !

--

--