Ttdfjt

I have been a solo developer for quite a while and am now working with another individual. I am making the difficult switch from Mavens Mate with Eclipse to Visual Studio Code. I am not sure what the best way is to pair program, but I believe Github to be the answer. How can we get our production orgs code into the Github and then have that deploy to our main production read sandbox that we share?

This is going to be a pretty quick summary of a very broad area. I am happy to focus this answer more finely on a specific area if you'd like to push me in one direction or another

Source Model

It sounds like you are already practicing source-oriented development using the Org Development Model (cf. also Trailhead). If you're all set up there, that's great. If not, and you still need to retrieve some customizations, you'll need to develop a package.xml file and pull the source down from your production org.

Eclipse and MavensMate can actually make this initial step pretty easy, if you want to use those tools before you put them aside for VS Code. Just subscribe to the metadata you want from Production and refresh the project to snapshot your metadata. Then, you have a source tree ready to swap over the Visual Studio Code.

Starting with Git

Adding GitHub is a natural extension of a source-based development process, and is especially critical when using a shared, persistent sandbox for development. In a shared context like that, it's very easy to inadvertently overwrite one another's customizations, as well as to pull down to one's source tree breaking changes or overwrites made by the other developer. Using Git makes sure that you can track the version history of your code and helps prevent loss.

Since you're already in a situation where you have your source code stored offline, adding Git and GitHub is pretty straightforward. Create a repository on GitHub and add both developers as collaborators. In your local project, where you have your source code, create a local repository and commit your source code to it. (You'll want to add a .gitignore file to ensure that build artifacts and tracking files, like .sfdx, aren't committed - steal one from an existing Salesforce open source project!)

(Note that you can do these steps from the command line, which is my preference, or from Visual Studio Code's Git interface, or from GitHub Desktop).

Then, follow the instructions on your GitHub repository page to add that repo as a remote to your local copy, and use git push to sync your work to the GitHub server.

Working with Git Flow

You and your colleague will have to get used to working in some flavor of Git Flow. (See Trailhead). Because you'll be moving your source of truth to your source code, it's critical to always make sure you've pulled changes from the server (git pull) before you start writing and committing work, and keeping track of the state of the Salesforce server (sfdx force:source:deploy and sfdx force:source:retrieve - preferably a lot more of the former, since your local source tree will be your source of truth).

It's very easy to be tempted into working primarily in the org, and pulling to local only to make commits to Git. I encourage resisting this tendency: work locally first, then push and test. This helps ensure that you focus on your source code as source of truth and helps protect you against interference in the development process due to changes in your shared resource, the persistent sandbox.

Commit early and commit often - as soon as you have an increment of work that compiles, is my philosophy. Always pull from the server to merge in your colleague's changes. Read up on branching models used by successful Salesforce projects, and consider using feature branches to keep larger units of work separated.

Next Step: Scratch Orgs

Scratch orgs are the next step in source-based development and provide you and your colleagues with individualized, disposable Salesforce environments. When you get to the point where you're fully comfortable working local-first in source format, you may be ready to start experimenting with pushing your code and metadata into scratch orgs.

Note that to take this step you really need to be version controlling everything. That means Apex and Visualforce, but also your entire data model, declarative automation, and possibly even permissions (Profiles are the trickiest thing to handle in source format, but it's not impossible). You'll generate fresh scratch orgs that look like production by pushing this source into them, do development there, commit it to Git, and then throw away the org.

There are lots of great resources on Trailhead and elsewhere on adopting the scratch org model.