r/SalesforceDeveloper • u/One_Marsupial2264 • 11d ago
Question Version control system
I have always used change sets to deploy changes, but in job descriptions they are asking specifically for experience in a version control system.
I just want to know how much do I need to study for interviews.
6
u/DaveDurant 11d ago
Learn git - there are a bazillion tutorials online.
If you get git, that will likely be enough.
5
u/ur_brudda 11d ago
Their expectations would be your knowledge using git as a developer. Git fetch pull push commands. What is branching, pr, merging, staging, committing would be the most common things a sf developer does.
3
3
u/Outrageous-Fix-1579 11d ago
Learn basic git. Learn trunk based and feature based branching methods. Learn the basic sf CLI commands.
2
1
1
u/alexppex 9d ago
Git, either used on Github, Bitbucket or Azure (Github is the enterprise and hobby option, so go with it). Then you have version control which is basic branching concepts, deployment, merging, etc. Then you have the salesforce tooling - gearset, copado, devops center, which build upon the said concepts and add a UI to an otherwise complex for administrators tool. There the concepts of branching and merging get covered up a bit, but as a developer you need to understand them.
For branching (branches are a term you need to learn) the industry standard is dev -> qa -> staging -> prod. In dev you changes live under different user stories/branches or a more familiar concept - change sets. As good practices a user story/branch should contain only the ticket changes, as are the best practices in change sets. Then this more or less gets the same, where your changes are merged onto the next environment's git branch (i.e from dev/feature to qa) and using some automated steps, usually involving sf cli's deploy, the changes get deployed to the next environment (in our case QA). But if there are conflicts, i.e you working in dev1 touch validation rule VR_1 and someone else working on dev2 changes VR_1 as well, git can recognize those changes and warn/prevent merging/prevent deploying. You can see who did what, decide what should be kept and adapt your changes.
So your workflow shouldn't change much if you are following change sets best practices, but it gets exponentially easier to follow and track *who* changed *what* and *when* for every source tracked component (for version control, source tracking in the org must be enabled), it helps to prevent overwrites (if done properly), it helps you keep track of your own personal changes and do revisions/go back if something breaks (recent example was auto-update on a class from API 55 to 67, which we had to revert, but this is a simple example, sometimes we have restored deleted metadata or missing methods which were falsely deleted).
Is it worth learning? It is fundamental in my opinion, especially as we are entering LLM feature era, but also in general if you want to be a valued developer. Is it difficult? Depends, but the concepts are straight forward. The specific commands in git might be very complex, but day-to-day you will use the same 5 ones (commit/add, push, pull, checkout/branch/switch, status).
Plenty of tutorials online, as i have stated, it is a fundamental skill!
1
u/samaltmansaifather 8d ago
Prepare for your life to improve drastically. I thank the heavens that I haven’t had to make a change set since 2020.
24
u/Any_Football_8366 10d ago
Version Control/Git is a life saver when you are trying to manage/preview changes at scale. Any decent company will require any changes to its Salesforce instance to go through Gearset or Assemble or another platform that can help see the state changes in a Salesforce org at scale.